Maybe some devices / ISP / cell providers are more likely to have networking issues. Try to get keep track of the data maybe some pattern will emerge and allow us to pinpoint the root cause (first step toward a resolution, if possible).
On Mon, May 28, 2012 at 8:59 AM, Nic Wise <[email protected]> wrote: > 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
