Hi folks,
Last year I faced a similar problem. I posted in the list, but it remains unsolved. >>>>>>>>>>>>>>>>>> BOM >>>>>>>>>>>>>>>>>>>>>>>>> Subject: Thunderbird stalls when an IMAPS server doesn't support resume Hi folks, I sent the following message to dev-apps-thund and, as I didn't receive any reply, I realized that it could be worth try to discuss this issue here. I am facing problems when using Thuderbird to acess my "old" imap server (uw-imap). After upgrading from an old thunderbird version, the interaction with my imapS server became unstable. It seems that the latest version 17.0.5 tries to resume the SSL session (sending a SSL Hello with a previous session number) and keep retransmitting it trying to resume the conection. At this point, the app stalls and the only way to keep the interaction with the imap server is to close and open thunderbird again. In this way, a brand new one session is stablished. Is anyone facing this kind of problem? Also, Is possible to have (in newer thunderbird version) a configure option to handle these old servers? The idea is to allow the user to configure app in such a way that, instead of resuming a SSL (imaps) conection, the app would start a new connection. Thanks in advance, Tiago ps.: After analyzing the capture of an older thunderbird (2.0) version, the app seems to initialize a new session every time it has to interact to the imap server. " The workaround for me was to use an older thunderbird version. >>>>>>>>>>>>>>>>>> EOM >>>>>>>>>>>>>>>>>>>>>>>>> Good luck, Tiago Em 12/01/2014 09:26, Kai Engert escreveu: > Have you ever seen a TLS server that was incompatible with TLS session > IDs? > > I helped to analyze bug 858394 (with the help of ssltap), where initial > connections to a TLS server work, but attempts to reconnect fail. > > If the client includes a non-null session ID parameter in the client > hello message, the server immediately terminates the connection. > > I reproduced the problem using ssltap (from NSS) and using the s_client > utility (from openssl). > > It has been confirmed (using a custom build) that reconnecting with TLS > session caching disabled makes reconnections work. > > Do you agree this is bug on the server side? Should we attempt to > identify which TLS toolkits and versions show this broken behaviour? > > At least NSS/PSM currently don't expect such behaviour. We don't > automatically retry without a TLS session ID. Should we? > > Regards > Kai > > PS: > > Bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=858394 [1] > > How to reproduce: > # ssltap -s -l 86.65.39.15:6697 > # openssl s_client -connect 127.0.0.1:1924 -ssl3 -tls1 > -no_ssl2 -no_tls1_1 -no_tls1_2 -reconnect Links: ------ [1] https://bugzilla.mozilla.org/show_bug.cgi?id=858394 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
