5 ms·

Airports usually do SSL MITM so they can inspect the traffic. Or they redirect all addresses to a hotspot sign-in page until the user signs in.

by Cakez0r 10y ago

themartorana 10y ago
Really wish this was illegal or SSL didn't have such a gaping vulnerability.
- mikegerwitz 10y ago
  There is no gaping vulnerability. The user will be presented with a certificate error (or denied outright, depending on the browser). If the user decides to add an exception, only then will a handshake succeed and the MITM be possible (in this particular scenario).
  - NotreDev 10y ago
    Not what you were replying to, but SSL does provide for MITM outside of the options offered in your response. I.e. https://mitmproxy.org https://mitmproxy.org
    - kecks 10y ago
      No? The link you posted is indeed a MITM proxy for SSL, but it will generate certificate errors, as my grandparent said. Users will know the MITM attack is going on (unless the website doesn't use HSTS and the attacker has stolen/bought a signing key from a CA registered in your device's trust store).
    - corndoge 10y ago
      As a user of mitmproxy, I assure you it is not achieving MITM by exploiting any weakness of SSL. mitmproxy requires its certificate to be trusted by the target (i.e. installed in the root store) to silently intercept SSL'd traffic. Invalid certificate warnings will display otherwise. This is fully conformant to SSL's threat model.
  - zeveb 10y ago
    Unless of course the WiFi operator is using a MITM certificate issued by a 'legitimate' CA. When you use XPKI, you are trusting every single CA in the world to certify every single site in the world. A sane PKI would limit what CAs are permitted to certify (e.g. TÜRKTRUST might be permitted to certify *.tr, but nothing else — not foo.br, bar.gov or baz.co.uk). But XPKI is neither a sane nor a secure PKI.
    - pfg 10y ago
      If a publicly-trusted CA would issue MitM certificates for WiFi operators (specifically for domains that the WiFi operator doesn't own), they'd be out of business in a heartbeat. That would be a severe violation of Baseline Requirements and various root program policies, and no browser vendor would continue trusting such a CA. Both HPKP and other pinning technologies included in e.g. Chrome would make this easily detectable. This scenario might be plausible for targeted attacks by nation states, but not for something as simple as public WiFi.
      - mtgx 10y ago
        Ok, so you think BlueCoat will be out of business because of this? Surveillance and censorship is BlueCoat's business, and now they're a CA. https://news.ycombinator.com/item?id=11781915 https://news.ycombinator.com/item?id=11781915
        pfg 10y ago
        The question here isn't whether BlueCoat would go out of business, but rather Symantec. I don't like Symantec, nor do I like BlueCoat. That being said, we have no evidence that this certificate was used for misissuance. Symantec claims that BlueCoat never had access to the private key. The certificate was disclosed to Mozilla's root program. I have no idea why Symantec would agree to sign a certificate for an organization like BlueCoat - the PR damage has to be devastating. It would make even less sense for them to sign such a certificate to allow BlueCoat to use it with their MitM devices, because something like that is more or less guaranteed to be detected sooner or later, with HPKP and other pinning technologies. They would essentially kill their CA business, and I doubt any amount of money BlueCoat would be willing to pay would cover their entire CA business profits.
  - developer2 10y ago
    If one doesn't understand exactly how TLS works, this is the usual question regarding MITM. If there is "end-to-end encryption", just how exactly is it even possible to do MITM? In an ideal world, it just wouldn't be possible. With the existing system, certificate "errors" that are really just "warnings" should not be allowed to be bypassed. The fact that certificate errors can be ignored is something that should never have been allowed to take place. Unfortunately with the historical fact that legit certificates were inexcusably expensive to obtain for internal/test projects meant that self-signed certificates became commonplace. We're waiting for a genius to come up with a new strategy for encryption that doesn't rely on trust being determined by a third party entity (ie: certificate authorities). Letsencrypt is nice and all, but it's still just a free workaround for a system nobody really wants. "It's not possible to do it any other way" is just pseudo-speak for "nobody has invented a better way yet". Why the strategy for encryption has relied on public/private keys for so long with no real alternative strikes me as odd. After 30+ years, nobody has thought of something else?
    - schoen 10y ago
      If sites use HSTS, browsers won't allow users to bypass the errors. See section 12.1 of RFC 6797: https://tools.ietf.org/html/rfc6797#section-12.1 https://tools.ietf.org/html/rfc6797#section-12.1 So you can encourage people to use HSTS and then get part of that behavior at least for individual sites.
      - developer2 10y ago
        The HSTS preload list (referring primarily to Chrome's, which is also included by other vendors) in particular is something I find really strange. The current domain owner adds the domain to the HSTS preload list. That domain then expires or is released by that owner, without them requesting its removal from the preload list. Then someone else buys the domain without having planned to use SSL/TLS. The result? Weeks, even months, of not being able to use the domain without encryption, all because someone else previously had the domain added to the HSTS preload list. Removal from the preload list is by request only; there is no automation in place to detect the lack of an HSTS header to mean that the domain is no longer to be considered a participant. Even worse, the request to be removed can take an indeterminate amount of time to be disseminated to end users of the browser. The preload list is not pushed to clients via something like a daily digest; the list is hardcoded into releases of the browser. This means it can take an absurd length of time to see a domain removed from the list, as it depends on every individual user updating the browser to the latest version, and only once the vendor even gets around to updating the hardcoded list in a given release to include your domain's removal. How such a mechanism was ever acceptable is beyond me. Domain ownership is technically fluid, and yet the implementation was designed in such a way as to assume that domain ownership never changes.
- bluewizard 10y ago
  The correct thing to do in this case (if you are worried about security) is to allow the MITM SSL handshake and use a secure VPN for your Internet access. Third parties with the certificate keys would only be able to see encrypted traffic between you and the VPN provider.
eatmyshorts 10y ago
I've seen captive portal redirection until login, but I've never seen an SSL MITM like this deployed officially at any airport. I would bet this guy logged in to somebody's pineapple: https://www.wifipineapple.com/ https://www.wifipineapple.com/
- corndoge 10y ago
  Captive portal redirection frequently causes SSL errors in my experience.
- epmatsw 10y ago
  Southwest's in-air wifi does this. Pretty scary looking warning message in Chrome, won't even let you go to Google cause of HSTS.
schoen 10y ago
It looks like this particular MITM is being done by OpenDNS. https://support.opendns.com/entries/46060260-FamilyShield-Router-Configuration-Instructions https://support.opendns.com/entries/46060260-FamilyShield-Ro... They are trying to show a block page because this site is classified as Proxy/Anonymizer by OpenDNS, but they have to MITM the HTTPS connection in order to (try to) do so. You might be able to avoid this censorship by using a different DNS resolver, depending how the airport wifi is implementing it.

Airports usually do SSL MITM so they can inspect the traffic. Or they redirect all addresses to a hotspot sign-in page until the user signs in.

by Cakez0r 10y ago

Airports usually do SSL MITM so they can inspect the traffic. Or they redirect all addresses to a hotspot sign-in page until the user signs in.

themartorana 10y ago

Really wish this was illegal or SSL didn't have such a gaping vulnerability.

mikegerwitz 10y ago
There is no gaping vulnerability. The user will be presented with a certificate error (or denied outright, depending on the browser). If the user decides to add an exception, only then will a handshake succeed and the MITM be possible (in this particular scenario).
- NotreDev 10y ago
  Not what you were replying to, but SSL does provide for MITM outside of the options offered in your response. I.e. https://mitmproxy.org https://mitmproxy.org
  - kecks 10y ago
    No? The link you posted is indeed a MITM proxy for SSL, but it will generate certificate errors, as my grandparent said. Users will know the MITM attack is going on (unless the website doesn't use HSTS and the attacker has stolen/bought a signing key from a CA registered in your device's trust store).
  - corndoge 10y ago
    As a user of mitmproxy, I assure you it is not achieving MITM by exploiting any weakness of SSL. mitmproxy requires its certificate to be trusted by the target (i.e. installed in the root store) to silently intercept SSL'd traffic. Invalid certificate warnings will display otherwise. This is fully conformant to SSL's threat model.
- zeveb 10y ago
  Unless of course the WiFi operator is using a MITM certificate issued by a 'legitimate' CA. When you use XPKI, you are trusting every single CA in the world to certify every single site in the world. A sane PKI would limit what CAs are permitted to certify (e.g. TÜRKTRUST might be permitted to certify *.tr, but nothing else — not foo.br, bar.gov or baz.co.uk). But XPKI is neither a sane nor a secure PKI.
  - pfg 10y ago
    If a publicly-trusted CA would issue MitM certificates for WiFi operators (specifically for domains that the WiFi operator doesn't own), they'd be out of business in a heartbeat. That would be a severe violation of Baseline Requirements and various root program policies, and no browser vendor would continue trusting such a CA. Both HPKP and other pinning technologies included in e.g. Chrome would make this easily detectable. This scenario might be plausible for targeted attacks by nation states, but not for something as simple as public WiFi.
    - mtgx 10y ago
      Ok, so you think BlueCoat will be out of business because of this? Surveillance and censorship is BlueCoat's business, and now they're a CA. https://news.ycombinator.com/item?id=11781915 https://news.ycombinator.com/item?id=11781915
      - pfg 10y ago
        The question here isn't whether BlueCoat would go out of business, but rather Symantec. I don't like Symantec, nor do I like BlueCoat. That being said, we have no evidence that this certificate was used for misissuance. Symantec claims that BlueCoat never had access to the private key. The certificate was disclosed to Mozilla's root program. I have no idea why Symantec would agree to sign a certificate for an organization like BlueCoat - the PR damage has to be devastating. It would make even less sense for them to sign such a certificate to allow BlueCoat to use it with their MitM devices, because something like that is more or less guaranteed to be detected sooner or later, with HPKP and other pinning technologies. They would essentially kill their CA business, and I doubt any amount of money BlueCoat would be willing to pay would cover their entire CA business profits.
- developer2 10y ago
  If one doesn't understand exactly how TLS works, this is the usual question regarding MITM. If there is "end-to-end encryption", just how exactly is it even possible to do MITM? In an ideal world, it just wouldn't be possible. With the existing system, certificate "errors" that are really just "warnings" should not be allowed to be bypassed. The fact that certificate errors can be ignored is something that should never have been allowed to take place. Unfortunately with the historical fact that legit certificates were inexcusably expensive to obtain for internal/test projects meant that self-signed certificates became commonplace. We're waiting for a genius to come up with a new strategy for encryption that doesn't rely on trust being determined by a third party entity (ie: certificate authorities). Letsencrypt is nice and all, but it's still just a free workaround for a system nobody really wants. "It's not possible to do it any other way" is just pseudo-speak for "nobody has invented a better way yet". Why the strategy for encryption has relied on public/private keys for so long with no real alternative strikes me as odd. After 30+ years, nobody has thought of something else?
  - schoen 10y ago
    If sites use HSTS, browsers won't allow users to bypass the errors. See section 12.1 of RFC 6797: https://tools.ietf.org/html/rfc6797#section-12.1 https://tools.ietf.org/html/rfc6797#section-12.1 So you can encourage people to use HSTS and then get part of that behavior at least for individual sites.
    - developer2 10y ago
      The HSTS preload list (referring primarily to Chrome's, which is also included by other vendors) in particular is something I find really strange. The current domain owner adds the domain to the HSTS preload list. That domain then expires or is released by that owner, without them requesting its removal from the preload list. Then someone else buys the domain without having planned to use SSL/TLS. The result? Weeks, even months, of not being able to use the domain without encryption, all because someone else previously had the domain added to the HSTS preload list. Removal from the preload list is by request only; there is no automation in place to detect the lack of an HSTS header to mean that the domain is no longer to be considered a participant. Even worse, the request to be removed can take an indeterminate amount of time to be disseminated to end users of the browser. The preload list is not pushed to clients via something like a daily digest; the list is hardcoded into releases of the browser. This means it can take an absurd length of time to see a domain removed from the list, as it depends on every individual user updating the browser to the latest version, and only once the vendor even gets around to updating the hardcoded list in a given release to include your domain's removal. How such a mechanism was ever acceptable is beyond me. Domain ownership is technically fluid, and yet the implementation was designed in such a way as to assume that domain ownership never changes.
bluewizard 10y ago
The correct thing to do in this case (if you are worried about security) is to allow the MITM SSL handshake and use a secure VPN for your Internet access. Third parties with the certificate keys would only be able to see encrypted traffic between you and the VPN provider.

eatmyshorts 10y ago

I've seen captive portal redirection until login, but I've never seen an SSL MITM like this deployed officially at any airport. I would bet this guy logged in to somebody's pineapple: https://www.wifipineapple.com/ https://www.wifipineapple.com/

corndoge 10y ago
Captive portal redirection frequently causes SSL errors in my experience.
epmatsw 10y ago
Southwest's in-air wifi does this. Pretty scary looking warning message in Chrome, won't even let you go to Google cause of HSTS.

schoen 10y ago

It looks like this particular MITM is being done by OpenDNS. https://support.opendns.com/entries/46060260-FamilyShield-Router-Configuration-Instructions https://support.opendns.com/entries/46060260-FamilyShield-Ro... They are trying to show a block page because this site is classified as Proxy/Anonymizer by OpenDNS, but they have to MITM the HTTPS connection in order to (try to) do so. You might be able to avoid this censorship by using a different DNS resolver, depending how the airport wifi is implementing it.