Hacker News Reader

Comment by avar | Hacker News Reader

Oh man:

    > I am bemused by an approach to accepting
    > security reports which is to go through the
    > motions of having PGP public keys available
    > for people to use to report issues but upon
    > receiving such a request ask for it to be
    > submitted without PGP because digging out
    > the keys is too much of a hassle.

View on HN

I was the one who replied with that, asking him to resend without PGP, for two reasons:

1) both of our MTAs do STARTTLS. And gmail is only TLS.

2) 99% of the PGP-encrypted emails we get to security@golang.org are bogus security reports. Whereas "cleartext" security reports are only about 5-10% bogus. Getting a PGP-encrypted email to security@golang.org has basically become a reliable signal that the report is going to be bogus, so I stopped caring about spending the 5 minutes decrypting the damn thing (logging in to the key server to get the key, remembering how to use gpg). But I recognized him as a knowledgeable person from the Internet, and I knew (1), so I just asked him to send without PGP to save me 5 minutes.

Even if I'd used PGP, I would've just replied cleartext anyway to our security@golang.org list, except all the MIME would've been garbled and unreadable.

In summary, the PGP tooling sucks (especially in gmail, but really everywhere) and it's too often used by people who are more interested in using PGP than reporting valid security issues.

Those figures are both good and depressing to know, thanks.

I figured the PGP usability problems were severe enough that I did not call you out by name in the post. This aspect was merely a darkly amusing aside leading into the main point of how the Golang devs handled this so well.

You didn't know the content of the report, so the irony is only clear in retrospect: the whole point of the report was about vulnerability to MitM attack and email MX->MX delivery is highly susceptible to that without some kind of trust anchoring in place, whether DANE or MTA-STS, neither or which is in place for the golang.org domain.

So the fact that TLS is _advertised_ by the gmail servers, which handle golang.org mail, doesn't mean that the advertisement reaches the sending mail-server.

I've since configured my mail-servers to always require verified TLS for outbound mail to the golang.org domain, as a manual override.

I should update our docs to say:

* If you can get remote code execution in a Go program, use PGP. Otherwise do not.

Sent. We'll see if it's approved. https://golang.org/cl/40860

I'm confused about the use of "PGP-signed" vs. "encrypted" here. Why do you need to decrypt PGP-signed emails? I guess they were signed AND encrypted and the problem was the encryption, not the signature. So presumably just PGP-signed cleartext should cause no problem for security reports. Or is that problematic too for some gmail-related reason?

Whoops, I meant encrypted. Fixed.

