W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Mandatory encryption

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 19 Jul 2012 11:39:01 +0200
To: Roberto Peon <grmocg@gmail.com>
Cc: Paul Hoffman <paul.hoffman@gmail.com>, Phillip Hallam-Baker <hallam@gmail.com>, grahame@healthintersections.com.au, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Mike Belshe <mike@belshe.com>
Message-ID: <20120719093901.GB16208@1wt.eu>
Hi Roberto,

On Wed, Jul 18, 2012 at 10:31:30AM -0700, Roberto Peon wrote:
> There are number of technical issues here.
> 1) speed of experience
> 2) deployability of protocol
> 3) privacy against wireless sniffers (I call this point-to-point privacy)
> 4) authentication of the server to the client.
> 5) runtime cost
> 
(...)
> #2: Experience has shown, unfortunately, that deploying something new from
> browser to server is either extremely difficult or unreliable. That is the
> only case where mandating anything like TLS makes sense to me.
> 
> #1 isn't obvious one way or another. For the first request TLS potentially
> harms latency as compared to http/1.1. For subsequent requests it comes out
> as better (given application protocol changes). More interestingly,
> negotiating http/2 over port 80 will require a round trip, which is the
> same latency penalty one will pay for using TLS at a site that you have
> recently visited assuming we use false-start.

For the two points above, I get your point but partially disagree. As we
discussed in another thread on HyBi a few years ago, I have experience of
a number of places where proxies don't allow TLS to pass through for filtering
reasons.

For instance, one of my customers doesn't allow HTTPS to google.com for a
simple reason : in HTTP they always force safesearch to on in outgoing
requests so that they rely on google's ability to filter out unsuitable
contents. In HTTPS they obviously can't do this so google images then
becomes a single-handed browsing tool. So they don't allow HTTPS on this
domain.

The effect is that connections from the browser to google cannot use SPDY
over port 443 right now and this is not going to change for a long time
due to internal filtering policy reasons.

So outgoing connection attempts to use port 443 will have to fall back to
use port 80 instead (second round trip) while the Upgrade would pass on
the same connection.

TLS is a valid transport to join many directly connected users but is not
very practical for people in enterprises unfortunately. What I'm opposed
to is to force such users to choose between HTTP/2.0 and HTTP/1.1 instead
of choosing between clear and encrypted as they're doing right now. Because
whatever the transport we choose, we're designing HTTP/2.0 to provide much
better end-user experience to users and we should not condition this to
the ability to pass over port 443.

Regards,
Willy
Received on Thursday, 19 July 2012 09:39:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 July 2012 09:39:51 GMT