Hello Nic, On Mon, May 28, 2012 at 8:30 AM, Nic Wise <[email protected]> wrote: > This is a bit of an oddball one, and not one I can reproduce. > > 20120528/113316: URL: https://bbsc.freeagent.com/verify > 20120528/113317: Ex in Verify: Error getting response stream (Write: > The authentication or decryption has failed.): SendFailure > 20120528/113317: Exception: System.Net.WebException: Error getting > response stream (Write: The authentication or decryption has failed.): > SendFailure ---> System.IO.IOException: The authentication or > decryption has failed. ---> Mono.Security.Protocol.Tls.TlsException: > The authentication or decryption has failed. > at Mono.Security.Protocol.Tls.RecordProtocol.ReadRecordBuffer (Int32 > contentType, System.IO.Stream record) [0x00000] in <filename > unknown>:0 > at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback > (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0 > --- End of inner exception stack trace --- > at Mono.Security.Protocol.Tls.SslStreamBase.AsyncHandshakeCallback > (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0 > --- End of inner exception stack trace --- > at System.Net.HttpWebRequest.EndGetResponse (IAsyncResult > asyncResult) [0x00000] in <filename unknown>:0 > at System.Net.HttpWebRequest.GetResponse () [0x00000] in <filename unknown>:0 > at System.Net.WebClient.GetWebResponse (System.Net.WebRequest > request) [0x00000] in <filename unknown>:0 > at System.Net.WebClient.ReadAll (System.Net.WebRequest request, > System.Object userToken) [0x00000] in <filename unknown>:0 > at System.Net.WebClient.DownloadDataCore (System.Uri address, > System.Object userToken) [0x00000] in <filename unknown>:0 > 20120528/113317: StackTrace: at > System.Net.HttpWebRequest.EndGetResponse (IAsyncResult asyncResult) > [0x00000] in <filename unknown>:0 > at System.Net.HttpWebRequest.GetResponse () [0x00000] in <filename unknown>:0 > at System.Net.WebClient.GetWebResponse (System.Net.WebRequest > request) [0x00000] in <filename unknown>:0 > at System.Net.WebClient.ReadAll (System.Net.WebRequest request, > System.Object userToken) [0x00000] in <filename unknown>:0 > at System.Net.WebClient.DownloadDataCore (System.Uri address, > System.Object userToken) [0x00000] in <filename unknown>:0 > 20120528/113317: In complete. success is False > > The user said that all/most other traffic was flowing well. He's on > the same carrier (in the same city) as me, and a lot of other people. > > I'm using the "accept all SSL certs" thing, if that helps: > > ServicePointManager.ServerCertificateValidationCallback = (sender, > cert, chain, ssl) => true;
You should not - but the exception points to transmission, i.e. well after the certificates validations. > Any thoughts? Anywhere to look? I think this is using an older version > of MonoTouch, SSL/TLS are, by design, difficult to debug since they don't tell you much about what (or when) things fails. That makes attacks harder and debugging (near) impossible. Now at the stage this occurs we know that SSL negotiation was done. IOW client/server decided on a common cipher suite, certificate were accepted... and that the request was sent. (More likely) a network glitch. SSL/TLS ensure integrity of the data. One single bad bit will result in an error - and since the internal state becomes invalid the whole SSL session must be restarted (i.e. there's no low-level try it again). If this is not something that can be duplicated again then it's a likely culprit. (Unlikely) the server asked for a renegotiation. That can occurs (it's optional) after a large amount of data was sent. It's very uncommon* (for HTTPS) so it's less tested than the general code (but bugs were fixed years ago and not reported again). If that's the case then it should be possible to duplicate the same issue with the same web site (same server configuration). * it's more common in long sessions, e.g. with a database, than for HTTPS > before the recent crypto changes that Sebastian blogged > about. The recent changes should not affect how SSL/TLS behave. It should be faster (I/O are predominant in this case so it might not show off a lot) but not different. More than 2000 test cases were ported to ensure this :-). Sebastien _______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
