The Problem with PGP
E-Mails probably is the most insecure way to communicate. But most people are not really aware of it. You can send an E-Mail from almost every server to every recipient and of course, if you control one server that is in between the sender and the recipient, you can read it all in plaintext. Here's a little illustration how E-Mails work.
To watch how many servers in just one of the steps are involved just use traceroute to check.
Windows
To overcome all those security issues there were many attempts to improve the protocol. But first of all, let's look at how easy it is to fake a mail. Have you ever tried to use the mail command in PHP. You just type in the sender, the recipient, the subject and the text and the mail is sent. Whatever sender you choose. It is even more astonishing if you try out the low-level telnet connection. For some more details go to Wikipedia.
For confidentiality a standard PGP encryption is quite good. But this often leads to a false sense of security. For the encryption in PGP the Public Key of the receiver is sufficient. And for some more obscurity, you can add the Public Key of your fake sender. Since the mail is encrypted, it seems trustworthy. The big problem here is, that the authenticity cannot be verified. Furthermore, the message contains a checksum of the content, but this also does not verify the integrity.
Next step, of course, is to sign your E-Mails. This needs to unlock your Private Key with your Private Password. Yep, it is recommended that you're protect your Private Key with a Password. Receiving a signed message means, that your message has not been modified during sending and if you have received two messages, that both came from the same source. PGP is built on the assumption of the Web of trust. Trust is one of the biggest security gap used by hackers.
It sounds horrific, but everyone can send you encrypted and signed PGP Mails where you can't reproduce the origin.
To watch how many servers in just one of the steps are involved just use traceroute to check.Windows
tracert google.comLinux/Unix
traceroute google.com
To overcome all those security issues there were many attempts to improve the protocol. But first of all, let's look at how easy it is to fake a mail. Have you ever tried to use the mail command in PHP. You just type in the sender, the recipient, the subject and the text and the mail is sent. Whatever sender you choose. It is even more astonishing if you try out the low-level telnet connection. For some more details go to Wikipedia.
telnet smtp.example.com 25 220 service ready HELO example.com 250 OK MAIL FROM:sender@whatever.net 250 OK RCPT TO:receiver@example.com 250 OK DATA 354 start mail input Subject: test text . 250 OK QUIT 221 closing channelSince telnet is a very low level, text based, insecure protocol some people thought about to use a SSL-tunnel. It worked out quite well for http. Now you can transfer secretly your messages from and to your server. But you have a new application, from OSI layer level 5 perspective, and therefore you need a new port. This creates new problems. With one should I use. How do I know that the receiver is able to use SSL? Wait for a timeout? No way! As the receiver server, with certificates do I accept. Self-signed? Of course, I don't want to lose my clients. For the first problem they found a solution, the second remains. The solution is called STARTTLS and was built in as protocol extension for SMTP and IMAP. It is fully downward compatible since it's only a new option after connecting to the server. Here's an example on what happens if I connect to GMail.com:
220 mx.google.com ESMTP u32-v6si12247199wrf.52 - gsmtp EHLO test.com 250-mx.google.com at your service, [87.163.4.131] 250-SIZE 157286400 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8Also, by using SSL or STARTTLS you're only securing a point-to-point connection. Looking at the illustration in the top, you can see, that your only able to control one of the point-to-point connections. The rest is absolutely secured by chance.
End-to-end encryption
Next step of course would be an end-to-end encryption. Then it's absolutely not relevant how your message is transferred. However, it would be good practice if even your password for authentication against you're mail service is securely transmitted or at least hashed. Speaking of secured E-Mails there are two widely spread solutions for it. The one is PGP, the other is S/MIME. Supposing you're not operating an Exchange Server I only stick at PGP (so far).For confidentiality a standard PGP encryption is quite good. But this often leads to a false sense of security. For the encryption in PGP the Public Key of the receiver is sufficient. And for some more obscurity, you can add the Public Key of your fake sender. Since the mail is encrypted, it seems trustworthy. The big problem here is, that the authenticity cannot be verified. Furthermore, the message contains a checksum of the content, but this also does not verify the integrity.
Next step, of course, is to sign your E-Mails. This needs to unlock your Private Key with your Private Password. Yep, it is recommended that you're protect your Private Key with a Password. Receiving a signed message means, that your message has not been modified during sending and if you have received two messages, that both came from the same source. PGP is built on the assumption of the Web of trust. Trust is one of the biggest security gap used by hackers.
It sounds horrific, but everyone can send you encrypted and signed PGP Mails where you can't reproduce the origin.