Re: Mandatory encryption

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

#5 goes up with TLS, in the short run, though in the long run this isn't
necessarily true if we use a long-lived multiplexed thing on tip of it-- at
least for less optimized stuff that allows the kernel to handle accept(),
etc. It is easy to forget about the cost of dealing with multiple
connections at the system level in the server.
For highly optimized proxies such as haproxy TLS will likely end up a net
cost, no question.

For #4: This is typically indicated by use of the http scheme. If one used
TLS in transporting such a query, the browser should not be in the business
of server auth-- there should be no chance of a cert warning. If you get
point-to-point privacy without auth here, it is strictly better from a
security perspective, even assuming TLS's trust chain is compromised.

#3: TLS does help with this, even without authentication. It isn't perfect,
but it is better than http by quite a bit.

#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.

-=R
 On Jul 18, 2012 12:16 AM, "Willy Tarreau" <w@1wt.eu> wrote:

> On Tue, Jul 17, 2012 at 11:54:00PM -0700, Mike Belshe wrote:
> > > The issue with HTTP/2 will indeed be the same as with IPv6 : HTTP/2
> will
> > > be deployed between the browser and the load balancer, and everything
> > > behind will remain HTTP/1 due to the added nuisances of deploying 2.0
> > > everywhere. Almost nobody does IPv6 between LB and server nowadays,
> it's
> > > added cost for no benefit.
> > >
> > > This will force us to continue to support the crappy parsers of 1.1
> > > forever and not to have MUX between the LB and the server, and that's
> > > precisely the situation I'd like to avoid, by having a protocol which
> > > *supports* more privacy but does not impose it where it's not expected.
> > >
> >
> > This is not true; you can use whatever you want in your backoffice.  I've
> > talked about this many times before, with or without TLS; whatever you
> > want.   It's the browser channel which will be TLS only.
>
> That's why I want the protocol not to rely on TLS but to be
> self-sufficient.
> If we can use HTTP/2 over TCP then I can disable TLS in the backoffice.
> Otherwise I cannot and am forced to use HTTP/1 instead.
>
> > > I'm really against making such a thing mandatory because it will only
> > > improve privacy on a few services which actually do not need it and
> will
> > > globally deteriorate the overall security by lowering the level of
> control
> > > of users.
> > >
> >
> > We just disagree.  And I keep going back to the same argument over and
> over:
> >
> > Show me the user that will stand up and say, "Yes, I would like my
> > communications to be snoopable and changeable by 3rd parties without my
> > knowledge."
>
> I am one of these users. When I'm browsing in clear text, I know my
> communications are snoopable and changeable and I don't care. When I
> care I use https. Using cleartext has many benefits for me as a user.
> It's faster and I don't have to constantly click "I accept" on every
> pop-up that is raised due to too difficult certificate management for
> the server, or the mess of keeping a CA list up to date.
>
> So I am one such user who doesn't want to be forced to face all the
> discomfort of TLS when it does not make sense. TLS for no reason is
> already badly used, there is no reason it will suddenly become better
> when made mandatory. It's the opposite, sites having it good will not
> improve and remain the same, but the number of sites which will have
> to deal with it when not expected will increase the number of false
> alarms on the user side. We don't want to accustom users to blindly
> click on this warning anymore.
>
> Willy
>
>
>