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

41–50 of 67 posts

Re: The Security Impact of HTTPS Interception [pdf]

#41

Post by hlandau »

arkadiyt wrote: post #32
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/

That blog post insinuates that 'strict' HPKP wouldn't work, yet despite this Google Chrome actually enforces strict HPKP... but only for some Google Domains. It's rather a double standard. I wrote about this: https://www.devever.net/~hl/policymitm

Re: The Security Impact of HTTPS Interception [pdf]

#42

Post by einrealist »

Its sad that interception receives such a bad reputation because of broken security products. Yes, a proxy is a weak link. But if implemented properly and in a trustworthy way, then its better than having endpoint security, which is often worse. And no, the proxy does not belong on the endpoint itself! If organizations with proxy interception are not able to scan traffic, they will just drop the traffic. Instead of using MITM mitigations that don't allow interception at all, we need better user experience (with choice) and safe(r) products.

I have a little side project where I try to implement a proxy for myself. I want to remove ads and be able to scan and cache downloads. I trust the adblock plugins and endpoint security products far less than a MITM proxy, I wrote myself.

Re: The Security Impact of HTTPS Interception [pdf]

#43

Post by the8472 »

xyzzy123 wrote: post #40
the8472 wrote: post #33

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

Either those are malicious, in which case you lost the game and cannot defend against that because they have the security high ground, or they legitimately act on the user's behalf.

The "quietly" adjective suggests they are malicious. Which means they should be reported to AV vendors (including microsoft) instead of being used as a boogeyman when arguing against user freedoms.

Re: The Security Impact of HTTPS Interception [pdf]

#44

Post by riffic »

zeveb wrote: post #36
eeZah7Ux wrote: post #11

Earlier quoted context omitted.

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, intercep…

  Don't use your work computer for things you don't want your work to be able to detect, intercept & modify.
with that logic, don't get mail sent to the office because your employer has every right to open and reseal the envelope.

You know who also has that right? Prisons.

Re: The Security Impact of HTTPS Interception [pdf]

#45

Post by jusob »

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…

It is part of the RFC: if a certificate is signed by a root certificate that is trusted in your private store (meaning it was added later on), HPKP is ignored. Unfortunately, this is required in the enterprise world where corporate MiTM is often done (Palo Alto Network SSL proxy, Websense/Forcepoint, Zscaler, Blue Coat, etc.) for content inspection.

Re: The Security Impact of HTTPS Interception [pdf]

#46

Post by SCHiM »

the8472 wrote: post #43
xyzzy123 wrote: post #40

Earlier quoted context omitted.

The problem in the field was application installers quietly "side loading" browser plugins.

Either those are malicious, in which case you lost the game and cannot defend against that because they have the security high ground, or they legitimately act on the user's behalf. The "quietly" adjective suggests they are malicious. Which means they should be reported to AV vendors (including microsoft) instead of being used as a boogeyman when arguing against user freedoms.

Yes, especially since true malware creators have been able to inject code into browsers and intercept and modify pages for ages. They don't need an add-on, they'll just inject a shared library or something similar.

Re: The Security Impact of HTTPS Interception [pdf]

#47

Post by debatem1 »

zeveb wrote: post #35
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 igno…

Android doesn't do what I want. It just warns you that a user added CA exists, which isn't specific enough to change user behavior but is frequent enough to cause fatigue.

Re: The Security Impact of HTTPS Interception [pdf]

#48

Post by voidlogic »

jusob wrote: post #45
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…

It is part of the RFC: if a certificate is signed by a root certificate that is trusted in your private store (meaning it was added later on), HPKP is ignored. Unfortunately, this is required in the enterprise world where corporate MiTM is often done (Palo Alto Network SSL proxy, Websense/Forcepoint, Zscaler, Blue Coat, etc.) for content inspection.

>Unfortunately, this is required in the enterprise world where corporate MiTM is often done

This still should not be the default, rather corps should have an easy about:config switch they can flip. The default should protect private users.

Re: The Security Impact of HTTPS Interception [pdf]

#49

Post by ryan-c »

voidlogic wrote: post #48
jusob wrote: post #45

Earlier quoted context omitted.

It is part of the RFC: if a certificate is signed by a root certificate that is trusted in your private store (meaning it was added later on), HPKP is ignored. Unfortunately, this is required in the enterprise world where corporate MiTM is often done (Palo Alto Network SSL proxy, Websense/Forcepoint, Zscaler, Blue Coat, etc.) for content inspection.

>Unfortunately, this is required in the enterprise world where corporate MiTM is often done This still should not be the default, rather corps should have an easy about:config switch they can flip. The default should protect private users.

How is that a meaningfully different experience? Anything able to install a CA can flip the config value.

Re: The Security Impact of HTTPS Interception [pdf]

#50

Post by Artemis2 »

LogicX wrote: post #31

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…

I've written a proxy that uses SNI to filter outgoing connections based on the domain name, without decrypting the traffic. It's not exactly user-friendly as you'd like, but it's a good solution to our use-case.

I might open-source it if there's interest but it's relatively basic.

Post reply on HN