5 ms·

Gogo Inflight Internet is Intentionally Issuing Fake SSL Certificates

87 points by danielcorin 12y ago

yuhong 12y ago
Gogo is old news by now though.
- hellbanner 12y ago
  I hadn't heard of it. Glad to hear about this -- MiTM attacks & SSL spoofing is an important problem in today's internet security.
  - fadzlan 12y ago
    Still, there will be a broken padlock icons in the browser. As much as they can read the traffic, they can't spoofed the identity. Not without having their own root cert on the customer side.
  - ubernostrum 12y ago
    They don't successfully spoof it; that would require a cert signed by a root CA the browser trusts, and they don't have that. So what you'll actually get is not a web page, but an SSL cert error warning from your browser. If you're technically inclined enough to click your way through to see the actual page, I think all you get is a generic "YouTube is blocked" (and blocking YouTube is the reason why they do it -- they don't have the bandwidth to support it or other streaming video).
- Animats 12y ago
  Right. They're trying to tell you "you can't do that", but have no good way to do so. As I pointed out when this came up last time, the problem is that current network stacks and browsers don't propagate ICMP Destination Unreachable subcodes (such as "Host Unreachable - Communication Administratively Prohibited") up to the user. That's the proper way to express "you can't do that". Unfortunately, most OSs treat network errors like file errors, hammer them down to some small set of "errno" values, and lose the detail.
lemiant 12y ago
This is very different though, because it would throw an error.
- MBlume 12y ago
  It's training users to ignore the error, and that's bad, but yes, it's not as bad as komodia
patcheudor 12y ago
There are a lot of places which "spoof" or provide their own public in the TLS handshake. Top of mind is every single hotel I've ever stayed at which requires the entry of my last name and hotel room number via a captive portal. Of course in those cases the captive portal authentication page isn't the site I was originally going to visit, although some don't redirect and do leave the original destination in the address bar which is always an interesting trust issue, especially if the captive portal is asking me for my ISP password or a credit-card.
- tyrfing 12y ago
  Regarding hotel portals, this is relevant: https://securelist.com/blog/research/66779/the-darkhotel-apt/ https://securelist.com/blog/research/66779/the-darkhotel-apt...
fivedogit 12y ago
Slightly OT: CDNs basically perform a MITM to do what they do. The destination site's certificate (www.destination.com) is deployed throughout the CDN's servers and when DNS lookups are performed, the end user is directed to the IP address an optimal edge server where the certificate is waiting to greet them warmly. On the other side (first mile), the CDN then connects via a second SSL certificate (say, origin-www.destination.com) to the origin's datacenter(s) to retrieve the necessary data. When I worked at a CDN company, we frequently got inquiries from customers saying that a security audit they ran threw up a red flag for MITM. And it was my job to tell them why it wasn't anything to worry about. PS, most origin-www.destination.com origins are extremely vulnerable to DDoS since, at that hostname, there is no CDN to protect them.
- general_failure 12y ago
  While what you explain is correct, willfully giving/deploying your certificates in another server probably doesn't count as MITM
  - Xorlev 12y ago
    Agreed. It's only MITM if it's unauthorized IMO. If I deploy my cert to a CDN its just legitimate handshakes so I'm not sure where the man in the middle comes in.
- skuhn 12y ago
  > On the other side (first mile), the CDN then connects via a second SSL certificate (say, origin-www.destination.com) to the origin's datacenter(s) to retrieve the necessary data. Perhaps. Not all CDNs require TLS to be used to connect to backends when the frontend is encrypted. This is completely obscured from the requesting client, and is a breach of user trust in my opinion. > PS, most origin-www.destination.com origins are extremely vulnerable to DDoS since, at that hostname, there is no CDN to protect them. This is a big problem that is rarely addressed until it bites you. When you're accustomed to a >90% hit rate and all of the nastiness of the Internet being handled upstream, you aren't going to be prepared for even a slight uptick in origin traffic. I saw one place whose site was served via Akamai DSA (http acceleration service), and routinely served >5Gbps. The origin consisted of two machines behind a Cisco ASA with a 100Mbit Ethernet port.
sjwright 12y ago
I think the two scariest discoveries with Superfish are that Microsoft allows an OEM to ship a retail Windows computer with additional root certificates, and that Chrome is trusting the root certificates stored by Windows -- Firefox does not. My proposed actions: (1) Microsoft should immediately update their OEM agreements to ban all manipulation of root certificates for computers sold at retail. Further, the root certificate store should be cryptographically signed by Microsoft and this signature validated during Windows OOBE. (2) Google should follow Mozilla's lead and have Chrome securely manage its own root certificate store. (It could be disabled for legitimate corporate deployments, but never with the regular end-user Chrome installer.)
- toast0 12y ago
  Chrome has chosen to use the system network (proxy) settings, the system SSL stack, etc. It actually makes sense for them to use the state CA store. Firefox's legacy includes platforms where there was no system any of that. As use shouldn't need to set proxy settings or corporate CAs for every application they run. Otoh, it is unfortunate that chrome has different SSL behavior on every platform.
  - jesseendahl 12y ago
    When it comes to SSL/TLS, "on all platforms, [they] use NSS's libssl to handle the SSL connection logic... [and] ... platform specific APIs for certificate verification."
- userbinator 12y ago
  Further, the root certificate store should be cryptographically signed by Microsoft and this signature validated during Windows OOBE. This is just one small step down the path of not allowing any modification to the root certificate store, and that is an even scarier situation, since users will have absolutely no control over who they decide to trust.
  - sjwright 12y ago
    I would agree with you if most users understood the concept of trust as it relates to the root certificate store. Very few do, likely less than 1%. Therefore I believe it must be Microsoft's responsibility to be the singular default trusted entity for the root certificate store shipped to retail consumers as part of Microsoft Windows. Your slippery slope argument fails because your "small step" would be immediately rejected by the vast majority of the Fortune 500, for starters. It just couldn't happen. It would be unworkable.
stevenjohns 12y ago
Okay I've never commented on my affiliation before because I don't want to advertise but this is ridiculous. I am the one who wrote the first article and 'broke' the story about Gogo's snooping [0]. Plenty of publications also reported on it after it reached high notoriety on Reddit. Some copied parts of my article, some didn't give a source or via to me, some made it appear like they were producing original news. That's fine, I don't really care: it happens to almost every single original article I write (one time I took a screen shot of my own Desktop as an article image and the other websites copied that too with no source) and I've grown use to it - I was just happy that it was making waves and forcing Gogo to reconsider their position. But in this case, Symantec has copied my original title verbatim. If you're going to literally copy my title verbatim, at least give a link back to it. Ridiculous. It wasn't even a good title. [0] http://www.neowin.net/news/gogo-inflight-internet-is-intentionally-issuing-fake-ssl-certificates http://www.neowin.net/news/gogo-inflight-internet-is-intenti...
- TwoBit 12y ago
  You need to list all that copying that was done on your resume. What better way to prove your skills than to show how much people are copying you.
  - stevenjohns 12y ago
    If I was a career journalist I'd probably be more concerned, but I'm a software engineer and write just because I enjoy tech.
    - cmwelsh 12y ago
      Original research cited by major news organizations puts you on a whole new level above just "software engineer" for salary purposes. It's resume-worthy if you have a section for academic-type accomplishments.
      - stevenjohns 12y ago
        That's actually a really salient point. I've never considered it as 'research,' my mind just never made that connection for whatever reason. I'll keep it in mind from now on - thanks!
bsdetector 12y ago
Pretty sure I remember PHK warning that (paraphrased) if you encrypt cat videos along with everything else it's just going to cause more effort to break and get around the encryption. Maybe httpbis should have actually listened to him.

87 points by danielcorin 12y ago

yuhong 12y ago

Gogo is old news by now though.

hellbanner 12y ago
I hadn't heard of it. Glad to hear about this -- MiTM attacks & SSL spoofing is an important problem in today's internet security.
- fadzlan 12y ago
  Still, there will be a broken padlock icons in the browser. As much as they can read the traffic, they can't spoofed the identity. Not without having their own root cert on the customer side.
- ubernostrum 12y ago
  They don't successfully spoof it; that would require a cert signed by a root CA the browser trusts, and they don't have that. So what you'll actually get is not a web page, but an SSL cert error warning from your browser. If you're technically inclined enough to click your way through to see the actual page, I think all you get is a generic "YouTube is blocked" (and blocking YouTube is the reason why they do it -- they don't have the bandwidth to support it or other streaming video).
Animats 12y ago
Right. They're trying to tell you "you can't do that", but have no good way to do so. As I pointed out when this came up last time, the problem is that current network stacks and browsers don't propagate ICMP Destination Unreachable subcodes (such as "Host Unreachable - Communication Administratively Prohibited") up to the user. That's the proper way to express "you can't do that". Unfortunately, most OSs treat network errors like file errors, hammer them down to some small set of "errno" values, and lose the detail.

lemiant 12y ago

This is very different though, because it would throw an error.

MBlume 12y ago
It's training users to ignore the error, and that's bad, but yes, it's not as bad as komodia

patcheudor 12y ago

There are a lot of places which "spoof" or provide their own public in the TLS handshake. Top of mind is every single hotel I've ever stayed at which requires the entry of my last name and hotel room number via a captive portal. Of course in those cases the captive portal authentication page isn't the site I was originally going to visit, although some don't redirect and do leave the original destination in the address bar which is always an interesting trust issue, especially if the captive portal is asking me for my ISP password or a credit-card.

tyrfing 12y ago
Regarding hotel portals, this is relevant: https://securelist.com/blog/research/66779/the-darkhotel-apt/ https://securelist.com/blog/research/66779/the-darkhotel-apt...

fivedogit 12y ago

Slightly OT: CDNs basically perform a MITM to do what they do. The destination site's certificate (www.destination.com) is deployed throughout the CDN's servers and when DNS lookups are performed, the end user is directed to the IP address an optimal edge server where the certificate is waiting to greet them warmly. On the other side (first mile), the CDN then connects via a second SSL certificate (say, origin-www.destination.com) to the origin's datacenter(s) to retrieve the necessary data. When I worked at a CDN company, we frequently got inquiries from customers saying that a security audit they ran threw up a red flag for MITM. And it was my job to tell them why it wasn't anything to worry about. PS, most origin-www.destination.com origins are extremely vulnerable to DDoS since, at that hostname, there is no CDN to protect them.

general_failure 12y ago
While what you explain is correct, willfully giving/deploying your certificates in another server probably doesn't count as MITM
- Xorlev 12y ago
  Agreed. It's only MITM if it's unauthorized IMO. If I deploy my cert to a CDN its just legitimate handshakes so I'm not sure where the man in the middle comes in.
skuhn 12y ago
> On the other side (first mile), the CDN then connects via a second SSL certificate (say, origin-www.destination.com) to the origin's datacenter(s) to retrieve the necessary data. Perhaps. Not all CDNs require TLS to be used to connect to backends when the frontend is encrypted. This is completely obscured from the requesting client, and is a breach of user trust in my opinion. > PS, most origin-www.destination.com origins are extremely vulnerable to DDoS since, at that hostname, there is no CDN to protect them. This is a big problem that is rarely addressed until it bites you. When you're accustomed to a >90% hit rate and all of the nastiness of the Internet being handled upstream, you aren't going to be prepared for even a slight uptick in origin traffic. I saw one place whose site was served via Akamai DSA (http acceleration service), and routinely served >5Gbps. The origin consisted of two machines behind a Cisco ASA with a 100Mbit Ethernet port.

sjwright 12y ago

I think the two scariest discoveries with Superfish are that Microsoft allows an OEM to ship a retail Windows computer with additional root certificates, and that Chrome is trusting the root certificates stored by Windows -- Firefox does not. My proposed actions: (1) Microsoft should immediately update their OEM agreements to ban all manipulation of root certificates for computers sold at retail. Further, the root certificate store should be cryptographically signed by Microsoft and this signature validated during Windows OOBE. (2) Google should follow Mozilla's lead and have Chrome securely manage its own root certificate store. (It could be disabled for legitimate corporate deployments, but never with the regular end-user Chrome installer.)

toast0 12y ago
Chrome has chosen to use the system network (proxy) settings, the system SSL stack, etc. It actually makes sense for them to use the state CA store. Firefox's legacy includes platforms where there was no system any of that. As use shouldn't need to set proxy settings or corporate CAs for every application they run. Otoh, it is unfortunate that chrome has different SSL behavior on every platform.
- jesseendahl 12y ago
  When it comes to SSL/TLS, "on all platforms, [they] use NSS's libssl to handle the SSL connection logic... [and] ... platform specific APIs for certificate verification."
userbinator 12y ago
Further, the root certificate store should be cryptographically signed by Microsoft and this signature validated during Windows OOBE. This is just one small step down the path of not allowing any modification to the root certificate store, and that is an even scarier situation, since users will have absolutely no control over who they decide to trust.
- sjwright 12y ago
  I would agree with you if most users understood the concept of trust as it relates to the root certificate store. Very few do, likely less than 1%. Therefore I believe it must be Microsoft's responsibility to be the singular default trusted entity for the root certificate store shipped to retail consumers as part of Microsoft Windows. Your slippery slope argument fails because your "small step" would be immediately rejected by the vast majority of the Fortune 500, for starters. It just couldn't happen. It would be unworkable.

stevenjohns 12y ago

Okay I've never commented on my affiliation before because I don't want to advertise but this is ridiculous. I am the one who wrote the first article and 'broke' the story about Gogo's snooping [0]. Plenty of publications also reported on it after it reached high notoriety on Reddit. Some copied parts of my article, some didn't give a source or via to me, some made it appear like they were producing original news. That's fine, I don't really care: it happens to almost every single original article I write (one time I took a screen shot of my own Desktop as an article image and the other websites copied that too with no source) and I've grown use to it - I was just happy that it was making waves and forcing Gogo to reconsider their position. But in this case, Symantec has copied my original title verbatim. If you're going to literally copy my title verbatim, at least give a link back to it. Ridiculous. It wasn't even a good title. [0] http://www.neowin.net/news/gogo-inflight-internet-is-intentionally-issuing-fake-ssl-certificates http://www.neowin.net/news/gogo-inflight-internet-is-intenti...

TwoBit 12y ago
You need to list all that copying that was done on your resume. What better way to prove your skills than to show how much people are copying you.
- stevenjohns 12y ago
  If I was a career journalist I'd probably be more concerned, but I'm a software engineer and write just because I enjoy tech.
  - cmwelsh 12y ago
    Original research cited by major news organizations puts you on a whole new level above just "software engineer" for salary purposes. It's resume-worthy if you have a section for academic-type accomplishments.
    - stevenjohns 12y ago
      That's actually a really salient point. I've never considered it as 'research,' my mind just never made that connection for whatever reason. I'll keep it in mind from now on - thanks!

bsdetector 12y ago

Pretty sure I remember PHK warning that (paraphrased) if you encrypt cat videos along with everything else it's just going to cause more effort to break and get around the encryption. Maybe httpbis should have actually listened to him.