2

I'm working on a Java web-application which runs on a HTTPS connection. This application sends emails to its users. I want to protect those emails from man-in-the-middle attacks and other potential threats. My questions are:

  1. Do I need to encrypt my email content? Why and How? Why not?
  2. Doesn't HTTPS encrypt the data transmitted automatically?
  3. If I have to encrypt them manually, how will the receivers decrypt it?
  4. Whatever solution you suggest, what is the likelihood and severity of potential threats?
  • I can already comment that no, unfortunately the mails are not encrypted even if your webapp runs on https – niilzon Mar 15 '16 at 9:59
6

Assuming that everything is done right (everything, which is not a given especially if one does it oneself), HTTPS still would't protect your email as emails are not using that protocol to be transmitted. Because you actually need to send the actual email to other servers using the "email protocol": SMTP. But even then, this is a bad idea.

For instance, what are these "other servers" exactly? If you recipient is at gmail for instance, you have to send the email to the gmail servers, right? However this is not exactly how SMTP is working: you email will hop from mail servers to mail servers until it reaches its final destination. This connection can be direct but there are no guaranty that it will actually be, far from it. This simple fact makes end-to-end encryption within SMTP impossible by design: each realy/MTA is a MitM! Yes, there were attempts at making SMTP secure but the design is still just bad from a security standpoint. See this Wiki article for instance, especially:

Mandatory certificate verification is not viable for Internet mail delivery. As a result, most email that is delivered over TLS uses only opportunistic encryption.

Opportunistic here means that it defaults to clear text whenever someone illegitimately wants to read, if anything in the middle is broken, if anything is not configured properly, etc. And the worst is that it's not because your connection to the first relay (called MTA, in the other answer) is actually secure (because you did a good job wasting 8h of you time in configuration and thorough checks) that the connection between that very first relay with the second will be secure. You have no guaranty of that whatsoever (and again, the relays themselves can be evil).

Solutions?

  • Don't send clear-text emails. Use PGP/GPG, S/MIME or equivalent to crypt your emails if you want secrecy. These provide end-to-end encryption but require a fair bit of configuration from your side and from your user side. To be done properly (and actually provide privacy), you need to manually authenticate each user. This may not be possible.

  • Another solution would be to use a protocol already designed to be secure which provides end-to-end encryption (some IM protocols are actually quite good for this).

  • As proposed in the other answer, provide an email with a link to a protected HTTPS page only accessible to authenticated users (a token in the URL won't do).

However, never ever use SMTP (with or without TLS/StartTLS) if you need a guaranty of a minimal amount of privacy. SMTP is not secure.

  • Hi, this is not my question, but I'm interested on the topic, so referring about second solution, could you tell me some protocols which you recommend, please? – hmrojas.p Mar 15 '16 at 16:13
  • Well, XMPP comes to mind. It can be used on proper TCP/TLS or within HTTPS to bypass moronic firewalls. The problem is that it is not as publicly widespread as SMTP (well, nothing is except HTTP). But interesting things can be done with it. In the proprietary realm, things like GG Hangout also work very well and the "archiving" part is well thought (you can retrieve/search old conversations from any GGHangout client: the server sends back everything you need). – JPatta Mar 15 '16 at 18:25
  • That said, end-to-end encryption is not supported natively (yet, at least for XMPP), however the existing E2E encryption implementations are far more widespread and easier to use than in the SMTP world. If you are looking for something really strong where there is no intermediaries, look at Firefox Hello (and similar) for instance. No need for an extra end-to-end encryption layer: the protocol already provides strong privacy. – JPatta Mar 15 '16 at 18:32
  • And I would avoid ToX for the time being: a few things are a bit fishy about it... – JPatta Mar 15 '16 at 18:33
  • What to you mean exactly with SMTP is not secure? What threat are you thinking about? And if you need more privacy, don't you need a VPN between the sender and the receiver of the message? – Serge Ballesta Nov 15 '16 at 17:26
3

One way to verify the communication path and configuration, at least from the perspective of you (the client) communicating with the direct Mail server (Microsoft/Apple/Google) is to run Wireshark (sniffing tool and packet analyzer) and send an email from one account to the other. depending on how you have your mail client setup, you can see the communication path that is being created and whether encryption (at least for the initial path) is encrypted, i.e.: using some type of TLS/SSL encryption path. Once on the company Mail Server, it is really difficult to evaluate whether the entire path from hop to hop of different DNS and Mail Server is encrypted. SMTP, POP3 IMAP, MIME all do not use data encryption or header encryption by default.

1

Simply because your web application is only accepting incoming HTTPS connections, does not mean that all the emails it sends are encrypted... This is the responsibility of the underlying SMTP server. You should configure the SMTP server to only send encrypted emails. So:

  • A1: Yes, but not on application level. Configure the SMTP server to use SSL/TLS between the client and itself, and for inter MTA communication.
  • A2: Yes it does; between client (the end-user's browser) and server (the web application). Not between the server and the SMTP server (since that isn't done through https).
  • A3: Exactly, they can not. This is why you need to configure the SMTP server to rely on SSL/TLS's encryption mechanisms and not encrypt data on application level.
  • A4: If the POP/IMAP server of the destination is not properly configured, it could download the emails plain text, which reveals an opportunity to man-in-the-middle...

If the content of the email is really that sensitive, I would opt not let it leave the application at all. You could send emails to the users to notify them a new message is available on the portal, and that they should log in to see it. Of course, this is less user-friendly than a direct email... This is the part where you have to weigh confidentiality of data vs user-friendliness, and decide upon.

  • The server configuration is a pain and that's useless: MTAs have access to the email content (MitM by design) and you can't force MTA to use encryption (downgrade attacks are sooo easy because the encryption is opportinistic or the certs are not checked). SMTP is not and never will be a secure protocol. However, I totally second your last comment! – JPatta Mar 15 '16 at 12:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.