Live data from Hacker News

The Security Impact of HTTPS Interception [pdf]

jhalderm.com

21–30 of 67 posts

Re: The Security Impact of HTTPS Interception [pdf]

#21
post #17
post #15

Earlier quoted context omitted.

The warning fatigue problem is still there - and we're talking about a warning for 4-10% of all connections according to the study. Plus, as you pointed out, this would only help against the average sysadmin; if we assume an advanced sysadmin convinced to not disclose their snooping or an actual attacker, replacing the browser binary would not be a huge obstacle. In that sense, it might even add a false sense of secu…

This figure of 4-10% of connections is meaningless here, either you're intercepted or you're not. The warning would only matter for websites that bother to implement certificate pinning. I don't really know how widespread key pinning is but if it's reserved to the more sensitive websites (banking, e-commerce etc...) it might make sense to at least issue a warning.

> This figure of 4-10% of connections is meaningless here, either you're intercepted or you're not. The warning would only matter for websites that bother to implement certificate pinning.

Most Google properties use key pinning in some form (though AFAIK through static pins rather than HTTP headers). I would suspect that most users in that group would see such a warning at least daily.

> I don't really know how widespread key pinning is [...]

"Visitors may be presented with a warning if they're behind a middlebox and you deploy HPKP" would probably be a good way to slow down HPKP deployment even further.

Re: The Security Impact of HTTPS Interception [pdf]

#22
post #8

I was surprised by this note (on page 2): > Contrary to widespread belief, public key pinning [19] — an HTTPS feature that allows websites to restrict connections to a specific key — does not prevent this interception. Chrome, Firefox, and Safari only enforce pinned keys when a certificate chain terminates in an authority shipped with the browser or operating system. The extra validation is skipped when the chain ter…

I believe that is mostly to support the corporate use case of being able to snoop all employees traffic. Now that Chrome features 'enterprise' deployment, maybe the default could be changed and only IT departments that specifically want this setting could have it on.

Re: The Security Impact of HTTPS Interception [pdf]

#23
post #18
post #8

I was surprised by this note (on page 2): > Contrary to widespread belief, public key pinning [19] — an HTTPS feature that allows websites to restrict connections to a specific key — does not prevent this interception. Chrome, Firefox, and Safari only enforce pinned keys when a certificate chain terminates in an authority shipped with the browser or operating system. The extra validation is skipped when the chain ter…

It's path dependence. Had public key pinning existed before companies started thinking of intercepting their internal TLS traffic, that wouldn't be an issue. But since TLS interception was already unfortunately common when public key pinning was developed, not having that exception would mean that nobody could ever use it, since it would mean instantly breaking whichever site enabled it. And in a certain way, users a…

> not having that exception would mean that nobody could ever use it, since it would mean instantly breaking whichever site enabled it.

That's the point...

Re: The Security Impact of HTTPS Interception [pdf]

#24
post #18

Earlier quoted context omitted.

It's path dependence. Had public key pinning existed before companies started thinking of intercepting their internal TLS traffic, that wouldn't be an issue. But since TLS interception was already unfortunately common when public key pinning was developed, not having that exception would mean that nobody could ever use it, since it would mean instantly breaking whichever site enabled it. And in a certain way, users a…

> not having that exception would mean that nobody could ever use it, since it would mean instantly breaking whichever site enabled it. That's the point...

The exception we're talking about exists primarily for computers owned by companies the likes of the Fortune 500, many of which have a regulated requirement to intercept TLS. If Chrome enforced pins against local policy, they'd simply use a less secure browser.

Re: The Security Impact of HTTPS Interception [pdf]

#25
post #13
post #10

Earlier quoted context omitted.

Trying to fight a local attacker with root (which is necessary to add a certificate to the trust stores on most platforms) isn't worth the effort. It's easy for the admin to bypass and would cause even more warning fatigue. That's not to say I disagree with the sentiment that this is something employers (and other organizations providing access to devices) should be obliged to disclose, but that is perhaps more of a…

> It's easy for the admin to bypass If it involves patching and recompiling the browser it wouldn't be that trivial for your average sysadmin. Besides I don't see why the admin would be hostile to the users being aware that they're being monitored. As you point out companies generally disclose that anyway.

No, sysadmins don't patch browsers. Endpoint security products do. Patching browsers to implement TLS interception is table stakes for security products. Local pin enforcement would in fact result in million more surreptitious browser patches.

Re: The Security Impact of HTTPS Interception [pdf]

#26
post #24

Earlier quoted context omitted.

> not having that exception would mean that nobody could ever use it, since it would mean instantly breaking whichever site enabled it. That's the point...

The exception we're talking about exists primarily for computers owned by companies the likes of the Fortune 500, many of which have a regulated requirement to intercept TLS. If Chrome enforced pins against local policy, they'd simply use a less secure browser.

Personally I'd be happy to DoS my sites by breaking them when policy MitM is used, as an act of solidarity. I even wrote a half-joking spec for it: https://hlandau.github.io/draft-landau-websec-key-pinning-re...

