Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Security Impact of HTTPS Interception [pdf]

jhalderm.com

Post reply on HN
Print view View original

31–40 of 67 posts

Re: The Security Impact of HTTPS Interception [pdf]

#31

Post by LogicX »

I'll jump on my current soap box, which is that we need a standard to allow MITM blocking, without interception, and a nicer user experience.

This won't solve all use-cases, but selfishly, It will solve mine at DNSFilter: If a browser could recognize our SSL cert, or a special field in our cert, and present the user with a block message, and a static link to learn more, it would eliminate the need for us to have our customers install a CA of ours, and MITM traffic. We have not yet done so, and I'd prefer not to, but it seems to be the industry standard way of avoiding users being confused by errors when we block/MITM an SSL site.

Re: The Security Impact of HTTPS Interception [pdf]

#32

Post by arkadiyt »

simias wrote: 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…

Fun fact: the google engineers responsible for this decision were repeatedly accused of being NSA plants as a result: https://twitter.com/sleevi_/status/668911789841608706

Chris Palmer also wrote a really great blog post about this: https://noncombatant.org/2015/11/24/what-is-hpkp-for/

Re: The Security Impact of HTTPS Interception [pdf]

#33

Post by the8472 »

pfg wrote: post #10
simias wrote: 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…

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…

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

Hah. That's precisely the argument I have made when arguing that there should be an opt-out for addon signature verification (needing admin permissions to toggle it if they insist) because you already utterly lost the security game if someone had admin on the machine.

But no, they argue that they must defend against malware with admin permissions injecting addons into the browser. Because that's a fight worth fighting and the perception of the browser's security is somehow more important than user freedom.

Re: The Security Impact of HTTPS Interception [pdf]

#34

Post by the8472 »

simias wrote: post #13
pfg wrote: 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.

Adding certs to root stores does not require recompiling the browser.

Re: The Security Impact of HTTPS Interception [pdf]

#35

Post by zeveb »

simias wrote: 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…

Android does what you want, and I hate it. Every time it starts up it notifies me that a third party could be intercepting my traffic (because I've installed one of my own root certs). Of course, I'm not a third party, but there's no way for me to make my phone's OS know that I trust myself.

Meanwhile, of course, if someone did install a third-party root cert on my phone somehow, I'd never know because I always ignore & dismiss the wolf-crying warning.

The fundamental reason I disagree with you is that a computer should do exactly what its administrator wants it to do. If I install a root cert, it should trust that cert exactly as much (if not more than) every other root cert in the world.

Re: The Security Impact of HTTPS Interception [pdf]

#36

Post by zeveb »

eeZah7Ux wrote: post #11
pfg wrote: 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…

Don't assume the there's a local attacker with root. Employees are often required to install local certs (or applications/scripts that do that) - that doesn't mean the host is entirely compromised.

> Employees are often required to install local certs (or applications/scripts that do that) - that doesn't mean the host is entirely compromised.

If they are forced to install those certs, then the computers they use belong to their employers, and those computers are obeying their proper owners. I fail to see the problem.

Don't use your work computer for things you don't want your work to be able to detect, intercept & modify.

Re: The Security Impact of HTTPS Interception [pdf]

#37

Post by the8472 »

debatem1 wrote: post #27
simias wrote: 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…

> The expectation that we've drilled into users' heads is that when they see the lock icon their traffic is private.

Except it isn't. Even simple things like cloudflare's SSL termination allows the traffic to go unencrypted over the internet and be intercepted by 3rd parties.

http://www.theregister.co.uk/2016/07/14/cloudflare_investiga...

Re: The Security Impact of HTTPS Interception [pdf]

#38

Post by hannob »

Chris_Newton wrote: post #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.

> The few good ones show what is possible

If you've read that out of the paper you read a different one. Quote:

"Our grading scale focuses on the security of the TLS handshake and does not account for the additional HTTPS validation checks present in many browsers, such as HSTS, HPKP, OneCRL/CRLSets, certificate transparency validation, and OCSP must-staple. None of the products we tested supported these features."

Read: Some products got the absolute basics right. None of the solutions did anything that can reasonably be called "good".

> I expected much higher general standards.

I didn't. I don't expect anything from security appliance vendors.

Re: The Security Impact of HTTPS Interception [pdf]

#39

Post by hlandau »

cesarb wrote: post #30
hlandau wrote: post #26

Earlier quoted context omitted.

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

Yeah, I've considered client certificates for this very reason, but as you mention, the UI is truly awful.

I'd like to see TLS Channel ID to become available in browsers for this very reason, but it still doesn't seem to have much buy-in.

Someone once proposed that browsers add a JS API for getting information about the certificate with which the page was loaded. The discussion is on a mailing list somewhere, you can find it if you try. It was shot down on the grounds that a page may contain resources from many origins and made over many different TLS connections, or come from cache, etc. So the idea of "what connection" a page was loaded over isn't necessarily very clear cut. If this API were added it would enable JS-based detection, which obviously wouldn't be foolproof against a determined attacker but would enable some monitoring of this issue to be done.

(Another hare-brained scheme I conceived of to detect this sort of thing is to have a special domain with a HPKP header set that doesn't match the certificates served, and a report-uri. If the browser makes a report, it means it's a normal browser acting correctly. If it doesn't, it means the page was served under a custom CA and HPKP has been disabled. Of course this is incredibly erratic as a means: it doesn't work if a browser doesn't support HPKP, you have to wait for the report to be made, or decide how long you wait before you conclude it's not coming, etc.)

Re: The Security Impact of HTTPS Interception [pdf]

#40

Post by xyzzy123 »

the8472 wrote: post #33
pfg wrote: 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…

> 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. Hah. That's precisely the argument I have made when arguing that there should be an opt-out for addon signature verification (needing admin permissions to toggle it if they insist) because you already utterly lost the security game if someone had admin on the machine. Bu…

The problem in the field was application installers quietly "side loading" browser plugins.
Post reply on HN