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