526806 - Add SSL socket option for completely disabling TLS extensions

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement, P2)

Description

[Kaspar]

This is an RFE for adding an option to SSL_OptionSet/SSL_OptionGet for completely disabling TLS extension for a particular socket. Currently, NSS has an option for explicitly turning SessionTickets on or off, but other than that, an application can't control if TLS extensions are included or not.

The idea came up in a thread on the curl-library mailing list, where Kamil (Cc'ed to this bug) was proposing a patch to add logic for detecting TLS intolerant servers to curl (based on what PSM has been doing for a long time already):

http://article.gmane.org/gmane.comp.web.curl.library/25440

When looking at the two servers mentioned in this thread (www.orange.sk, tcs.mysap.com) in more detail, it turns out that they are not TLS intolerant, actually, but TLS *extension* intolerant. I.e., these servers freak out as soon as they see a TLS extension in the ClientHello (e.g., SNI, SessionTicket etc.).

Given the fact that more interoperability issues with TLS extensions are likely to appear in the future, I think it would be useful to have this option - for cases like the one in curl, where it is desirable to fall back to TLS 1.0 w/o extensions.

The attached patch is a first try at implementing this idea - at least for the client side, it was successfully tested by Kamil. (v2, which is attached to this bug, differs from v1 [as posted on the mailing list] only insofar as it has been updated for trunk, to accommodate for the recent checkin which adds DEFLATE support).

Nelson, could you review/comment? Bob apparently likes the idea, from what I understand :-)

[And yes, I'm aware of the fact that we'll probably very soon see a new TLS extension emerge, at least as an I-D, but at the time it will be implemented in NSS, the SSL_DISABLE_TLS_EXTENSIONS option could be revised to turn off renegotiation support as well...]

Comment 1

[Kaspar]

Attachment: Proposed patch

Oops... Bugzilla didn't pick up the patch with my initial submission, apparently. Here we go.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Bob and I discussed this specific case recently.  At issue (AIUI) is a certain
brand of server product that claims to implement TLS 1.0, but (reportedly) 
refuses to negotiate a handshake with any client that includes ANY extensions 
whatsoever in the client's hello message.  This is simply not RFC compliant.

I have also recently discussed with numerous members of the IETF TLS working
group the desirability (or lack thereof) of having mandatory TLS hello 
extensions, (of which the forthcoming TLS renegotiation extension is likely
to become one).  The WG seems to have accepted the inevitability of some 
hello extensions becoming mandatory.  This further seals the fate of any TLS 
implementation that rejects hellos bearing extensions.  More on this below.

NSS does not send any client hello extensions when it is sending an SSL 3.0
client hello.  Although the SSL 3.0 ID specifically allows extensions, we 
have found SO MANY SSL 3.0 servers that reject hellos with extensions that
we decided to consider extensions to be part of TLS only, and not SSL 3.0.
Consequently, when TLS is disabled, and NSS sends an SSL 3.0 client hello
in SSL 3.0 record format, no extensions are sent.  IMO, the server that 
brought this whole discussion about is essentially one of those old SSL 3.0
servers, and the right way to talk to it is to send it an SSL 3.0 client 
hello.

I believe that, soon, the forthcoming TLS renegotiation info hello extension 
will be effectively a mandatory hello extension for TLS clients. Servers will 
stop accepting hellos that don't have it.  And for that reason, I think this 
new option, to disable all TLS hello extensions, is inadvisable.  

So, my recommendation to the libCURL folks is: when talking to an alleged 
TLS server that rejects hellos with extensions, fall back to a mode in which
you disable TLS, leaving SSL 3.0 enabled, and try that.  I believe it will 
work.  There's no need to enable SSL v2-compatible client hellos (as PSM does).

Right now, ALL other SSL/TLS work is receiving less priority that the TLS 
renegotiation work.  I won't review this patch until that work is done.

Comment 3

[Kamil Dudka]

