4 ms·
Sounds like only Chrome has been updated to reflect this? Which means all Android/iOS apps that rely on a secure channel to a *.google.com domain can be MITMed?
by RyanZAG 14y ago
Sounds like only Chrome has been updated to reflect this? Which means all Android/iOS apps that rely on a secure channel to a *.google.com domain can be MITMed?
If so, then current SSL should be regarded as 'broken' effective immediately and not used for secure transactions with Google (and probably anybody else).
- cleverjake 14y agoI would assume the cert was revoked, this is about how they do not trust any cert signed by the same authority.
- lmz 14y agoEven if the certificate was revoked, how do the Android devices know that the certificate was revoked? Do they regularly update CRLs or do they check using an online protocol e.g. OCSP?
- RyanZAG 14y agoDo SSL libraries in Java/ObjC use OCSP correctly? As far as I can tell, Android has OCSP disabled by default as the increased latency can be harmful on mobile. I believe Firefox has OCSP disabled by default as well?
- 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 agoThat'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 agoI 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 agoYou can implement that by installing the CertificatePatrol addon for Firefox.
- mpyne 14y agoThat's mostly what certificate pinning does already, if I'm understanding the concept right.
- uiri 14y agoThat'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.
- jrabone 14y agoAt least on my Android devices, you can select which root CAs to trust via Setting -> Security -> Trusted Credentials. Click on TURKTRUST, scroll down and click "Disable". Repeat. YMMV as I'm running Jelly Bean on both phone (CM10.1) and tablets (stock).
- fpgeek 14y agoI don't know about anyone else, but I just tried this on my Galaxy Note 2 and the first certificate was a TURKTRUST certificate! Apparently, it sorted that way because the name started with "(c) 2005". There was also another certificate further down, but I'm amazed by the apparent coincidence (unless sloppy procedures led to an unusual certificate name, I suppose).