thanks Sebastien - that makes sense. It appears to only happen with a small number of my customers - a VERY small number. I wonder if it's a device issue....
On Mon, May 28, 2012 at 1:52 PM, Sebastien Pouliot <[email protected]> wrote: > 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 -- Nic Wise t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise b. http://www.fastchicken.co.nz/ Earnest: Self-employed? Track your business expenses and income. http://earnestapp.com Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p mobileAgent (for FreeAgent): get your accounts in your pocket. http://goo.gl/IuBU Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2 _______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
