email - Thunderbird: SSL/TLS vs. STARTTLS

16
2014-04
  • Foo Bar

    Following up this question on serverfault "Is STARTTLS more safe than TLS/SSL?" it came up that the question is rather a question about Thunderbird and not about the actual protocols. Also, if you Google about this topic you will find many different answers contradicting each other.

    Thunderbird (talking about current version 17, but it's like this since version 3) offers three methods of encrypting transfers:

    • None
    • SSL/TLS
    • STARTTLS

    And before TB version 3, there were these option

    • None
    • SSL
    • TLS
    • TLS, if available

    With TB version 3 the last two where merged and renamed to "STARTTLS" and the "SSL" was renamed to "SSL/TLS" in the config dialog. And now according to this question and answer "Secure email sending with Thunderbird?", Thunderbird could fallback to plaintext transfer when using STARTTLS without noticing me! STARTTLS is also the default configuration of Thunderbird.

    The question are:

    1. Can Thunderbird really fall back to plaintext transfer without telling me and establishing the connection anyways (which would be a security risk)?
    2. What version of SSL, TLS and STARTTLS does Thunderbird support?
    3. Is there some indicator in TB telling which encryption method (protocol and version) is actually used?
    4. Is there a way to force TB to use TLS and if not supported by server to not connect at all? (option "SSL/TLS" seems it can't handle TLS (I tried it), and STARTTLS which could do TLS may have the "silent fall back" security risk)
  • Answers
  • Petr Abdulin

    1) That's possible. According to the specification:

    2.3. Clear-Text Password Requirements

    Clients and servers which implement STARTTLS MUST be configurable to refuse all clear-text login commands or mechanisms (including both standards-track and nonstandard mechanisms) unless an encryption layer of adequate strength is active.

    thus, there MUST be a checkbox which would specifically restrict plain-text login. But there isn't. I expect that this is a default behaviour in Thunderbird, but I don't know for sure, so we can expect that.

    2) I guess it support all major versions used. SSL is obsolete and slowly being replaced by TLS. However contradictory to it's name STARTTLS can use SSL as encription protocol, all depends on the protocols that server supports.

    3) I don't know about such possibility.

    4) I guess 1) answers that too (i.e. you can't force it, but most probably that's default behaviour). Note: "SSL/TLS" and "STARTTLS" isn't interoperable protocols (that's why they use different ports).


  • Related Question

    GMail and SSL Encryption - how much is encrypted
  • hatorade

    It's strangely difficult to find out exactly how SSL works with email, at least insofar as answering my specific question - when I connect to gmail using SSL, I understand that my connected is secure and thus data is all encrypted between MY COMPUTER and the GMAIL SERVER. However, is that all SSL does? For example, when I open an email on my computer, the data between Mountain View (or whatever) and my house is encrypted? Would that mean then if I email my friend who also uses gmail with SSL/secure gmail enabled, then if I send an email also with an attachment to his gmail account that email as well as the attachment are encrypted at my computer, sent to GMail server, and then provided my friend uses SSL then he can security acquire the email too? So there is no need for those firefox encryption addons? Are those just for more robust encryption algorithms?

    So in summary, here is what I think I have learned (and provides a summary for others reading). PLEASE CORRECT ME IF I AM WRONG:

    1. gmail sends emails to google servers with HTTP. gmail also retrieves emails from google servers with HTTP. when you connect to the google servers using https (as opposed to http) then the connection between your gmail client and the gmail servers is secure and data is encrypted going back and forth between the two.

    2. when using a client (thunderbird for example) SMTP is used to send emails, and IMAP/POP are used for retrieving emails. At the add-on/options level, you can tell these clients to use TLC for both the SMTP and IMAP/POP steps.

    3. The google servers probably don't use TLS with SMTP when bouncing emails back and forth amongst their servers.

    4. Conclusion - if using gmail, always use HTTPS but know there is no encryption between google's servers, but in the 'outside world' the connection between google clients (as long as using https) is secure. if using thunderbird (or something else) turn on TLS.

    Is this correct?


  • Related Answers
  • jtimberman

    When you trust the certificate from the site encrypted with SSL, you can:

    • Trust that the connection to that web server is encrypted.
    • Trust that the identity of that web server is correct (ie its not phishing scam).
    • Trust that someone isn't intercepting your traffic to the web server (man in the middle).

    (the important thing here, of course, is that you trust the certificate presented by Google's mail server, which you generally should :-))

    The data you submit in a form when composing an email will be encrypted through HTTPS as it travels from your client browser to the Gmail server that will pass it off to the SMTP server. When you display mail in your browser from the server, this is also encrypted.

    SMTP does not encrypt mail, however. There are ways to use TLS (transport layer security) over IMAP and POP to encrypt the authenication data from the user/client to the server. When you connect via IMAP/POP with TLS, the data you receive when retrieving mail is encrypted from the server to you. IMAP and POP are retrieval protocols only. When you use an external client such as Thunderbird to send mail, it will go through an SMTP server. This can be encrypted as well using SASL/TLS with SMTP, but again that is only from your client to the server, and not from the server to its final destination.

    If you want to send and receive encrypted email end to end, no matter where it goes on the network, then you need to look into a solution like PGP/GPG. For more information about this, see the question I asked. Gmail's webui doesn't support usage of PGP/GPG, so you'll need to set that up with an external mail client such as Thunderbird, Mail.app, or Outlook (or others).

    As far as email you send from your Gmail account to a friend's Gmail account, it is sent around inside Google's internal mail infrastructure. This may have one or more hops between servers, but usually stays within their private (10.x.x.x) network. You can verify this by looking at the headers of the email your friend sends. From the email in the Gmail webui, hit the drop down button next to the "Reply" and click "Show Original". You're looking for lines that start with "Received:", like these:

    Received: by 10.215.12.12 with SMTP id p12cs100615qai;
            Sun, 18 Jan 2009 15:04:17 -0800 (PST)
    Received: by 10.90.100.20 with SMTP id x20mr2195513agb.12.1232319857088;
            Sun, 18 Jan 2009 15:04:17 -0800 (PST)
    Received: by 10.90.68.11 with HTTP; Sun, 18 Jan 2009 15:04:17 -0800 (PST)
    

    This is a Gmail to Gmail message I have. The first (last) message here indicates that the mail server 10.90.68.11 received the message in question from an HTTP connection (webui). Then the mail went via SMTP to 10.90.100.20, then SMTP to 10.215.12.12, where it was delivered to me.

    Again, while this is all internal to Google's network, SMTP should not be considered a secure protocol for sending sensitive information. Anyone who has access to the systems in the chain above can potentially read the message. Also note that Google Apps may go through a gateway system on their network that has an external address (still owned by Google, though).

  • dlamblin

    Your data is not secure.

    People are always worried about the data in transit, but the basic fact is that the data storage is the main point of where attacks happen. E.G. Credit cards generally get stolen from files and databases of numbers, and not from the transport of the numbers.

    Google stores your data. The storage is not encrypted. People at Google, or those who compromise Google can one day read it, if they actually care to. The recipient of the mail can also read it, and the owner of the recipient's mail server (ISP or company) can too. If the recipient is using a regular mail client, it is stored on his/her machine. This is where any spyware or rootkits that the recipient has installed could get at it.

    In transit, jtimberman is right. Your browser is talking to Google, if you trust that the machine that sent you the certificate is Google, and that Verisign or whomever is a trustworthy company which tells you that Google did actually send you Google's certificate. While the browser talks to Google with the certificate over https, the transmission is encrypted. This is nice, because it means that all the other PCs on your network with possible spyware or nosey-users, and the network admin, cannot read how much you complain about them every single day.

    You also have to trust your browser, AND all it's plug ins. They can pretty much just read what's in the forms before you even sent it. Generally you can trust it, but not those nosey tool bars everyone is asking you to install along side all those free programs you download.

    But overall, say you sent someone an email and it contained your tax-id, birthdate, current address and legal name, something an employer maybe needs to know, you'd think of that as sensitive information. Well that email is stored forever by Google in the sent-mail area. Even after you delete it. And the recipient is going to store a copy in their inbox. The mail server of the recipient could be storing a copy. The mail-server of the domain of the recipient's mail-server could be storing a copy, but not for long. And a number of more servers in between. ALSO smtp sends mail between these quite unencrypted, but what's scarier, that some criminal's malicious program might be listening to the right network at the right time to catch the data in transit, or that some other criminal's malicious program might one day get installed on any of the machines that now contain a copy, find that copy, then send the data to the criminal's organization?

  • SacRyan

    GMAIL's SSL encryption does only protect your data in transit. So in your example of your e-mail message going from you to gmail and then from gmail to your friend, all of the transmissions would be encrypted, however, the data at rest on the gmail servers (a copy in your sent items and a copy in your friends inbox) would all be readable data. If you trust google to keep your data safe, then you are okay.

    Which of the firefox add-ons are you thinking of?

    jtimberman is right that you would need a 3rd party program like pgp/gpg to encrypt your mail messages so that Google couldn't read them.