7

I would like to "secure" my email, http servers and desktop client by connecting exclusively over TLS, be it email, in/out:80 or just regular "web surfing" traffic.

Will that prevent ISP and potential mans in the middle from spying on the traffic?

Quamchatka
  • 79
  • 1
  • 2

3 Answers3

8

Yes, assuming the following conditions

  • your web browser/email client is properly checking for valid signed certificates from trusted CAs with a valid chain of trust that have not been compromised and use strong encryption (e.g., 128-bit or greater symmetric key; 1024 or greater asymmetric key),
  • the CA was not fooled into signing a certificate (intermediate certificate) to the wrong organization,
  • you aren't fooled to go to a different site with a properly signed certificate but is actually phishing you, (e.g., you want to go to https://www.yourbank.com but instead get a link to go to https://www.yourb.ank.com which has a valid certificate for ank.com),
  • the servers at the other end do not have compromised private certificates and are not willingly sharing your traffic, and
  • there's no flaw in TLS that your ISP knows about that the rest of us do not.
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • and then you need to worry about local MITM attacks with WIFI and malicious nodes on your local network, but that's not ISP :) – schroeder May 31 '12 at 19:58
  • 1
    @schroeder - Local MITM attacks are still covered under the conditions said above. Data is encrypted at the application layer and without the server's private key other local computers can't get the secret encryption keys. That is unless the local attacker manages to get control of your computer somehow at which point you are completely vulnerable (e.g., install bad root certificates in your browser or just log the data passing through your browser or install a keylogger or install a malware eavesdropping browser extension, etc). – dr jimbob May 31 '12 at 20:26
  • You are correct, of course. But the potential vulnerability I don't think you directly addressed was the user not accepting bad certificates when they are presented in a run-of-the-mill MITM attack. The browser will properly validate the certificate, and prompt the user for verification. If the user accepts the certificate, then the chain is broken. I'm thinking of BEAST or Ettercap, for instance. But as I said, it's local and not ISP. – schroeder May 31 '12 at 21:38
  • 3
    There is also the risk of unencrypted e-mail passing between mail servers, which is completely out of your hands unless you encrypt your e-mail on top of TLS. – tdammers May 31 '12 at 21:40
  • 1
    @tdammers - Yup. All TLS ensures is secure transmission (no eavesdropping or MITM; but still can DoS and monitor when and to what servers data is being sent) of data between your computer and another server identified with a certificate. You or the server at the other end may take the securely transferred data and do something stupid with it in an infinity of ways (including your email example). Once the data is given away you have no control over it. E.g., your password/credit card numbers/etc went to the https site securely, but was stored in plaintext for an attacker to easily take. – dr jimbob Jun 01 '12 at 16:16
3

TLS is safe against attacks from attackers who control the transit network, including your ISP. This still relies on the validation of the server's certificate -- in a Web context, the browser does this validation against the set of trust anchors (aka "root certificates") that the browser vendor (Microsoft, Google, Mozilla...) found fit to include by default in the browser. To defeat this validation, your ISP might try to subvert one of these CA or get a CA of its own included in the set of trust anchors. An Evil ISP could give you a "connection kit" which does just that (in addition to connecting you to the Internet).

The same principle applies to other applications such as email user agents. Things may vary depending on the amount of verifications that each such software performs; for instance, it seems that the emailing app on my smartphone does not validate the server's certificate at all ! Instead, it "remembers" the certificate and warns when it changes (but then I am supposed to know, from the certificate's fingerprint alone, whether the new one is good or not -- that did not strike me as utterly practical).

As others have pointed out, for emails, SSL/TLS will only protect your data between your computer and the mail server. It will not protect the emails on the mail server (and, a fortiori, from the mail server) and neither will it ensure that the emails travelled only within encrypted tunnels when they were sent to you (some SMTP servers optimistically enable TLS, but not all). For a more thorough email protection, follow @D.W.'s advice and use an end-to-end protection system: S/MIME or OpenPGP.

Assuming that your SSL/TLS connections use the intended server's genuine certificate, and that the implementation of SSL/TLS is bug-free, and that you are not hit by a newly discovered flaw (like the recent CRIME attack), then you should be safe. SSL/TLS is the most studied tunnelling encryption protocol, and while its popularity means that it is the first target for any new idea of attack, it is also the first repaired protocol, and security patches are promptly produced and distributed. For the CRIME attack, affected browsers (Firefox, Chrome, Amazon Silk) where already fixed when the attack's existence was first revealed.

Your ISP still has the power to disrupt your connection (some Internet users would point out that their ISP appears to be very good at that job) and no amount of TLS will fix that.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
2

Realistically, if you need to protect the confidentiality of your email, then your approach is not the best possible approach. It might be good enough for some settings, but it is not a 100% robust way to secure your email.

There are a number of ways it could fail: your mail server might get hacked, or might share the email with others, or might forward it through other mail servers and happen to use unencrypted SMTP when it does so. Or you might mis-type the recipient's address, causing the email to be sent in the clear to someone you didn't intend. TLS is intended to protect traffic along one hop, but email often takes multiple hops, and since you only control the first hop, you cannot guarantee TLS will be used on all hops.

I think a more secure way to protect your email is to encrypt the email, e.g., using GPG or PGP or similar.

If your security needs are not that great, you could use TLS as you suggested. But understand that it is slightly fragile and not 100% reliable. So if you need reliable protection, GPG/PGP/etc. will provide stronger protection for the confidentiality of your email.

D.W.
  • 98,420
  • 30
  • 267
  • 572