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
Received on 2009-10-21