Re: [PATCH] nss: try to reconnect in case of TLS intolerant server
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 https://www.orange.sk
> $ 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
www.orange.sk ("Server: Oracle-Application-Server-10g/10.1.3.1.0
Oracle-HTTP-Server") and tcs.mysap.com (no Server header, running some
SAP stuff, I guess) aren't really "TLS intolerant", they do speak TLS
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=239381 (and the bugs
mentioned in comment 12, too). Some of them have recently been addressed.
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2009-10-17