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 \
> https://tcs.mysap.com/invoke/tc/getCert?SAPServerCA.der
>
> 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
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
alert...).

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
ClientHello.

- 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
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsNSSIOLayer.cpp&rev=1.165&mark=1594-1608#1578

- 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.

Kaspar

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2009-10-17