(Yeah, if it were just signed, that'd be fine.)

> PGP tooling sucks (especially in gmail, but really everywhere)

GPG integration doesn't suck in Mutt.

I used to use Mutt, and I appreciate that some people still love it, but I don't intend to go back to it just for PGP support.

If PGP (or something like it) is going to catch on, it has to do so for everybody's MUAs, not just nerd ones.

You're apparently someone with at least a bit of influence at GOOG, which makes Gmail. If you cared about PGP, maybe you could use a bit of your power.

...or Thunderbird (Enigmail) for people that like GUIs.

Also fine in KMail.

> I recognized him as a knowledgeable person from the Internet, and I knew (1), so I just asked him to send without PGP to save me 5 minutes.

I understand where you're coming from but this bit of logic I don't get. Especially if you recognized him, then clearly it's worth spending the five minutes.

The five minutes you personally save, someone else has to pay them. The person who originally sent you the email now has to read the response, process it, send you another non-encrypted email and/or enter into a meta-debate with you. They end up mentioning it on their blog and now we're all having this meta-meta-chat about it on hacker news, wasting several man-hours on it.

Was it worth it?

Negatively-anticipatory subjective analysis of the effort and difficulty of a task that needs to be done and which the brain has not "task-switched" into actually doing yet. (What's this canonically described as?)

Something we all do, and which I'm personally very guilty of.

In this case it was exacerbated by "99% of PGP-encrypted security reports being bogus" (to paraphrase).

I can clearly see both sides of this coin though (security!), and I'm not at all discounting what you're saying.

It's both ridiculous and horrendous that PGP remains an operational holy grail after how many decades?

I'd say it was worth it. This thread was more fun than using gpg, even if the time savings is a wash.

    > 1) both of our MTAs do STARTTLS. And gmail is only TLS.

What you're implying here, i.e. that the communication is encrypted anyway, isn't how E-Mail works at all.

Even if the GMail MXs are configured to only accept E-Mails over TLS, the user's sensitive E-Mail may, depending on his settings, traverse multiple servers with less secure settings before a connection is ever initiated with the GMail MXs.

If someone's E-Mail is going to be MITM'd it's far more likely to happen between the Internet café he's sitting in and his ISP's badly configured SMTP server than between his ISP's SMTP server and GMail's TLS-using MTA.

GMail using TLS will do nothing to protect against the message being MITM'd, whereas GPG would, because it's end-to-end encryption, unlike TLS settings for individual MTAs in a possibly long chain of mixed or no encryption before a message reaches you.

Do we have any confirmation that Google has mandatory TLS?

IIRC, STARTTLS may not be mandatory and be just purely opportunistic. So relying on STARTTLS only is not a good idea.

https://serverfault.com/questions/523804/is-starttls-more-sa...

Brad knows me slightly better than that and there was a bit more factoring into his decision. As I'm one of the maintainers and security/release people for Exim, a major MTA, I'd hope that the SMTP server on my personal domain is not too badly configured. :-D

STARTTLS is not required to be used (even if the peer advertises it), can be stripped from the advertisement by an MITM (and the relevant RFCs say you shouldn't configure your MTA to require STARTTLS for every peer), and the standards even say that the session should continue even if the certificate verification fails (absent any site-specific configuration).

This is strictly worse than the problem you're writing about (lack of SSH host key verification) because at least with SSH you know the link is going to be encrypted (perhaps only between you and an MITM, but I digress...), but with ESMTP you can't assume even that. For example, it is perfectly acceptable for Google to one day decide not to negotiate TLS with ESMTP MTAs it's delivering mail to. You could check the message Received: headers on all the E-mail you receive to see if it was used, but by that time it's too late.

Advertising that you use pgp and then in practice not using it is kind of daft, but is there actually much benefit to using encryption to initially report vulnerabilities?

Using pgp is good for +30 cryptolluminati cool points. It also reduces your kibitz surface, which is useful for keeping the guardian from writing incorrect hit pieces about how you don't care about security.

Other than that, not really.

If we're talking serious vulnerabilities (e.g. can allow remote code execution) for a project used by a large number of people, then absolutely. It can be weeks between initial report and a fix being pushed depending on the vulnerability, and even longer for people to update. It's a pretty good niche: intercept emails to maintainers for important projects and either sell the vulnerabilities or use them yourself in that small window. It'll net you a pretty steady stream of 0days if you can pull it off and you choose the right target. Encrypting communication makes that strategy a lot more difficult, and more invasive.

It just seems to me that the window is small (and you have to write a weaponised exploit in that time too), and the only people likely to be able to reliably intercept the email are nation-state actors who do bulk email slurping, and they're probably sitting on a pile of zerodays anyway. But that's just gut feeling so it's likely wrong.

I'll admit it's not a likely scenario, it's just good trade craft.

The window isn't as small as you'd think. The hacker would have all the malware written except for the infiltration point. And a skilled team, who is familiar with the software you are targeting, can go from a whitepaper to something actionable in a couple weeks. Less if they don't sleep much. Even better, a lot of these vulnerability reports come with POCs that can be pretty easily adapted to your needs.

As for who could pull this off, you don't necessarily need nation-state resources. In fact, bulk email slurping probably wouldn't help, since STARTTLS is pretty ubiquitous. Since you're focusing on a single target, your best bet is compromising the SMTP server. If that's someone's personal server, that's well within the abilities of a moderately skilled group. If it's managed email (say gmail) it gets much harder, but maybe they get lucky and figure out your password, either from good guessing/brute force or from an account leak.

Of course, a group could get access to those vulnerability reports by hacking the laptop of someone with the keys, but at least using PGP lowers the attack surface.

This is probably a niche use; all the potential RCE vulnerabilities I've found in projects with large numbers of users have involved projects with no formal vulnerability reporting process at all, where just finding a private way of reporting the issue was a pain.

> Mind, we are overdue for some nice convenient tooling to have a PGP-decrypting-and-reencrypt-to-subscribers mailing-list software tool for use for such public contact points.

We use this:

https://github.com/fbb-git/gpg-remailer

Reply on news.ycombinator.com