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 18:27:43 UTC