4 ms·

> Which means all Android/iOS apps that rely on a secure channel > to a *.google.com domain can be MITMed? http://mitmproxy.org/doc/certinstall/android.ht

by kanzure 14y ago

> Which means all Android/iOS apps that rely on a secure channel > to a *.google.com domain can be MITMed? http://mitmproxy.org/doc/certinstall/android.html http://mitmproxy.org/doc/certinstall/android.html

RyanZAG 14y ago
That's hardly the same thing - you have to actually run/install something on the Android device itself. With this fake Google certificate, I can install a box between 2 routers anywhere between you and Google - say on an open wifi hotspot or in your ISP's server room. I can then set up a simple transparent forwarding proxy that will provide the fake Google certificate for any Google SSL requests, and forward on other requests as normal. I can then log all data passed between you and Google, such as session cookies, emails, credit card details on Google wallet, etc. This is extremely problematic as it is effectively invisible to users and can be easily used by governments such as China to ensure they have full access to anybody's encrypted communications with no risk to themselves and very little chance of being detected. Basically, SSL, HTTPS and anything else relying on CA certs should be regarded as broken, and you should even expect that a hostile government will be listening in. USA government, for example, has full access to AT&Ts server rooms and backbone routes. China has full access and control of any network infrastructure involving communications over Chinese borders.
- deleted 14y ago
  [deleted]
- gcr 14y ago
  I kind of wish we went to the SSH model, where you accept the identity of all servers you visit, and you get loud warnings whenever the identity changes. But even that has huge problems. (For example, who ever double-checks their SSH server fingerprints in their known_hosts file?)
  - caf 14y ago
    You can implement that by installing the CertificatePatrol addon for Firefox.
  - mpyne 14y ago
    That's mostly what certificate pinning does already, if I'm understanding the concept right.
  - uiri 14y ago
    That's what SSHFP records are for. You store the fingerprint of the SSH server in DNS and then turn on a setting in your ~/.ssh/config and it will check for you if it matches with DNS when you try to connect. Even without DNSSEC it creates another thing which needs to be spoofed.
- kanzure 14y ago
  > That's hardly the same thing - you have to actually > run/install something on the Android device itself. I was scratching my head trying to figure out where the impedance mismatch was between our two comments... first, you're obviously talking about man-in-the-middle attacks on untouched devices in the wild. Second, your original statement that I was quoting was about intercepting Google apps that contact *.google.com, which I was pointing out that you can do anyway in a controlled environment. I thought you were surprised about the latter in the context of app security, otherwise why would you mention those apps specifically instead of the entirety of all traffic you can intercept etc.
  - RyanZAG 14y ago
    The general issue is that if your communication between your device and server is going over HTTP, then anybody can sniff it and modify it. This is pretty well known, and the 'solution' is to use SSL. Unfortunately with these open .google.com certificates in the wild, any android device that would have been securely connecting with SSL to a google server is now wide open to MITM as if it wasn't using SSL at all. I mentioned .google.com in particular since that's the certs floating in the wild, but obviously certs could be made for any site. *.google.com is also of particular issue as your Android device will hold a secure channel open for commands from Google Play. Anybody who can pretend to be Google Play can add/remove applications from your device as they wish, and Google Play itself runs with elevated privileges and can be used to keylog passwords, intercept credit cards, etc. This is bad stuff, man. At this very minute, someone may have installed a fake cert at your ISP, and your Android device may in fact be compromised without you having any idea. Obviously a completely different issue to hijacking traffic in a controlled environment!

by kanzure 14y ago

RyanZAG 14y ago

That's hardly the same thing - you have to actually run/install something on the Android device itself. With this fake Google certificate, I can install a box between 2 routers anywhere between you and Google - say on an open wifi hotspot or in your ISP's server room. I can then set up a simple transparent forwarding proxy that will provide the fake Google certificate for any Google SSL requests, and forward on other requests as normal. I can then log all data passed between you and Google, such as session cookies, emails, credit card details on Google wallet, etc. This is extremely problematic as it is effectively invisible to users and can be easily used by governments such as China to ensure they have full access to anybody's encrypted communications with no risk to themselves and very little chance of being detected. Basically, SSL, HTTPS and anything else relying on CA certs should be regarded as broken, and you should even expect that a hostile government will be listening in. USA government, for example, has full access to AT&Ts server rooms and backbone routes. China has full access and control of any network infrastructure involving communications over Chinese borders.

deleted 14y ago
[deleted]
gcr 14y ago
I kind of wish we went to the SSH model, where you accept the identity of all servers you visit, and you get loud warnings whenever the identity changes. But even that has huge problems. (For example, who ever double-checks their SSH server fingerprints in their known_hosts file?)
- caf 14y ago
  You can implement that by installing the CertificatePatrol addon for Firefox.
- mpyne 14y ago
  That's mostly what certificate pinning does already, if I'm understanding the concept right.
- uiri 14y ago
  That's what SSHFP records are for. You store the fingerprint of the SSH server in DNS and then turn on a setting in your ~/.ssh/config and it will check for you if it matches with DNS when you try to connect. Even without DNSSEC it creates another thing which needs to be spoofed.
kanzure 14y ago
> That's hardly the same thing - you have to actually > run/install something on the Android device itself. I was scratching my head trying to figure out where the impedance mismatch was between our two comments... first, you're obviously talking about man-in-the-middle attacks on untouched devices in the wild. Second, your original statement that I was quoting was about intercepting Google apps that contact *.google.com, which I was pointing out that you can do anyway in a controlled environment. I thought you were surprised about the latter in the context of app security, otherwise why would you mention those apps specifically instead of the entirety of all traffic you can intercept etc.
- RyanZAG 14y ago
  The general issue is that if your communication between your device and server is going over HTTP, then anybody can sniff it and modify it. This is pretty well known, and the 'solution' is to use SSL. Unfortunately with these open .google.com certificates in the wild, any android device that would have been securely connecting with SSL to a google server is now wide open to MITM as if it wasn't using SSL at all. I mentioned .google.com in particular since that's the certs floating in the wild, but obviously certs could be made for any site. *.google.com is also of particular issue as your Android device will hold a secure channel open for commands from Google Play. Anybody who can pretend to be Google Play can add/remove applications from your device as they wish, and Google Play itself runs with elevated privileges and can be used to keylog passwords, intercept credit cards, etc. This is bad stuff, man. At this very minute, someone may have installed a fake cert at your ISP, and your Android device may in fact be compromised without you having any idea. Obviously a completely different issue to hijacking traffic in a controlled environment!