RE: 9.2.2, Rough Consensus, and Working Code

This is precisely our situation as well.  Our defaults are good (though our default for in-market versions aren't actually 9.2.2 compliant either; see http://support2.microsoft.com/kb/2929781 for the fully-patched Server 2012 R2 order), but we have the ability for the admin to make changes, removing or reordering as they like -- and we know that many do.  Some move lower-overhead suites higher in the list to boost throughput; others move the stronger suites to the top because they want the best security possible; still others do local swaps of two ciphersuites because there's a known bug in some client's implementation they want not to encounter.

Regardless, we don't want to constrain that ability by saying that the HTTP-layer MUST sniff out what happened and kill connections that actually work the way the admin has decided they want.  We're happy for MUST support, fine with SHOULD prefer, but enforcement will create some combination of operational breakage and confused admins.

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: Thursday, November 6, 2014 10:27 AM
To: Yoav Nir
Cc: HTTP Working Group
Subject: Re: 9.2.2, Rough Consensus, and Working Code

On Nov 6, 2014, at 9:12 AM, Yoav Nir wrote:
>> On Nov 6, 2014, at 2:37 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
>> 
>> More to the point, they do implement HTTP, and the chartered goal of 
>> this working group is to produce a protocol that they will be willing 
>> to adopt as a replacement for HTTP/1.  If you want to change the name 
>> of the protocol to TLS+, feel free to do so and ignore the existing 
>> implementations.
>> 
>> I know Apache httpd won't be implementing 9.2.2 because the 
>> HTTP-aware code doesn't even get involved in connection activity 
>> until after the first HTTP message is received.  Furthermore, there 
>> is no way of knowing if an external device is securing the connection.
>> When we do have an implementation of HTTP/2, it won't be limited to 
>> TLS for the same reason HTTP/1 isn't limited to TCP.
> 
> Does this mean that Apache won't be enforcing the TLS requirements at all? IOW, if the configuration string for OpenSSL allows TLS_RSA_EXPORT_WITH_RC4_40_MD5 negotiated over SSLv3, httpd will be fine with this cipher and version?

The httpd interface to TLS tries to encompass many different libraries.
To the extent that such algorithm choices are available to the server, the configuration files for TLS allow the administrator to select them.
It doesn't have anything to do with the HTTP filters within httpd (the code that actually implements HTTP standards).

We occasionally disable choices within the TLS interface that have known security vulnerabilities, but we generally prefer secure defaults and shoot-your-own-foot flexibility (due to the universe of legacy platforms that httpd wants to run within that don't always have the latest features).
However, I can't really say what the SSL interface will likely support, since it is orthogonal to HTTP and depends on exactly why TLS has deprecated a given feature.  If you want to know what Apache httpd will support for HTTP/2 communication, look at what it supports for HTTP/1.

Generally speaking, if people think something is insecure of HTTP/2, it would be foolish to continue using that for HTTP/1.  However, we still need to allow such options to be configured because one of the roles of an HTTP server is to provide access to software updates.
Hence, in some circumstances, backwards compatibility does override specific security concerns because the alternative is less secure in general.

These choices are made prior to any connection, regardless of the protocol used on top of TLS.  Terminating the connection just because the client successfully negotiated a variation of TLS that isn't good enough for 9.2.2 is a stupid idea because it places me in the position of overriding the administrator's deliberate choice to configure some other (non-default) choices for TLS.  I cannot possibly guess why they made those choices, since it depends on the environment in which they are operating and the purpose of the content served.  In contrast, I know all too well that 9.2.2 is nothing more than a punt by browser vendors and a political statement by folks who have no operational responsibility.

....Roy

Received on Thursday, 6 November 2014 20:09:13 UTC