[RndTbl] MitM on IMAPS?

[Sean Cody]

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
P.S. Thanks, Mr. Walberg, I appreciate the kind words... yeah that was an interesting chat.

On Jan 18, 2014, at 3:37 AM, Trevor Cordes <trevor at tecnopolis.ca> wrote:

> 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?
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable
>