42

I'm making a few assumptions about basic email security, and I want to confirm or clarify some of these points to make sure I understand the big picture. Please correct me where I'm mistaken:

The answer to this question gives some insight, but doesn't cover all I'm looking for.

This is all assuming a traditional email service, accessed using a desktop or mobile client, over POP or IMAP, and SMTP (ignoring webmail).

Suppose I'm retrieving messages - my client app passes my username and password to the POP server, which authenticates me, and sends back the messages. If I'm not using SSL/TLS, then the entire conversation, including the message and credentials, is in plaintext. And anyone watching the network traffic can intercept the entire thing. And if I am using SSL, then the entire conversation is safe, even over a public network. Do I have that right?

My understanding is that traditional messages are insecure when my server talks to someone else's server - so the message itself is likely vulnerable while in transit between servers, but at least with SSL my email password would be safe.

If I understand, PGP or similar would mean that the message itself is encrypted, so that as long as my and the recipient's private keys are safe, nobody else could read the message. But that's just the message, right? Not the IMAP/SMTP/POP connection? Meaning if I used PGP for the message, but a non-SSL connection to SMTP, I'd still be sending plaintext username and password to authenticate.

Basically, I'm trying to understand why an email provider would refuse to offer SSL/TLS for POP/IMAP/SMTP connections - one particular provider says they don't do it because email is inherently insecure anyway, so SSL doesn't actually do anything to protect you, and they suggest PGP for truly secure email. I'd like to argue that while SSL may not be end-to-end message protection, it would at least protect my credentials and protect my message for a significant portion of its journey (me to SMTP server, and POP server to recipient assuming they're connecting with SSL).

Do I have everything straight with that?

Community
  • 1
Joe Enos
  • 523
  • 1
  • 4
  • 7

4 Answers4

27

To answer your question:

  • If you're using SSL/TLS to access your e-mails, regardless of whether it's POP or IMAP then it would be very difficult for anyone to decipher the text of the e-mails from analysing the traffic alone. That said some large companies e.g a law firm I used to work for have a server which sat between us and the internet, stripping out the SSL so the answer is a qualified yes in saying you're safe.

  • Also if the message is still sitting on the e-mail server after you access it, then it is possible for your e-mail provider to be bribed/coerced into handing it over. Of course GPG does solve this problem. You can also ask your e-mail provider to delete messages you download through POP though you have to trust that they're both able and willing to delete the messages securely.

  • With SSL, when logging in using your e-mail password, your password cannot easily be read by intercepting the traffic between your computer and e-mail server subject to the proviso I mentioned in point one.

  • Your understanding of PGP is largely correct. If a message is sent to you encoded with your public key then only you our someone who has broken your private key can read it. The sender's private key is irrelevant as he can't use it to decode a message meant for you. If your e-mail password were sent in plain text though you're absolutely right in thinking it could be intercepted and someone could access your e-mails or send them on your behalf pretending to be you. If you used PGP at all times to encrypt and sign all messages and others did the same for you, this would protect the content of your messages though.

  • I can't imagine why an e-mail provider wouldn't want to offer SSL beyond sheer laziness. You can even get free certificates these days! Most of the free webmail providers offer SSL e.g Gmail, have you thought about using them?

Stryfe
  • 286
  • 3
  • 2
  • 1
    Thanks, I appreciate the explanations. Not too worried about the major attackers or corporate security divisions - if they want my data, there's not a whole lot I can do to stop them. And yes, I'm not accepting the provider's laziness, and jumping ship to someone else. – Joe Enos Feb 14 '14 at 22:10
  • Keep in mind that (avoiding mail providers that may not use ssl/tls) you have to consider even who is receiving the email. He has to use ssl/tls either. – eKelvin Mar 21 '17 at 08:21
19

Suppose I'm retrieving messages - my client app passes my username and password to the POP server, which authenticates me, and sends back the messages. If I'm not using SSL/TLS, then the entire conversation, including the message and credentials, is in plaintext.

Not necessarily. SMTP, POP, and IMAP all can support multiple authentication mechanisms, some of which are encrypted (e.g., CRAM-MD5, GSSAPI). See a good list here under Non-plaintext authentication. In this manner, your credentials might be safe on the wire even though the actual mail isn't.

And if I am using SSL, then the entire conversation is safe, even over a public network. Do I have that right?

Yes, you do. However, as was pointed out in the thread you quoted, mail involves many hops. You may secure the client to the mail store server, but the path the mail takes from the sender's client to your mail store isn't provably secure unless you're using an end-to-end encryption mechanism.

Basically, I'm trying to understand why an email provider would refuse to offer SSL/TLS for POP/IMAP/SMTP connections

Because they're cheap, lazy, and nobody had to wear helmets on bikes when they were kids.

I'd like to argue that while SSL may not be end-to-end message protection, it would at least protect my credentials and protect my message for a significant portion of its journey (me to SMTP server, and POP server to recipient assuming they're connecting with SSL).

