4 ms·

HTTPS stops MITM except for nation-state attackers. How does it increase the attack surface?

dogma1138 10y ago
On the website? An additional library e.g. OpenSSL (heartbleed), HTTPS crypto attacks (e.g. beast), an additional business processes that can be compromised both from the CA/issuers standpoint and from the website admin POV, and an additional resource to protect and securely distribute(private keys). All and all you now have a greater attack surface as an entity, it doesn't mean that you shouldn't use HTTPS, but as far as risk management goes things change. You as a user aren't affected unless you erroneously implicitly trust encrypted traffic considerably more than unencrypted one. HTTPS also doesn't stops MITM attacks from non-state actors. People trust untrusted certificates, the certificate supply chain can be easily poisoned as time and time again we've seen that everyone and their mother managed to make CA's issue certificates under false pretences or otherwise erroneously and DNS / packet racing attacks still can work unless the website implements HTTPS strictly.
- witty_username 10y ago
  > An additional library e.g. OpenSSL (heartbleed), HTTPS crypto attacks (e.g. beast), an additional business processes that can be compromised both from the CA/issuers standpoint and from the website admin POV, and an additional resource to protect and securely distribute(private keys). If these things are attacked, your security is not worse than HTTP. HPKP and HSTS fix the problems you've described.
  - dogma1138 10y ago
    Again you are talking about 2 different attack vectors here, the GP was talking about compromising the website, an attack against the traffic between the website and the client does not compromises the website in any case. And no if these things are attacked, at least as far as the library goes things aren't no worse than HTTP because it's a completely different threat scenario which can actually compromise the website/host rather than just poison a single client session. For example https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6309 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6309 which poentially allows for RCE if you use a vulnerable version of OpenSSL exposes your website to completely different threats than if you would only use HTTP, not worse, not better just an additional and quite different threat. This is why when you implement HTTPS or any other additional service you need to understand how it changes the attack surface of your service from both a technical and operational perspective.
  - anonymfus 10y ago
    Actually heartbleed was a lot worse than using HTTP: attacker could steel everything in the RAM of the server with vulnerable OpenSSL.
- zeta0134 10y ago
  I don't buy that unencrypted traffic is equally trustworthy. Encrypted traffic cannot easily be snooped by a man in the middle. It's arguably the entire point of HTTPS. With HTTP, I have no hints, much less guarantees, that the website I'm talking to is actually who it says it is. There is no mechanism whatsoever to establish trust, and my traffic is up for easy analysis. HTTPS may not fix that problem completely (CAs are the biggest weak point) but it does wonders to solve MITM type snooping of my traffic (a boon to me, as a user) and has the mechanisms in place for me to inspect the certificate chain if I need to be sure of the server I'm communicating with. I agree with a great many of your criticisms against the standard and feel like CAs in particular need to be re-thought, but don't dismiss the entire technology because you assume that the "user" is too stupid to know how to use it.
  - dogma1138 10y ago
    >I don't buy that unencrypted traffic is equally trustworthy. Neither do I, which is why I never made any such claims. Encrypted traffic even in ideal circumstances can and is equally untrustworthy especially under certain threat models ;)
pimterry 10y ago
> HTTPS stops MITM except for nation-state attackers. Technically yes, but in practice no. Sure, you can't MITM a running HTTPS connection. But in HTTPS without HSTS it's easy to transparently stop users getting to HTTPS in the first place, and unless they reliably check the URL bar and verify they have a cert and exactly the right domain then that gives you almost as much damage as a MITM, super easily. We can all agree that users are terrible at constant vigilance, and attacks like this are surprisingly practical. MITMing HTTPS sites that you browse to directly: * You type "site-without-hsts.com" into your URL bar. * Your browser makes an initial plain HTTP request to site-without-hsts.com, and instead of getting an HTTPS redirect I MITM you, and just proxy the plain HTTP to the real HTTPS-only site. * I see and/or change everything on your 'secure' site. Game over. 301's sort-of protect you here, but a) you don't want to user security to depend on browser caching, b) that doesn't work for the first load of a site, and c) if I'm running a wifi hotspot, it's reasonably easy to get people to clear their caches before you let them log in, since it's a fairly standard technical fix now. Alternatively, MITMing HTTPS sites reached through some other page: * You load any plain HTTP page while browsing, on route to a secure site. * I MITM the plain HTTP, replace 'https' with 'http' in all links in the page, and MITM every subsequent page as above, proxying through to real HTTPS sites where required. * I see and/or change everything on your 'secure' site. Game over. Functionally, if you have any insecure step in your browser session, I can stop you reaching the secure step, and if you're not carefully paying attention you won't notice. Sometimes, sure, you might, but most of the time you won't, and 99.9999% of the time your average computer user won't ever check. HTTPS coverage is getting better, but I suspect the vast majority of browsing sessions still go through an insecure step somewhere along the pipeline. HTTPS doesn't fully protect your users from MITMs. Add HSTS though (so the browser will refuse to ever make a plain HTTP request to your HTTPS site), and you get substantially closer.
- witty_username 10y ago
  BTW, why can't browsers try HTTPS first and then fallback to HTTP? I agree with you.

