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

11–20 of 67 posts

Re: The Security Impact of HTTPS Interception [pdf]

#11

Post by eeZah7Ux »

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…

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.

Re: The Security Impact of HTTPS Interception [pdf]

#13

Post by simias »

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…

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

Re: The Security Impact of HTTPS Interception [pdf]

#14

Post by TD-Linux »

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.

Well, sysadmins have a way simpler solution: just tell their users to use a different browser. This would have to be coordinated between browsers to have any effect at all.

Re: The Security Impact of HTTPS Interception [pdf]

#15

Post by pfg »

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.

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 security. It's a bit like the state of certificate revocation - it works most of the time, just not when you actually need it.

Re: The Security Impact of HTTPS Interception [pdf]

#16

Post by pred_ »

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…

Relevant Bugzilla entry: https://bugzilla.mozilla.org/show_bug.cgi?id=1059392

Re: The Security Impact of HTTPS Interception [pdf]

#17

Post by simias »

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

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.

Re: The Security Impact of HTTPS Interception [pdf]

#18

Post by cesarb »

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'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 are already being warned, as long as their bank uses an EV certificate: the EV green bar won't appear, since EV certificates are only allowed from a hardcoded list of CAs (unfortunately, according to https://www.grc.com/ssl/ev.htm that's not the case for Internet Explorer).

Re: The Security Impact of HTTPS Interception [pdf]

#19

Post by cesarb »

codezero wrote: post #9

Is there a website you can visit that will tell you if your TLS handshake doesn't match your browser's user agent? Maybe this will have to wait until after the team from this paper releases their fingerprints: https://github.com/zakird/tlsfingerprints

https://www.ssllabs.com/ssltest/viewMyClient.html tells you what your client handshake looks like, and https://www.ssllabs.com/ssltest/clients.html shows the usual handshake for several popular browsers.

Re: The Security Impact of HTTPS Interception [pdf]

#20

Post by utefan001 »

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…

In apps like Netflix and Snapchat key pinning works because they control the server side and client side.

This is one reason why squid has a bump splice feature. Look for the SNI in Wireshark then config squid to let Netflix packets go through untouched. I am not aware of any other way to get Netflix and Snapchat to work in a MITM network. My experience is that you have to create a exception and not intercept. Not 100% sure. YMMV.

Post reply on HN