cURL / Mailing Lists / curl-library / Single Mail


Re: [PATCH] nss: try to reconnect in case of TLS intolerant server

From: Kaspar Brand <>
Date: Sat, 17 Oct 2009 08:41:02 +0200

Kamil Dudka wrote:
> here is a proposed patch implementing the workaround for TLS intolerant
> servers (taken from Firefox/xulrunner). I've just tested it as following
> and it looks like it solves the problem:
> $ curl --silent --verbose -o/dev/null
> $ curl --silent --verbose -o/dev/null \
> Any feedback welcome!

GŁnter asked me (off-list) to comment on this patch... so here we go.
I haven't looked at the proposed code changes in much detail, but have
some additional observations/thoughts.

Seems like you tripped over yet another category of broken TLS servers:
those which freak out when they encounter TLS extensions. Both ("Server: Oracle-Application-Server-10g/
Oracle-HTTP-Server") and (no Server header, running some
SAP stuff, I guess) aren't really "TLS intolerant", they do speak TLS
1.0, actually.

However, when encountering a ClientHello with TLS extensions - be that
SNI or SessionTicket, e.g. -, these servers will immediately return a
fatal TLS alert, either "illegal_parameter" or "unexpected_message"
(i.e., the ones you're catching in Curl_nss_connect). Probably needless
to say that this behavior does not comply with the TLS 1.0 spec -
already RFC 2246 had a "Forward compatibility note" which allows
additional data in the ClientHello (and noted that this data "must
otherwise be ignored" - certainly not being replied to with a fatal

This doesn't a priori preclude libcurl from implementing a workaround,
of course course (depending on how frequently such server
implementations are seen in the wild). Some points to consider:

- Is downgrading to SSL 3.0 really the best solution? If there's a way
to only suppress TLS extensions, that would probably be preferrable.

- The fix for these particular server implementations should make it
clear that it's dealing with "broken TLS servers" (or maybe
"TLS-extension intolerant servers"). As mentioned above, those servers
will "happily" negotiate TLS 1.0 if no extensions are sent in the

- Mozilla's PSM code has 15 NSS error codes which possibly indicate a
TLS intolerance - you might want to add some of them to your list. See

- libcurl versions compiled against OpenSSL or GnuTLS will most likely
suffer from the same problem, so maybe an implementation with fallback
to "extension-less" TLS (or even SSL 3.0) would better go into
lib/sslgen.c, not into lib/nss.c only?

- The "ssl_connect_retry" state variable, how exactly does it behave in
a long-living process (such as a daemon, e.g.)? If a particular URL has
been marked as "intolerant", would it stay so forever? I'm asking this
because PSM has some issues with this specific scenario, see e.g. (and the bugs
mentioned in comment 12, too). Some of them have recently been addressed.


List admin:
Received on 2009-10-17