Re: Moving forward on improving HTTP's security

Hi William,

On Wed, Nov 13, 2013 at 04:09:33PM -0800, William Chan (?????????) wrote:
> On Wed, Nov 13, 2013 at 2:36 PM, Adrien de Croy <adrien@qbik.com> wrote:
> 
> > I thought we already did the mandatory TLS argument to death many times.
> >
> 
> We did :) And I don't think we're going to convince one another here. I
> feel like I understand your position and disagree with it. And I think the
> vice versa is true. I stated my preference earlier, but I don't expect to
> convince you. As much as it'd be nice to have the spec mandate this, so I
> could use it as a weak hammer to beat people on the head with when they
> don't want to use TLS, I don't really think we'll achieve rough consensus.
> But I'll impose my will insofar as I can affect Chromium policy and push
> more HTTPS adoption as much as I can.

Working groups are precisely the places where educated people learn from
others that what they thought they knew was not exactly true and tend to
make better collective choices than isolated ones. And if you, with your
choice *alone* were making a mistake, how many users would that affect ?

I remember talking with Mike in Paris about the use of gzip compression
in SPDY and HTTP/2. I disagreed for performance reasons. Mike preferred
to stay on gzip than other algos such as LZ4 because gzip is standard and
deployed everywhere. Our disagreement was purely based on the technical
quality of gzip for this, none of us thought about any possible security
implication.

Then came that BEAST attack making smart use of compression to guess
clear text by only observing the on-wire compressed & ciphered size.
We discussed this privately afterwards and both of us admitted that
it was *the* good reason for not doing it this way and that both of
us would have failed by picking either algorithm just because of the
nature of the vulnerability that we overlooked in our "battle" for
what algorithm was more suited to the task.

All that to say that it's fine to have ideas, it's fine to have opinions
and to defend them, but in the long term it can serve you and your users
even better if you push less hard and let some of your other team members
share their point of view, fears and doubts, which in the end might result
in strengthening your choice or on the opposite reconsidering it, but at
all times further improving your products.

Sadly your comment above makes me feel like this browser became *yours*
and reflects your sole usage instead of the ones of a group, which can
be counter-productive in the long run. But probably this was just a
wording mistake or just a sign of excess of enthousiasm.

> > We added MITM in WinGate mostly because Google and FB went to https.
> >  Google and FB you may take a bow.
> 
> FWIW, I'm happy those companies went HTTPS, and I'm sad that y'all are
> offering MITM features in your products. I suppose that if I ask you not to
> MITM traffic, you wouldn't listen, would you? :P If you feel that MITM is
> bad for the web, why are you implementing this? Is it simply because if you
> don't, then someone else will and people will switch from your product?

Sometimes when you're requested to do something you don't agree with for
various reasons, you can at least help do it the least detestable way. Eg:
there are many valid use cases for MITM right now and when you're asked to
design this and you have some consideration for privacy and security, you'll
probably try to educate the customer to only route the connections with
certain SNIs to the MITM proxies and not the rest (just an example).

If at least it's enough to allow a school to give internet lessons to young
kids and force "safe search on" on Google images, it will be a good point.
And if the teacher uses the same PCs to connect to his/her bank account,
you probably don't want the solution you design to be able to MITM that
at all and you'll design it so that this cannot happen by accident.

> > Does this improve security of the web overall?  IMO no.  People can now
> > snaffle banking passwords with a filter plugin.
> >
> 
> Just to be clear, the MITM works because the enterprises are adding new SSL
> root certificates to the system cert store, right? I agree that that is
> terrible. I wouldn't use that computer :) I hope we increase awareness of
> this issue.

And are you certain that you're not already having such CAs in your
phone that allow your mobile phone provider or one of its subsidiaries
to decipher your traffic just because it allows them to cache contents
and score better in page load speed when compared to competitors ?

> > You really want to scale this out?  How will that make it any better?
> >
> 
> I believe that making communications secure by default will overall improve
> the security of the web as long as most devices don't have these additional
> SSL root certificates used by the MITM proxies.