Yes, especially where those credentials are probably good for something else, such as managing your account with that provider.

Do I have everything straight with that?

Essentially, yes.

I would suggest, though, that you are wasting your time arguing with your provider about it. If they don't want to provide SSL, then find another provider. That's probably the only vote you could cast that they'd actually listen to.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • Thanks, hadn't heard of that kind of alternate authentication method for email before - the challenge/response concept seems pretty decent. But I'm guessing these guys don't support that anyway - if they do, they don't document it. And I'm with you 100% - definitely voting with my wallet. – Joe Enos Feb 14 '14 at 22:28
2

This question has been pretty well answered. But, it's worth taking a look at the delivery from the sender's outgoing SMTP server to the recipient's incoming MX server. This delivery is often done using STARTTLS to encrypt the SMTP connection. With STARTTLS, the connection starts off in plain text, then the connection is upgraded to an SSL/TLS connection if both sides support it. However, there are inherent problems with SMTP and STARTTLS that make it possible for an active attacker to perform a MITM attack. See this article for more info.

mti2935
  • 19,868
  • 2
  • 45
  • 64
  • That's what I am concerned about. Even if you force encryption at your organisation, you can not trust the receiver to reply to you in an encrypted manner, thus revealing your entire conversation. You can also not trust something intended to be secret not be discussed by a sender to you in clear text. There should be another protocol that forces encryption all together, so that no one can even send you an email without using PGP encryption or the like. – mjs Jun 23 '17 at 18:25
  • Even if the server decides to bounce an unencrypted message, the message might still contain information that is sent unencrypted and there would be no point in actually bouncing it other than to inform the sender that it could not be delivered. You might just as well then receive it and send a bounce letter of your own. As you mentioned regarding STARTTLS there is this obvious problem, why I'd like to see a protocol that always starts in an encrypted mode, although exchange of keys are always going to be a problem. – mjs Jun 23 '17 at 18:28
  • But then a third party might allow for the safe exchange of public keys at least the initial exchange of keys, which also can be disabled for you to distribute the key yourself, and when the public keys are updated/changed later on you would need to send all parties a new public key yourself using their stored public key. If a party have already changed their public key when you send a message, the message must bounce with information that the public key is outdated. This would include messages for public key change as well, so that if you send an update ... – mjs Jun 23 '17 at 18:31
  • ... regarding the update of your public key using someones outdated key, the same thing should happen, a bounce. You would then know that you need to contact the person in some other way to exchange the keys, or send a message containing a challenge that both parties know the answer to in order for automatic update of keys to occur. Now, lets implement this shit, because frankly, I am considering dropping the use of email all together. Just viewing my messagesource in thunderbird shows that all messages appear to be received in clear text. – mjs Jun 23 '17 at 18:34
  • Not sure if the message is actually received encrypted and then thunderbird is showing me the unencrypted message though, but I can not see anywhere whether my exchange is encrypted or not. I just can not believe that all these companies out there are basically sending sensitive emails all over the world for everyone to snoop on. Not strange that all these leaks are happening all the time, like the Panama documents ( CIA, NSA ). – mjs Jun 23 '17 at 18:36
1

As touched upon in this thread, SSL secures emails you have received only while in transit between the pop server and your machine , as well as those you sent only while in transit between your machine and the server smtp.

as stated by Stryfe, once sent the email arrives on the SMTP server, there is no evidence that the rest of the transit is secure until POP server of the recipient. Same thing on recipient side, where the path between your recipient machine and the email server is not secure; e.g. consider the case where the pop/imap server is in-house and an it team can have a look.

as for PGP mentioned couple of times; for having trying it, PGP is not easy to set up at all in enterprise with outlook, thunderbird, gmail and smartphone users. There are solid alternatives like CryptoMailer(http://www.thegreenbow.com/cryptomailer), although this one is immensely easier to setup and use.

Marco Madeira
  • 11
  • 1
  • Hi Marco, this answer doesn't add anything the other two haven't already mentioned, aside from the final paragraph which reads either like spam or a product recommendation - neither of which are useful here. – Rory Alsop Feb 21 '14 at 15:46
  • `Website unavailable This site is currently suspended. The site administrator has been informed. ` – Jonathan Jan 07 '19 at 21:33
  • See also: http://www.protonmail.com/ – Jonathan Jan 07 '19 at 21:33