On the website? An additional library e.g. OpenSSL (heartbleed), HTTPS crypto attacks (e.g. beast), an additional business processes that can be compromised both from the CA/issuers standpoint and from the website admin POV, and an additional resource to protect and securely distribute(private keys). All and all you now have a greater attack surface as an entity, it doesn't mean that you shouldn't use HTTPS, but as far as risk management goes things change. You as a user aren't affected unless you erroneously implicitly trust encrypted traffic considerably more than unencrypted one. HTTPS also doesn't stops MITM attacks from non-state actors. People trust untrusted certificates, the certificate supply chain can be easily poisoned as time and time again we've seen that everyone and their mother managed to make CA's issue certificates under false pretences or otherwise erroneously and DNS / packet racing attacks still can work unless the website implements HTTPS strictly.

witty_username 10y ago
> An additional library e.g. OpenSSL (heartbleed), HTTPS crypto attacks (e.g. beast), an additional business processes that can be compromised both from the CA/issuers standpoint and from the website admin POV, and an additional resource to protect and securely distribute(private keys). If these things are attacked, your security is not worse than HTTP. HPKP and HSTS fix the problems you've described.
- dogma1138 10y ago
  Again you are talking about 2 different attack vectors here, the GP was talking about compromising the website, an attack against the traffic between the website and the client does not compromises the website in any case. And no if these things are attacked, at least as far as the library goes things aren't no worse than HTTP because it's a completely different threat scenario which can actually compromise the website/host rather than just poison a single client session. For example https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6309 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6309 which poentially allows for RCE if you use a vulnerable version of OpenSSL exposes your website to completely different threats than if you would only use HTTP, not worse, not better just an additional and quite different threat. This is why when you implement HTTPS or any other additional service you need to understand how it changes the attack surface of your service from both a technical and operational perspective.
- anonymfus 10y ago
  Actually heartbleed was a lot worse than using HTTP: attacker could steel everything in the RAM of the server with vulnerable OpenSSL.
zeta0134 10y ago
I don't buy that unencrypted traffic is equally trustworthy. Encrypted traffic cannot easily be snooped by a man in the middle. It's arguably the entire point of HTTPS. With HTTP, I have no hints, much less guarantees, that the website I'm talking to is actually who it says it is. There is no mechanism whatsoever to establish trust, and my traffic is up for easy analysis. HTTPS may not fix that problem completely (CAs are the biggest weak point) but it does wonders to solve MITM type snooping of my traffic (a boon to me, as a user) and has the mechanisms in place for me to inspect the certificate chain if I need to be sure of the server I'm communicating with. I agree with a great many of your criticisms against the standard and feel like CAs in particular need to be re-thought, but don't dismiss the entire technology because you assume that the "user" is too stupid to know how to use it.
- dogma1138 10y ago
  >I don't buy that unencrypted traffic is equally trustworthy. Neither do I, which is why I never made any such claims. Encrypted traffic even in ideal circumstances can and is equally untrustworthy especially under certain threat models ;)

pimterry 10y ago

> HTTPS stops MITM except for nation-state attackers. Technically yes, but in practice no. Sure, you can't MITM a running HTTPS connection. But in HTTPS without HSTS it's easy to transparently stop users getting to HTTPS in the first place, and unless they reliably check the URL bar and verify they have a cert and exactly the right domain then that gives you almost as much damage as a MITM, super easily. We can all agree that users are terrible at constant vigilance, and attacks like this are surprisingly practical. MITMing HTTPS sites that you browse to directly: * You type "site-without-hsts.com" into your URL bar. * Your browser makes an initial plain HTTP request to site-without-hsts.com, and instead of getting an HTTPS redirect I MITM you, and just proxy the plain HTTP to the real HTTPS-only site. * I see and/or change everything on your 'secure' site. Game over. 301's sort-of protect you here, but a) you don't want to user security to depend on browser caching, b) that doesn't work for the first load of a site, and c) if I'm running a wifi hotspot, it's reasonably easy to get people to clear their caches before you let them log in, since it's a fairly standard technical fix now. Alternatively, MITMing HTTPS sites reached through some other page: * You load any plain HTTP page while browsing, on route to a secure site. * I MITM the plain HTTP, replace 'https' with 'http' in all links in the page, and MITM every subsequent page as above, proxying through to real HTTPS sites where required. * I see and/or change everything on your 'secure' site. Game over. Functionally, if you have any insecure step in your browser session, I can stop you reaching the secure step, and if you're not carefully paying attention you won't notice. Sometimes, sure, you might, but most of the time you won't, and 99.9999% of the time your average computer user won't ever check. HTTPS coverage is getting better, but I suspect the vast majority of browsing sessions still go through an insecure step somewhere along the pipeline. HTTPS doesn't fully protect your users from MITMs. Add HSTS though (so the browser will refuse to ever make a plain HTTP request to your HTTPS site), and you get substantially closer.

witty_username 10y ago
BTW, why can't browsers try HTTPS first and then fallback to HTTP? I agree with you.