But that's the key point. If some companies are paying millions to have
these features, surely they don't do it for fun. What is irresponsible is
to declare their needs do not exist and refuse to talk to them on the sole
basis that they do something you disagree with. I'd rather try to enumerate
all the reasons why they're doing this and see how we can cover most of
them and how we can help them not need the remaining ones (even by pushing
for changing laws sometimes).

> You are taking a cynical
> view on the outcome when communications become secure by default.

No, Amos is realistic because he has seen the people who do this. Have you
ever met these people ? Have you ever worked for a customer in a hosting
company or at an ISP's ? I think not that much, otherwise you would be
less certain about yourself on these points because you'd have seen that
what you claim will not happen is already being done almost everywhere
because of the same reasons several people here have repeated over and over.

> I disagree. I think that it's worthwhile to force entities that want to
> examine communications to have to MITM SSL. I think that the negative PR of
> a government or ISP or whatever trying to force installations of additional
> root certificates on end users' machines would be a strong disincentive to
> employ these policies. I agree it might lead more enterprises to MITM their
> employees who use corporate devices. It is a sad world indeed if it's the
> status quo for everyone to use devices with extra root certs so
> intermediaries can MITM SSL connections.

In my opinion, as soon as we'll accept that MITM is something that some
companies *need* and which is currently being done the most insecure way,
we'll make a great progress because we'll design a protocol so that it is
possible with the users' knowledge, consent, and choice of sites. Only
after that we can try to think about the remaining cases (eg: dealing with
cert errors for every site that doesn't care).

> > You're suggesting anyone wanting to run an http2 server now has to
> > purchase, and pay for the ongoing maintenance of a cert, and take the cost
> > on additional CPU to handle the load?
> 
> Yes, I want to use HTTP/2 as a carrot to incentivize server operators to
> use HTTPS. There are tradeoffs that prevent folks from adopting HTTPS. I'm
> hoping HTTP/2 helps adjust the tradeoffs in HTTPS' favor somewhat, due to
> its reduced user perceived latency and improved connection reuse leading to
> improved scalability compared to HTTP/1.X over TLS.

I agree it can significantly help which is why Mark's proposal can make
sense to some extents. But at the same time I know a number of places
where it will not be accepted at all to multiply the number of servers
for cost and maintenance reasons.

> > Organisations have to live with the pain in the neck of deploying signing
> > certs to clients, dealing with visitor devices etc etc.  This = reduction
> > in user experience.
> >
> 
> You mean the additional root certs installed on client machines? Good, I'm
> glad it's a PITA for y'all, so maybe you'll stop doing it or do it less
> often, and maybe corporations will stop asking you to do this for them.

Do you *really* think that a company changes its behaviour regarding laws
or bandwidth because one guy says "hey, chief, could you please tell your
chief to tell his chief to tell his chief to tell his chief to tell his
chief to tell his chief that it's a PITA to install certs on customer's
machines" ? No. The guy at the top says "we must comply with laws and not
waste bandwidth". The guys below know they need to log. Other ones can
only cache because there's no provision for adding more fibers in the
ocean. Etc... And at the bottom, there is you. The guy who's tasked for
helping them design an MITM cache so that their customers can still have
some internet despite the wires being overly saturated.

> This is terrible and I'm personally not interested in making it easier for
> organizations to snoop on their members/employees/students/etc.

We're not speaking about making it easier for them but making it safer
and visible for the end user. *That* is a difference. Maybe some guys
would not have been killed in some countries if they knew they were
snooped when planning their meetings for some riots. Unfortunately, due
to some of the next web designers (us) being stubborn and denying reality,
users still have no way to know if their connection is safe or snooped
these days. That's sad.

> I'm in
> favor of reduced user experience where the user is someone who wants to
> MITM SSL traffic.

That's what several of us already proposed several times ago in the past
and I think it's an acceptable trade-off : "we offer you some free WiFi
access which logs everything but it's not as fast as a transparent one,
unfortunately we have to comply with local laws. Be careful not to access
sensible sites".

Best regards,
Willy

Received on Thursday, 14 November 2013 01:10:08 UTC