Kamil Dudka wrote: > The "TLS intolerant" terminology has been formerly taken from xulrunner.
Correct - but it actually refers to a server which is completely TLS intolerant. Back in 2000/2001 or so, when this code was added to Mozilla clients, it was a workaround for servers which only spoke SSL 3.0, but not TLS 1.0 (because RFC 2246 was pretty new at that time). I would suggest to reword the warnings in Curl_nss_connect to something like "TLS disabled due to previous handshake failure" and "Error in TLS handshake, trying SSLv3...", respectively. >> of course course (depending on how frequently such server >> implementations are seen in the wild). Some points to consider: > > I have no statistics, but the user's question is always the same: "I can > download https://XXX with Firefox, why it is not possible with curl?" I see. And they might get more common, now that quite a few of the SSL/TLS toolkits are using TLS extensions by default. > If you find a better solution, I am happy to use it. From my observation > either disabling TLS or enabling V2_HELLO was successful for those two URLs. > But I wanted to avoid reinventing a wheel, thus took the working solution > from xulrunner as-is. You're right, for NSS this is currently the only viable solution to turn off TLS extensions in the ClientHello in NSS. Maybe NSS should add support for setting another option for an SSL socket, something like SSL_DISABLE_TLS_EXTENSIONS... What about your contacts to the NSS people within Redhat (Elio, Bob, ...), would they listen to you and make sure that this happens "reasonably soon"? ;-) > The variables in lib/urldata.h can be shared by others implementation, the > hook for reconnect after SSL error as well. Unfortunately the SSL error code > resolving and then SSL option tweaking is per-library specific. That code > has to stay within lib/nss.c. True, all the logic is within the *_connect routines. Are you considering to add similar workarounds for the OpenSSL and GnuTLS specific code, or are you focusing on the NSS stuff right now? The changes to lib/nss.c look reasonable to me, as far as they relate to NSS. I'm not familiar with curl's retry logic, so I defer comments about that to others following this thread. > IMO this bug does not affect libcurl, but good point anyway. It makes sense > to > cache the "broken TLS server" detection result among different connections on > the same handle. I've added a new state variable to struct UrlState to > achieve this. There's one caveat with this strategy: a URL could also get into this "TLS incapable" state due to a transient problem with the handshake (with the SSL_ERROR_HANDSHAKE_FAILURE_ALERT error e.g.). In a long-living process, this could mean that libcurl never retries to connect with TLS, even if it was supported by the server (and therefore preferrable over SSLv3). My previous comment actually referred to this situation - so all in all, the approach with patch v1 seems better to me, actually (i.e., do not remember the state in libcurl forever, and retry with TLS whenever you're connecting again). Kaspar ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