Seems like it should be feasible to develop modules for HTTP frontends to detect policy MitM based on the techniques described in this article and enable conditional denial of service.

Re: The Security Impact of HTTPS Interception [pdf]

#27
post #8

I was surprised by this note (on page 2): > Contrary to widespread belief, public key pinning [19] — an HTTPS feature that allows websites to restrict connections to a specific key — does not prevent this interception. Chrome, Firefox, and Safari only enforce pinned keys when a certificate chain terminates in an authority shipped with the browser or operating system. The extra validation is skipped when the chain ter…

The arguments around this-- and the people who make them-- have always disappointed me. The expectation that we've drilled into users' heads is that when they see the lock icon their traffic is private. That is not the case, and we could warn them about it, and we don't. In my eyes that's a failure.

The arguments around warning fatigue are specious. The exact same mechanism that currently sets the number of warnings you get due to a pinning failure stemming from a user added certificate to 0 could easily make it 1 instead, or be tied to a "don't show me these warnings again" checkbox. Experimentation and data could determine whether and to what degree this was effective, as is routinely done with related warnings changes that have far less potential upside. But when you bring up the possibility of solving the question with real data the argument morphs into pure philosophy.

The philosophical points are twofold: first, a claim already raised here that fighting local admins is pointless because they'll always win and you don't want to get into an arms race. I attribute this to the fact that browsers developed on poorly sandboxed desktop platforms where admins are de facto root and no intelligent statement of any kind can be made about limitations of their behavior. On those platforms this isn't a crazy approach (although its shoulder-shrugging fatalism is distasteful to me even there). Fortunately, those aren't the only platforms we have today: on systems like Android the expectation is that corporate admins act through narrow, carefully controlled channels and will have no powers beyond those. There, the platform wins arguments with admins pretty much all the time. The arms race was over before it began. Without the risk of escalation from admins, the only question is whether the user is properly aware of the consequences of having had an extra CA added to their trust store, and again I refer to the point I made above: this can be settled with data. Rather than bend over backwards to give admins the benefit of the doubt, let's gather actual data on the degree to which users are comfortable with this behavior. And if they aren't, well, then the admin is an adversary and we have a duty to protect the user.

When you make this argument however the discussion becomes /really/ philosophical: people will start saying that limiting admin powers is anti-user-freedom, despite the fact that the user of the device clearly has a greater ability to make decisions for themselves about their security than in the free-for-all common to platforms of yore. Why that matters in this discussion is beyond me: even if you subscribe to this belief the horse is out of the barn and no amount of smugly screwing users will fix that. And some will assert that admins are users too, and that we need to serve those markets well. But the fact that people will give you money does not mean you should take it: if the data gathered above indicates that users do not want their traffic intercepted then that, in my mind, should be final-- if the amount of money on the other side convinces members of the security community to hurt users then in my view we should just give up the pretense that we're the good guys.

Re: The Security Impact of HTTPS Interception [pdf]

#28
I’m surprised by the contrast between the best products in each category and the average standard. The few good ones show what is possible, yet the vast majority seem to be sub-standard or outright dangerous. I wouldn’t have been surprised by the odd outlier where someone dropped the ball, but I expected much higher general standards.

Re: The Security Impact of HTTPS Interception [pdf]

#29
post #25
post #13

Earlier quoted context omitted.

> It's easy for the admin to bypass If it involves patching and recompiling the browser it wouldn't be that trivial for your average sysadmin. Besides I don't see why the admin would be hostile to the users being aware that they're being monitored. As you point out companies generally disclose that anyway.

No, sysadmins don't patch browsers. Endpoint security products do. Patching browsers to implement TLS interception is table stakes for security products. Local pin enforcement would in fact result in million more surreptitious browser patches.

Maybe on windows. Do you know of any Android security products which do this? Why does Chrome for Android not implement this?

Re: The Security Impact of HTTPS Interception [pdf]

#30
post #26
post #24

Earlier quoted context omitted.

The exception we're talking about exists primarily for computers owned by companies the likes of the Fortune 500, many of which have a regulated requirement to intercept TLS. If Chrome enforced pins against local policy, they'd simply use a less secure browser.

Personally I'd be happy to DoS my sites by breaking them when policy MitM is used, as an act of solidarity. I even wrote a half-joking spec for it: https://hlandau.github.io/draft-landau-websec-key-pinning-re... Seems like it should be feasible to develop modules for HTTP frontends to detect policy MitM based on the techniques described in this article and enable conditional denial of service.

There's another way to do that: require client certificates. The MITM proxy cannot present the client certificate to the server, since it doesn't have the corresponding private key.

Unfortunately, the user interface for client certificates is a complete pain, so they are rarely used. But they're the only true way for a server to make sure it's talking directly to a client, in the same way server certificates can allow a client to make sure it's talking directly to a server.

Post reply on HN