Is email sent form a Java web-app over a HTTPS connection encrypted?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.