Re: Moving forward on improving HTTP's security

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
>

Received on Thursday, 14 November 2013 16:47:50 UTC