But if I use a webmail client, everything is sent HTTPS, I’m all good, right? (except for MITM?)
webmail often works with HTTP no encryption. While SSl/TLS is decent its not mil grade or anything.
Meflin
IF everything is sent HTTPS, then you’re all good. Also, my understanding is that even a man-in-the-middle attack can’t be used on an HTTPS connection, as long as you don’t accept any untrusted certificates. Can someone back me up on that?
Man in the middle for HTTPS generally requires a signed certificate trusted by your browser, or you accepting an untrusted certificate.
There are a couple of ways for a fake site to have a signed certificate trusted by your browser:
- Malware on your computer itself adds certs or certificate authorities to the trusted list
- Manufacturer/provider/employer adds certificate authorities to the trusted list. This happens, for example on some cell phone providers where they wanted to compress all traffic, or at some employers where they want to monitor all traffic.
- Compromised SSL provider already trusted by your browser issues a certificate for the website in question. Generally these tend to hit the news and get patched/revoked.
I had thought that normal SSL/TLS only authenticates the server, not the client, so a MITM could just pass challenges from the client directly to the server and send the responses back, but the MITM can respond to server challenges directly because the server thinks the MITM is the client and has no way of knowing otherwise. Is that not correct?
I’m not an expert, but my understanding is that with an SSL/TLS connection, traffic in both directions is encrypted. The MITM could establish an SSL connection to the host, but he couldn’t pretend to be that host to your client, because your browser client will use public keys that only the host would have the corresponding private keys for, to set up the session encryption keys. Assuming your browser doesn’t know the host’s public keys, it gets them from a trusted source from its list of certificate authorities. The MITM cannot provide this, unless your browser is set to trust that MITM.
Again, if I got some aspect of this wrong, I hope someone corrects me.
Traffic in both directions is encrypted. Leahcim you’re basically right as to how man in the middle works, but the man in the middle has to then send you a certificate that it knows the private key for, and unless it is somehow is trusted (via one of the methods I listed above), you’ll get the untrusted certificate warning.
The public keys you use to establish the SSL sessions actually come from the site you visit, but they are signed by the certificate authority (CA) and your browser has built into it either trust for that CA or a parent of that CA or a parent of a parent of that CA (chain of trust).
Even a MITM attack won’t work, unless your system has already been compromised.
Here’s the process. A server with an SSL certificate – let’s call it Alice.com – presents the certificate to your browser. Let’s call you Bob.
Bob’s browser knows the certificate is legitimate, because it’s signed – encoded with a key that can be verified by a trusted Certificate Authority. You, Bob, have a list of such trusted CAs on your system.
Meanwhile, the MITM is trying to eavesdrop. Let’s call her Eve.
The heart of this kind of encryption is this: it’s possible to have a complex encryption scheme that can be “locked” – encoded – with one key, and unlocked – decoded – only with a corresponding second key. Someone can have the “lock” key without being able to figure out the unlock key.
So alice.com and Bob will use this scheme to communicate: alice.com sends Bob her public (“locking”) key. Bob generates a random number, encodes that random number, and sends it back to alice.com. Alice.com unlocks the coded random number with her private unlock key. Now Bob and alice.com – and ONLY Bob and alice.com – know that random number, and they use that random number to encode and decode their communications to each other for that session.
Of course, eve may have been listening in the whole time. She sees the public key – the “locking key” that alice.com sends Bob. But she doesn’t have the corresponding unlocking key, so when Bob generates the random number and encodes it, Even can see the coded message but can’t unlock it. So she has no way to figure out the random number which is used to encode the rest of the conversation.
Eve could try to intercept the original message alice.com sent, substituting her own public key for the real alice.com key. But that won’t work either: Eve’s fake key isn’t signed by a trusted CA.