Re: Moving forward on improving HTTP's security

Assuming that HTTP/2.0 will be successful (and I hope that to be the case), and assuming that people here care about security (sure seems like it from the volume of mail in the last few days, slashdot story, etc.), HTTP/2.0 needs to actually address how you make a secure implementation of it - that means going beyond mandating TLS - (mutual) authentication, validation, etc.  Security != TLS.

Saying “use HTTP/1.1” doesn’t actually help, since the same security issues that HTTP/1.1 faces today are the issues that HTTP/2.0 will face tomorrow.  

We should also answer the question: what problems is HTTP/2.0 trying to solve?  Are we just concerned with public web browsing, or is the WG trying to make a better version of HTTP/1.1 that can be used in all of the same situations?  Based on the charter I honestly thought that the point of HTTP/2.0 was the latter, but it seems like everyone is just afraid of what the NSA/GCHQ/insert-acronym-here is doing or will do with the bits flowing over the Internet. Clearly that is an important new data point that will influence the design of future protocols, but slapping TLS on HTTP/2.0 or forcing people that can’t/won't use TLS to HTTP/1.1 is security theater, not secure protocol design.





On Nov 14, 2013, at 11:46 AM, James M Snell <jasnell@gmail.com> wrote:

> While this is a perfectly valid argument, so far the response from the
> folks championing mandatory TLS seems to be, "Well then, just keep
> using HTTP/1.1 then". In fact, that exact sentiment has been voiced
> several times in this thread.
> 
> - James
> 
> On Thu, Nov 14, 2013 at 8:41 AM, Michael Sweet <msweet@apple.com> wrote:
>> Printers are a classic example of how the PKI/CA system is not ready for providing TLS support for the IoT.  Most printers don’t have stable addresses or hostnames.  The closest you’ll get is the mDNS hostname, e.g., vendorxxxxxx.local., which makes it hard to deploy CA-signed X.509 certificates, either by the vendor or the customer.  So that leaves you with self-signed certificates, usually generated by the printer itself when the customer clicks on the button that turns on TLS support.
>> 
>> In order to provide authentication of the printer you are sending to (to avoid leaking confidential information, for example your latest blood test results), clients currently can perform certain operations (either an “identify” operation that makes the printer beep, flash, and/or display a message, or a simple print job that can be used to confirm things) to establish a minimal level of trust, much like you’d do when pairing with a Bluetooth device. This pairing is *not* foolproof - a MITM proxy could still intercept and forward these pairing operations and the user/client would be none the wiser - but it *does* help prevent passive monitoring and subsequent MITM/impersonation attacks and is probably the best we can do today (for printers at least).
>> 
>> The point of all this is just that adding/requiring TLS for HTTP/2.0 does not, by itself, make HTTP/2.0 more secure, and that deploying TLS properly is not as simple as clicking a button.  Last week the prevailing assumption was that “active attacks are too expensive”, but in the last couple days we have discovered that assumption is not correct and that MITM proxies are widely deployed already.  Addressing that is likely far outside the scope of the HTTP WG, but clearly we can talk about the security considerations, recommend TLS as a general technology that can be used (with caveats) to enhance the security of HTTP/2.0, but leave ourselves open to existing (VPN, IPSEC, etc.) and new security technologies by requiring http:// support (no TLS).
>> 
>> We could also work with the HTTP Auth WG to define a common mutual authentication framework (IIRC there are a couple drafts on the table already), possibly one that identifies all parties in the chain (yes my hands are waving, I don’t know whether that is possible/feasible).  This could work for both http:// and https:// URLs and potentially help solve some trust/validation issues for TLS.
>> 
>> 
>> 
>> On Nov 14, 2013, at 5:48 AM, Nicolas Mailhot <nicolas.mailhot@laposte.net> wrote:
>> 
>>> 
>>> Le Mer 13 novembre 2013 22:54, Willy Tarreau a écrit :
>>>> When certs are
>>>> needed to connect to my printer, I doubt I'll have to order a new
>>>> cert every year to connect to it once every 3 years at most to change
>>>> its IP address.
>>> 
>>> Printers are a big equipment. People are already connecting lightbulbs for
>>> christsakes (did not one here hear about the Internet of things stuff? I
>>> can tell you it is happening, I see the first parts in my proxy traffic).
>>> There is no way in hell the current PKI/CA system can scale to this number
>>> of devices no one really wants to secure anyway without making
>>> certificates effectively meaningless (and my bank would disagree with
>>> this)
>>> 
>>> And make a protocol revision supposed to be future-proof for at least a
>>> decade depend on this system when it is already broken ? Madness
>>> 
>>> TLS is not advocated for security or freedom values it is advocated by big
>>> websites operators like Google who resent anyone interfering with the
>>> control they have of their visitors now. It's giving big brother a bigger
>>> stick because who the hell can even pretend Google-enduser relationship is
>>> remotely balanced. (replace Google with any of the other Internet giants,
>>> none of those is free from the temptation to abuse a direct
>>> in-controllable link to end-users, and Snowden showed).
>>> 
>>> This is quite transparent in the latest exchanges "small fishes will
>>> continue to use http/1, we want tls+http/2 for out giant monitoring
>>> platforms, and btw revisiting cookies? Forget about it"
>>> 
>>> --
>>> Nicolas Mailhot
>>> 
>>> 
>> 
>> _______________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>> 
> 

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Thursday, 14 November 2013 17:09:45 UTC