-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 13/01/2015 2:35 p.m., Constantine A. Murenin wrote:
On 2015-01-12 16:30, Willy Tarreau wrote:
Hello,
On Sat, Jan 10, 2015 at 12:09:38AM -0800, Constantine A. Murenin
wrote:
I am sincerely asking for the IETF to not approve HTTP/2 as a
standard without the compatibility issues as above being
addressed first. The policy to abandon the http:// address
scheme and adopt https:// will only promote a significant link
rot for the future generations to experience well into the
future (didn't we think TLS 1.0 was good enough?), and will
curtail independent and hobbyist operators.
Please note that the protocol *does* support http:// address
scheme, it's only that two browsers decided that they will not
implement it. Let's hope that they'll change their mind when
HTTP/2 starts reaching normal users and is no more limited to
huge sites with lots of people to manage certificates.
Has this been changed since the publication of
http://queue.acm.org/detail.cfm?id=2716278, which claims that it's
3 out of 4 major browsers that will only do HTTP/2.0 with TLS?
Nothing has changed. You just seem to be slightly misunderstanding the
situation.
The protocol spec defines both http:// and https:// on equal footing
for HTTP/2 just as they were for HTTP/1. As Willy mentioned.
Those browsers have chosen (for now) to ignore whole sections of the
specification and the WG chartered requirements that HTTP/2 to be
usable in *all* use-cases where 1.1 was. By vehemently not
implementing that support and forcing their users through all those
problems you describe (I pity their users but karma will have its way).
PHK, and others including myself, are at the other extreme of the
spectrum not implementing https://. Though we have not been refusing
to ever do so (that just seems a stupid claim to make).
It is a reflection on some implementers arbitrary choice to ignore the
specification text (er, "forever"). Not an explicit lacking in the
specification itself. It makes little sense for a protocol to say
"MUST implement this specification". But it does make for an
interesting birth to the new protocol.
PHK>>>> Yet, despite this, HTTP/2.0 will be SSL/TLS only, in at
least three out of four of the major browsers, in order to force a
particular political agenda. The same browsers, ironically, treat
self-signed certificates as if they were mortally dangerous,
despite the fact that they offer secrecy at trivial cost.
Regardless, this doesn't change the fact that HTTP/2, as proposed,
lacks soft upgrade/downgrade provisions -- from the server side,
you either have to carry the whole pre-HTTP/2 SSL/TLS baggage,
pre-TLSv1.2 and all, or not deploy HTTP/2 at all; else, some of
your customers won't be able to access the site at all, after they
get the https:// links from customers that do.
This wouldn't have been the case with opportunistic encryption.
It would have ensured full protection against passive monitoring
attacks, in compliance with Best Current Practice 188. HTTP/2 does
nothing to combat the widespread passive monitoring.
This is incorrect.
Soft upgrade/downgrade in https:// is done with ALPN and the reason
why that TLS feature is now mandatory for https://.
Soft upgrade in http:// is done via HTTP Upgrade mechanism same as
with HTTP/1. The sad reality that it lacks widespread HTTP/1.1
implementation support to actually perform the switch does not detract
from its existence as a feature in the protocol and potential use when
opportunity presents it. Its active use by HTTP/2 implementations to
transition should also improve the environment/availability for
opportunistic upgrades.
The TLS/SSL baggage needing to be implemented is no different for
HTTP/2 as for HTTP/1.x. The expectation is that the baggage
requirements become smaller over time. After the events of the past
few months in particular all the SSL baggage should not be an issue
for any HTTP/2 implementation and the TLS built-in upgrade mechanism
is actively minimizing the remaining legacy issues.
The HTTP/2 does change the BCP 188 state over HTTP/1.1:
* explicitly forbids use of the crypto schemes currently known to be
(or expected soon to be) vulnerable to monitoring.
* multiplex+compressed traffic raising the difficulty bar to passive
monitoring identifying any given client from packet statistics through
intermediaries.
* provides extensibility points for future strong cryptography even
in the "clear-text" HTTP/2 connections.
* provision to opportunistically remove (or compress away) features
of HTTP/1 used as client identification/signature footprints by monitors.
* lack of opportunistic downgrade for http:// raises the difficulty
bar for active attackers to impose a weak HTTP/1.x environment on
clients initiating native HTTP/2.
It also does a few things which lower the bar in some ways if
implemented (TLS ALPN, and the native magic prefix can still be hijacked).
So your assertion that it "does nothing" is incorrect. It does what
can be done in HTTP at this point in time. True it is just a small
improvement, but non-zero.
Amos Jeffries
Squid Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUtJuoAAoJELJo5wb/XPRjh9cH+QFm3Nv+jJ6YJGWr1VEbDr6T
h2vSet/JfR92MR9TC0S1CKn2lEN1XQ1wyHB+7BHjn0pYCUcrg5qv1jorI5CbS8ci
a1o/PYb3T30DAAjCUeacinc3ZgECeDWHuCJxLODsXDffq8Hn+jp5lfxBT3t67Dj0
nmg2zIWO+77CiHd8BpgfPjxRq4lp192bgARPr2Y/4OFADV9zKRrDM7H8KuoswG/V
sPeAEx+48c745swXN7042k+KmHk0KG8rIyO8+j6eqSjs+kx6wnS2380AQJ1DQsXG
m2rDWEw2H8XUjOgHEg+PopIHo/WMBUsNSIz5PtqSYjT8sJ0bOThTCSy3RIWfQUo=
=7vN9
-----END PGP SIGNATURE-----