I'm just wondering if it is possible for someone to MitM me in the following scenario and intercept plaintext traffic:
dovecot imaps server with real thawte "quick" cert | imaps (ssl) | public wifi | android phone using imaps using "ssl" not "ssl (any cert)" option
For instance, can a malicious hotspot use some sort of interception technique / spoofing and some sort of wildcard cert to trick my phone into negotiating SSL with it, which then does its own SSL to my dovecot server, thus MitM'ing me without me even knowing? I know in a web browser I'd normally be protected against that by looking at the URL in the address bar, or the green EV-cert graphics (or am I wrong in even that assumption)?
How paranoid do I have to be? And is there any way to beat any shortcoming on Android, perhaps with a client cert or a way to tie the account to a single manually-specified server SSL cert?
I'm pretty sure you're OK as long as the phone is still verifying that the CA signing the received key is known. (you could test this with a self signed certificate)
The EV bar doesn't provide any better crypto, it's just a set of tags on the cert indicating the issuee has undergone extra offline validation. Each CA that can issue EV certs has its own tag so it's not like someone could make a CA and sign with the EV tags.
Wildcard wise, wildcards only work for one level of subdomain and not on EV certs.
SSL interception needs you to inject a root CA certificate into the client. The proxy generates a new certificate signed by the fake CA when something is requested, pushes that behind the client, then stitches the two sessions together. The only way the client knows is that the certificate is signed by a different CA. I've done this as part of a web filter at a large company, we needed to use Microsoft group policy to push out that key. It can work transparently or with the browser having configured a proxy. But without the client having the proxy's CA in the certificate store, all certs look broken.
Related: I talked to Sean Cody on a podcast about stuff like this about a year ago. I still think it's the most enlightening discussion about SSL and trust that I've ever had. http://linuxadminshow.com/2012/09/22/episode-2-ssl/
Sean
On Sat, Jan 18, 2014 at 3:37 AM, Trevor Cordes trevor@tecnopolis.ca wrote:
On 2014-01-18 Sean Walberg wrote:
Wildcard wise, wildcards only work for one level of subdomain and not on EV certs.
Thanks for all the help guys, I'll slog through implementing the ideas tonight. As I thought, it's not as simple as it looks to be. I'm sure I'll have more questions.
Just a quick Q on wildcards/certs: so if I'm understanding right, a wildcard doesn't help a hacker, as they can't buy a * they must buy a *.something.com, right?
Yes, there would be the issue of a rogue CA selling a malicious wifi hotspot guy *.mydomain.com but there's no way they could do that on the fly quickly while I sit down at their wifi for only 15 mins and never return. Right? I guess my question was more whether they could instantly generate MitM certs for everyone who connects and intercept everything easily. (I thought that is what some hotspots do for HTTPS?)
In all cases, I am assuming I have sole, complete physical control and access to my phone, and that the OS hasn't been compromised. After all, you have to start somewhere and assume some level of security. And if they rootkitted my phone, them getting my IMAP credentials would be the least of my worries.
Thanks!
Friends don't let friends use wildcard certs. There in the past have been rather annoying bugs relative to wildcard processing.
There is an x509 extension called Subject Alternate Name (aka SaN), this a means of adding alternate names to a certificate (specifically setup to avoid the issues of wildcards yet allowing for http vhost utility).
The common name in the certificate is just one of the basic constraints, sig needs to match as does the signer needs to validate etc. The common name field is just the field you typically see. In point to point SSL uses you can expand the constraints to validate more of the fields which makes it harder to forge a good signature.
The 'bad guy' just needs to make a certificate VERY close to the one you are looking at or one that satisfies a bug in the wildcard expression parser. For instance *\0.whateveryouwant.net the \0 is 'null' which would match _any_ URI. There are most definitely good uses of wildcard certificates (like proxy farms, load balancing) but for a single host with a single IP, it is irrelevant.
Your 'bad guy' just needs to forge a CA you already trust or convinces you to trust then you are completely hooped. They could also (if they were bad ass enough) take the contents of the intended server certificate and subtly change things enough to convince your client it is the same certificate. This is an example of why MD5 collisions are well... a non-trivial issues. Recommendations for that is to use a certificate with SHA-? signatures instead of MD5 but you can't control what your CA signs... hell most CAs these days don't respect your CSR and just pull the CN and key and create their own CSR to sign.
Like Mr. Walberg said you are pretty good already doing certificate and CA validation is a solid step and being SUPER cautious about modifications to the CA/certificate trust store is 50% of the battle.
Step 1: (dovecot.conf) ssl = required ssl_cipher_list = HIGH:!LOW:+TLSv1:+SSLv3:!SSLv2:!SSLv1:!RC4:!MD5:!aNULL:!eNULL or ssl = required ssl_cipher_list = ALL:!LOW:!MEDIUM:!MD5:!SSL2:!EXP-ADH-DES-CBC-SHA:!EXP-EDH-RSA-DES-CBC-SHA:!EXP-DES-CBC-SHA:!EXP-EDH-RSA-DES-CBC-SHA:!EXP-ADH-DES-CBC-SHA:!EXP-DES-CBC-SHA:!ADH-AES256-SHA:!ADH-AES128-SHA:!ADH-DES-CBC3-SHA:!EXP-ADH-DES-CBC-SHA:!EXP-ADH-DES-CBC-SHA:!ADH-DES-CBC3-SHA:!aNULL:!eNULL
#(see 'openssl ciphers -v' pay attention to the Enc=cipher(keysize) columns) Step 2: Don't trust DNS in client/host configuration (including for CA CRL validation). Step 3: Explicitly add (and set trust) for the server certificate in your phone's trust store. Step 4: Setup a unique (as in keys) encrypted tunnel for ad-hoc use when things look funny. Step 5: Use client certificate infrastructure.
In the above you can harden things by removing variables... do as much of the above as the level of effort and paranoid you have warrants.
Step 1: Let's stick to 'stronger' ciphers and TLS1+, SSLv3 (note... TLS1.2+ would be nice but can be annoying if client support isn't up to suff). Step 2: Untrusted upstream... don't trust configuration services on said provider. Do you know for certain the DNS response is what you expect? Well magic number those IP configs because that's one less easy redirection. DNSSec is nice but well who does it? Step 3: Don't trust the public key being passed on the wire, compare it to a known copy. There are some neat ideas out there about certificate notaries but not a lot of traction yet. (also...https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning) Step 4: Setup VPN tunnels... recent VPN exploit in android should be noted but it's rather specific, still better than nothing. L2TP is rather trivial to setup, OpenVPN is well not terrible but also not awesome. For either, use different keys for all your devices. Hell, maybe even setup Tor? Step 5: Use TLS client certificates, same 'concept' as ssh key based authentication but well requires a lot more effort on your part to setup (and you'll have to manage your CA certificate on top of client certificates). That deals with your transport layer and then use your IMAP normal credentials, recommend you cut certificates for every device, enable CRL/OSCP and revoke certs when expired or you decom/destroy/lose devices.
To my rube like disposition... all CAs kinda suck. When using a 3rd party CA I tend validate more on the depth of the signing, ciphers used and key length more than I care about what company issued it. As along as you avoid the self signed 0 depth cert and put some care and concern in to CA choice/management then you get what you get and no less. $>X is a weak indicator of trust and event weaker replacement for effort.
Since I have exactly zero android devices I can't comment there, though the 2nd gen Nexus 7 looks pretty enticing at the price of 1/5th a good snow-blower.
Have fun,
-
Sean Cody -
Sean Walberg -
Trevor Cordes