(In reply to comment #2)
> So, my recommendation to the libCURL folks is: when talking to an alleged 
> TLS server that rejects hellos with extensions, fall back to a mode in which
> you disable TLS, leaving SSL 3.0 enabled, and try that.  I believe it will 
> work.  There's no need to enable SSL v2-compatible client hellos (as PSM does).

Let me note there are also servers that "only implement and support TLS (SSL 3.1) and not also SSL 3.0":

https://bugzilla.mozilla.org/show_bug.cgi?id=239381#c8

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Sure, but if they reject all client hellos that have extensions, they're 
just BROKEN, not RFC compliant.

Comment 5

[Kamil Dudka]

Yes, and we are implementing a workaround for broken servers. If users have to communicate with a broken server, they are happy to use an option which makes it possible.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

That's fair.  I'll think about this as I work on renegotiation info.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Now that Bug 526689 is public, we can say aloud that servers that reject 
client hellos with extensions will soon be rejecting hellos from the majority
of clients, because the majority of clients will be sending the new 
renegotiation_info extension, and will soon be demanding that servers 
respond with them also.  Servers that cannot do that will be presumed to 
still be vulnerable to the renegotiation flaw.  So, I think the useful 
lifetime of such servers is going to come to an end pretty quickly,
and that implies that the useful lifetime of this socket option likewise
may be very short.  

But other than that, I don't oppose it. :)

I'll consider taking this patch (or rather, its successor) for NSS 3.12.6
after the renegotiation_info patch and compression patches have landed.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 410549 [details] [diff] [review]
Proposed patch

This patch doesn't apply cleanly to the trunk now because additional socket
options have already been added.  I suggest you wait until those other
patches have landed to make your next version of this patch, but then I 
don't foresee any problems for this patch.

Comment 9

[Kaspar]

(In reply to comment #8)
> (From update of attachment 410549 [details] [diff] [review])
> I suggest you wait until those other patches have landed

I merged my changes earlier this week with ssl.h r1.30 / sslimpl.h r 1.69 / sslsock.c r1.59 earlier this week, so I'm now at 23 for SSL_DISABLE_TLS_EXTENSIONS - should I expect further changes?

By the way, shouldn't SSL_REQUIRE_SAFE_NEGOTIATION be 22, for the sake of consistency?

When turning off extensions, I'll plan to set enableRenegotiation to SSL_RENEGOTIATE_NEVER and requireSafeNegotiation to false. Does that sound reasonable?

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

> shouldn't SSL_REQUIRE_SAFE_NEGOTIATION be 22, for the sake of consistency?

consistency with what?  The bit numbers in the bit field?  
No, those are merely coincidental.

Comment 11

[Kaspar]

Attachment: Patch v2 (work in progress)

(In reply to comment #10)
> consistency with what?  The bit numbers in the bit field?  
> No, those are merely coincidental.

Well, given the fact that those SSL_* constants primarily exist to control the bits in that field, it's probably not mere coincidence ;-) I noticed that there's a gap between 3 and 5, but it's also true that the "mapping" isn't 1:1 for some of the options.

Anyway, I've now changed SSL_DISABLE_TLS_EXTENSIONS to 22 and am attaching v2 of the patch, which should be considered work in progress. I have also included the respective changes for tstclnt/selfserv/strsclnt, so that this option can be used with them as well. Comments welcome, of course.

Comment 12

[Kaspar]

Comment on attachment 412463 [details] [diff] [review]
Patch v2 (work in progress)

Is there still an interest in adding this option? (I.e., should I update the patch?)

In theory, "extension-less" TLS is still possible with RFC 5746, at least to some extent: NSS as the client would just send the SCSV and use SSL_RENEGOTIATE_TRANSITIONAL for the time being (i.e., continue the connection with an unpatched server - the strategy which browsers are currently taking).

Comment 13

[Wan-Teh Chang]

I am not interested in the SSL_DISABLE_TLS_EXTENSIONS option.

Comment 14

[Kaspar]

WONTFIX, due to lack of sufficient interest (after comment 12).