Securely sending information from a web form to an email address

Question

Is it possible to have a user enter information into a form on an HTTPS secured site, then send that information using PHP to an email address securely? How do you encrypt the email so it's secure between sending it from an HTTPS site and checking it via HTTPS email? How feasible is this and what are the potential pitfalls?

Answer 1

You could encrypt the email with PGP or S/MIME. These will require special support in your client to decrypt. Most webmail providers don't have this (though there may be e.g., Firefox extensions to make it work).

Other than end-to-end encryption like PGP or S/MIME, it really isn't doable, because of email's clear-text legacy:

• It is possible to transmit e-mail between MTAs using TLS (with the SMTL STARTTLS extension). However, there is no way to mark a message as requiring it. You can configure your MTA to require STARTTLS, but not anyone else's. (Note that unless you have root, you can't even configure your MTA.) The default and normal configuration of MTAs will happily accept a message over TLS, and relay it plain text.
• Its normal to add relays when needed. In practice, they are frequent. So your message may take a couple of hops before final delivery. You can force TLS for the first hop, but none of the others. You can check Received: headers to see how many hops a message took, but that may change at any point (and it may change from message to message for operational reasons).
• Generally speaking, mail while in transit is written to disk. The normal MTA process is accept message, write to disk, confirm receipt, send message to next MTA, wait for confirm, delete from disk. You can certainly configure your MTA to store these on disk encrypted, but generally that's not done.
• Once "delivered", mail is usually stored in plaintext on disk. Your web mail provider probably does so.
• If you ever use a non-webmail client to access the email, its very likely it downloads messages to disk, in plain text. Then you have unencrypted messages sitting on a random desktop PC. The MUA may even transfer messages over the Internet in plain text.
• Email is easy to access anywhere, from any machine. Especially webmail. It will be very tempting for you, or someone else in your company, to log in to the account the messages are sent to from random devices. Can you guarantee none of those devices has any malware—key logger, session hijacker, screen scraper, etc.—installed? Can you guarantee no user will ever ignore the certificate warning, enabling a man-in-the-middle attack?

Except for a few of the very largest webmail providers, they probably don't have sufficient security to protect confidential identity data. E.g., if you call them up and say you forgot your password, how do they handle that? Or, if someone else calls them up and pretends to be you.

Lastly, even with PGP or S/MIME, you're left with the problem that email, in the real world, can and does get lost. Your site may send a message, get confirmation that the message is accepted for delivery, and then that message just never arrive—not even to a spam folder. That generally isn't acceptable for valuable data.

note: If you encrypt the message with PGP or S/MIME, using sensible settings (e.g., 3072-bit or higher RSA keypair, AES cipher), then it doesn't matter if the email message (ciphertext) is disclosed; it is unreadable without the private key. The crypto used is fairly similar to TLS (but unfortunately doesn't offer things like perfect forward security as its an offline protocol). End-to-end crypto protects against insecurities between the endpoints. Not that I'd advocate printing the cihertext in a newspaper, but even that should still be secure. You must, of course, keep the machine which holds the private key (and decrypts the emails) secure.