Re: Moving forward on improving HTTP's security

On Wed, Nov 13, 2013 at 5:09 PM, Willy Tarreau <w@1wt.eu> wrote:

> 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 ?


Just to be clear, I'm not ignoring your comments. I merely stated in
response to the comment that, yes, we've discussed this before, and no,
nothing's really changed. We understand each other's positions and
information as already shared with this working group. And taking that into
consideration, I respectfully disagree with your (intermediary folks)
stance. And you guys are going to MITM traffic even though I think you
shouldn't. I'm just being realistic about the current state of affairs.


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

Hm, it's not clear to me what you mean here. I certainly am not the
Chromium dictator, as much as that would be awesome :P I just affect
project policy to the degree which I have influence, which is generally how
it works in an organization. And I've stated for you what policy I try to
effect is. Anyhow, if you don't mind, I'd rather not make this discussion
about me. I spend far too much time talking about myself.


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


I disagree with the use of MITM to achieve these ends. I think we don't
need to break end to end security to achieve these goals. As an example,
here's a Chrome feature to provide parental controls rather than implement
them in a MITM proxy: http://www.bbc.co.uk/news/technology-24635752.


>
> > > 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 ?
>

I'm reasonable confident because I use an Android Nexus phone receiving OTA
from Google. If Google's installing additional certs, I will likely throw a
fit and call them out on it.


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

The key point, as Pat noted, is that the majority of users don't have these
extra root certs. I never said these organizations' needs do not exist. I
just disagree with their using MITM as the mechanism to achieve their goals.


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

No, I believe I said I recognized the likelihood that enterprise adoption
of MITM proxies would increase.


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

We've been thinking about this stuff. Security UI is hard =/


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