12 ms·

The Security Impact of HTTPS Interception [pdf]

160 points by DeltaWhy 10y ago

nailer 10y ago
From the conclusion: > We deployed these heuristics on three diverse networks: > (1) Mozilla Firefox update servers, > (2) a set of popular e-commerce sites, and > (3) the Cloudflare content distribution network. > In each case, we find more than an order of magnitude more interception than previously estimated, ranging from 4–11%. > As a class, interception products drastically reduce connection security. Most concerningly, 62% of traffic that traverses a network middlebox has reduced security and 58% of middlebox connections have severe vulnerabilities. We investigated popular antivirus and corporate proxies, finding that nearly all reduce connection security and that many introduce vulnerabilities (e.g., fail to validate certificates).
__david__ 10y ago
What is the meaning of the "AS" acronym that the paper uses (seemingly representing network providers)? I didn't see it explained anywhere and it's not ringing any bells with me…
- jrcii 10y ago
  It stands for autonomous system, part of BGP
- r1ch 10y ago
  Autonomous System. https://en.wikipedia.org/wiki/Autonomous_system_(Internet) https://en.wikipedia.org/wiki/Autonomous_system_(Internet)
- deleted 10y ago
  [deleted]
- scotchmi_st 10y ago
  AS refers to the Autonomous System. https://en.wikipedia.org/wiki/Autonomous_system_(Internet) https://en.wikipedia.org/wiki/Autonomous_system_(Internet) It's an IP routing concept. AS Numbers are used to refer to different networks (run by different ISPs and providers) on the internet.
simias 10y ago
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 terminates in a locally installed root (i.e., a CA certificate installed by an administrator). Seems like a strange default to me. I feel like the user should be notified of this, for instance if they're using a work computer to access their bank account or something like that.
- pfg 10y ago
  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 legal and educational issue.
  - eeZah7Ux 10y ago
    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.
    - zeveb 10y ago
      > 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.
      - 10y ago
codezero 10y ago
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://github.com/zakird/tlsfingerprints
- cesarb 10y ago
  https://www.ssllabs.com/ssltest/viewMyClient.html https://www.ssllabs.com/ssltest/viewMyClient.html tells you what your client handshake looks like, and https://www.ssllabs.com/ssltest/clients.html https://www.ssllabs.com/ssltest/clients.html shows the usual handshake for several popular browsers.
ejcx 10y ago
Another blow to the utility of AntiVirus. I hate the AV industry in infosec. It does not work well and in most cases, refundes security. Unbelievable that it's still required for a lot of compliance veers.
Chris_Newton 10y ago
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.
- hannob 10y ago
  > 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.
LogicX 10y ago
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.
- Artemis2 10y ago
  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.
  - LogicX 10y ago
    I'd be interested in seeing what you've got -- I have on my list to look into doing so with HAProxy per the link here: http://serverfault.com/questions/628147/nginx-proxy-based-on-sni-without-decryption http://serverfault.com/questions/628147/nginx-proxy-based-on...
einrealist 10y ago
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.
- ownagefool 10y ago
  Why does the proxy not belong on the endpoint?
  - einrealist 10y ago
    For various reasons: you probably have more endpoints on your network than proxy servers and thus a bigger attack surface. Keeping the endpoints up-to-date is harder (e.g. laptops that are not permanently attached to the network to receive updates). If your endpoints are workstations, human interaction (e.g. installing malicious software, opening malicious attachements) and the overall complexity of the system (e.g. GUI, multiple users) makes it weaker than a central, dedicated, isolated, stripped down and locked down set of proxy servers. And finally, process isolation is really, really hard (if your countermeasure _only_ runs on the target (endpoint), you already weakened your position).
jaimex2 10y ago
Yep, HTTPS is a joke. Always secure your own transport if its sensitive.

160 points by DeltaWhy 10y ago

From the conclusion: > We deployed these heuristics on three diverse networks: > (1) Mozilla Firefox update servers, > (2) a set of popular e-commerce sites, and > (3) the Cloudflare content distribution network. > In each case, we find more than an order of magnitude more interception than previously estimated, ranging from 4–11%. > As a class, interception products drastically reduce connection security. Most concerningly, 62% of traffic that traverses a network middlebox has reduced security and 58% of middlebox connections have severe vulnerabilities. We investigated popular antivirus and corporate proxies, finding that nearly all reduce connection security and that many introduce vulnerabilities (e.g., fail to validate certificates).

__david__ 10y ago

What is the meaning of the "AS" acronym that the paper uses (seemingly representing network providers)? I didn't see it explained anywhere and it's not ringing any bells with me…

jrcii 10y ago
It stands for autonomous system, part of BGP
r1ch 10y ago
Autonomous System. https://en.wikipedia.org/wiki/Autonomous_system_(Internet) https://en.wikipedia.org/wiki/Autonomous_system_(Internet)
deleted 10y ago
[deleted]
scotchmi_st 10y ago
AS refers to the Autonomous System. https://en.wikipedia.org/wiki/Autonomous_system_(Internet) https://en.wikipedia.org/wiki/Autonomous_system_(Internet) It's an IP routing concept. AS Numbers are used to refer to different networks (run by different ISPs and providers) on the internet.

simias 10y ago

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 terminates in a locally installed root (i.e., a CA certificate installed by an administrator). Seems like a strange default to me. I feel like the user should be notified of this, for instance if they're using a work computer to access their bank account or something like that.

pfg 10y ago
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 legal and educational issue.
- eeZah7Ux 10y ago
  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.
  - zeveb 10y ago
    > 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.
    - 10y ago

codezero 10y ago

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://github.com/zakird/tlsfingerprints

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

ejcx 10y ago

Another blow to the utility of AntiVirus. I hate the AV industry in infosec. It does not work well and in most cases, refundes security. Unbelievable that it's still required for a lot of compliance veers.

Chris_Newton 10y ago

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.

hannob 10y ago
> 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.

LogicX 10y ago

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.

Artemis2 10y ago
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.
- LogicX 10y ago
  I'd be interested in seeing what you've got -- I have on my list to look into doing so with HAProxy per the link here: http://serverfault.com/questions/628147/nginx-proxy-based-on-sni-without-decryption http://serverfault.com/questions/628147/nginx-proxy-based-on...

einrealist 10y ago

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.

ownagefool 10y ago
Why does the proxy not belong on the endpoint?
- einrealist 10y ago
  For various reasons: you probably have more endpoints on your network than proxy servers and thus a bigger attack surface. Keeping the endpoints up-to-date is harder (e.g. laptops that are not permanently attached to the network to receive updates). If your endpoints are workstations, human interaction (e.g. installing malicious software, opening malicious attachements) and the overall complexity of the system (e.g. GUI, multiple users) makes it weaker than a central, dedicated, isolated, stripped down and locked down set of proxy servers. And finally, process isolation is really, really hard (if your countermeasure _only_ runs on the target (endpoint), you already weakened your position).

jaimex2 10y ago

Yep, HTTPS is a joke. Always secure your own transport if its sensitive.