I've been learning about PGP, and I asked myself, "Why?"
For example, if I'm using https://mail.google.com, then what benefit would adding PGP offer that would justify it being used?
I can understand that its possible for an encryption method to become compromised, and it could be seen as a means to avoid disaster if a backdoor to SSL/TLS was released. PGP is also more decentralized, which could be attractive to some.
SSL/TLS protects the email from tampering or eavesdropping as it transits between your computer and Google's server, and possibly during further relays to eventual recipient. And that's all it does.
PGP does far more. If you're sending a signed email, the recipient can verify that the email was sent by you, and that it was not tampered with at any point between when you wrote it and when they received it. If you're sending an encrypted email, you know that nobody but the intended recipient can read it -- not Google, not the NSA, nobody. That's why it's called "End to End Encryption".
However, the email metadata (from, to, subject, timstamps) is still sent in clear, and PGP can't help with that. So in general, it's best to send PGP-encrypted emails via TLS-secured connections.
body) of the e-mail can't be read; there's a whole lot more you can't (easily) hide and which PGP doesn't solve.
There is more at risk in using SSL/TLS than potential 0-days, because there are already known attacks that can circumvent TLS. Moxie Marlinspike has been giving Def Con presentations on it since at least Def Con 17.
One of the most notable tools is sslstrip, created by Marlinspike.
Sslstrip works because TLS operates on a Certificate Authority trust model, which gives potential MITM adversaries an opportunity to forge digital certificates and serve them to an unsuspecting user. The user's browser will tell them the website might be insecure, and most will continue anyway. When properly used, TLS is considered secure, however older versions such as SSLv2 and SSLv3 have been proven to be insecure.
This is problematic because the default behavior of TLS is to fall back on SSLv3 when one end of the connection does not support TLS. With this, an attacker can force a users connection to SSLv3 without them knowing. A patch was released, however does not mitigate the issue, as both ends of the connection must be patched. This means that unless you go out of your way to disable SSLv3 entirely, your encrypted communications are still at risk.
With PGP/GPG, the bar to entry is much higher. You cannot simply fire up your web browser and start typing. In fact, PGP is not used for encrypting traffic at all. It is used to encrypt data while on your computer, which you can then send. It has remained largely unchanged over the years, and is often complained about for being difficult to set up for beginners. With proper usage however, it is a very secure method of encrypting communications. So secure in fact, Ed Snowden has recommended it to evade the NSA.
The biggest difference between TLS and PGP is that with PGP, the data is secure on either end, where in TLS, the data is only secure during transmission.
The key to getting the most out of PGP is to generate a good key, establish your web of trust, keep your private keys secure, and assume if your machine is compromised that your private keys are as well. (Which you would then use a previously generated key revocation certificate to nullify the key)
For more info on getting the most out of PGP/GPG, try checking out a comprehensive resource on it. This is one of many created over the years.
HTTP Strict Transport Security and browsers implementing STS preloaded list deal with sslstrip to some extent. And with certificate pinning, the CA trust model is a little more trustworthy.
Commented
Dec 11, 2014 at 9:15
Just to name three.
HTTPS only protects your email between you and Google. From then on it is transferred unencrypted. That means your email can be read by:
PGP, however, provides end-to-end encryption. Only the receiver can decrypt the email. All intermediates can only relay the encrypted text without being able to read it.
In short, PGP protects the contents of the email, both in-flight and at rest; TLS protects the communication channel while the message is transiting a network.
PGP vouches for a person and an email address; TLS vouches for a server (and optionally a client).
Unluckily, although PGP is awesome in theory, the "real world" benefits of PGP are quite limited, if existent. If PGP was the default that everybody uses, it would rock.
TLS gives you (ignoring the possibility of exploits) a secure connection to your mail server. You have the guarantee that the server you talk to is really your mail server, and that nobody can eavesdrop on your communication with the server. However, there is no end-to-end encryption, nor message authentication.
Which means that although your communication with the server is confidential, your messages are stored in plain text on the server (and forwarded to the NSA anyway, don't be fooled into believing anything different).
Also, the exchange with the recipient's mail server may or may not be secured (you don't know), mail on the receiving (and intermediate) server(s) is stored in plaintext, and the recipient may or may not use a secured connection with his mail server.
Further, despite some extensions that thwart the most trivial spoofs, the protocols used in email exchange are pretty naive and give little to no guarantee about a message's origin. In other words, you do not know with any reasonable certitude whether a message you received originates from who you think it came from at all, or whether someone replaced part of it with something different.
PGP addresses all of this in theory by offering both end-to-end encryption and a means of signing messages. That means you know for sure that the message you received cannot be read by anyone intercepting the message, and the message really originates from who you think it came from and wasn't changed.
The problem is that for this to work, two prerequisites must be met:
The first point already pretty much settles PGP's benefits for the "real world". Hardly anyone uses PGP. Your aunt Sally doesn't, your bank doesn't, your electric supplier doesn't, and XYZ doesn't either. Which means you just aren't getting to use PGP, except with a few geeks.
The second point bears the whole lot of problems that SSL/TLS has, too (as explained e.g. in that Defcon Youtube video in cremefraiche's answer), except the chain of trust in PGP is more of a "hobbyist" thing, if I'm allowed to call it that. This may actually be a good thing, but it may as well be a bad thing. Instead of trusting a company that sells certificates for profit, you let your keys sign by a number of... well... people. People you know well, or maybe don't know too well. Depending on who signed their keys, you trust them a little bit more or less.
Unless you meet the recipient at least once in person to exchange keys, you never have a guarantee that you own the correct key (either way).
PGP will hide what you are telling someone, but it will not hide who you mailed, or that you sent a mail at all (well, it can hardly do that, can it). The mere fact that you communicate with people may however already be important (even more so if you communicate using encryption).
An important consideration is that since the vast majority of people doesn't use end-to-end encryption, you are automatically on the bad guys' (bad guys = government agencies) suspect list if you do. After all, if you use encryption, you have something to hide, so you are most probably a crimial, or worse. No such thing as a presumption of innocence exists, outside fairy tale books (even if your constitution says something different).
So, when you plan your next bomb strike, it is probably a good idea not to coordinate your terror cell's weekly meetings via email and use PGP because the NSA will make you a priority target. That doesn't automatically mean you will get waterboarded, but it means that you will be subject to much more detailled profiling and a much more thorough individual analysis.
Depending on what their profiling shows (depending on where you live, who you talk to, what happens on your bank account, where you travel to, what communication pattern you have, etc.), this may result in anything from "nothing happens" to "guys with masks beat the crap out of you so you reveal your passwords" or "wake up in a black camp".
Luckily, for most people, it's the "nothing happens" flavor, but you never know.
Seven years later, and it seems like a better question would have been "What real-world benefits does sending email with SSL/TLS have?"
This 2015 paper looked at over 650,000 mail servers in Germany, which offered SMTP on one or more of ports 25, 465, or 587. 419K of them offered SMTP on port 25, but only 69% could perform a successful TLS handshake. 256K offered SMTP on 587, with 83% performing a successful handshake. On 465, the figures are 267K, and 90%. Now consider that most emails go through multiple hops, and TLS has to be negotiated on every hop. Clients appear to be unlikely to reject connections if the handshake fails, so the hop falls back to clear, and the remaining hops go through in clear. The paper goes over multiple reasons why TLS might fail, but it doesn't cover attacks per-se, and the most obvious attack is for a MITM to simply drop a STARTTLS, which would be relatively trivial.
So, unless you know that the sender's MTA connects directly to the receiver's MTA, with no intervening hops, and that both support TLS and are correctly configured, and that they haven't been compromised, and that both the sender and receiver are connecting securely to their own MTAs, then SMTPS appears to be completely pointless. In any event, you should never trust it. And, if you really were concerned with security, why would you go to the bother of auditing your SMTPS connection at all, rather than just using a custom protocol?
PGP has none of these issues, with the only downsides appearing to be that the addresses go through in the clear, and it's marginally harder than trivial to set up (Thunderbird, at least, has it built in now). And the NSA knows you're using it, of course.
