4

I have heard security researchers suggest that if you run a public website, you should put up a "security contact" page that includes a contact email address and your PGP public key so that people can contact you if they discover any security vulnerabilities.
One example of this is http://37signals.com/security-response.

1) What is the intended purpose of including your PGP key on this page?

2) How can you be sure that someone didn't compromise the server and put up their own PGP key?

AviD
  • 72,138
  • 22
  • 136
  • 218
Jeremy Smith
  • 41
  • 1
  • 1
    Do you by any chance have a reference to where they are indicating that this would be a good practice? I'm not sure why any details would be needed beyond the whois for the site being up to date. That should let someone noticing a problem get in touch with you just fine. – AJ Henderson Feb 04 '13 at 18:46
  • 1
    @AJHenderson WHOIS info is all well and good, but one might prefer to have cryptographic protection of e-mails containing details of security vulnerabilities on their website. – Iszi Feb 04 '13 at 21:37
  • @Iszi - yea, I get that, but you could also e-mail them, explain that you found a vulnerability and ask how they would like you to send them the information. At that point, they can e-mail their public key back. Hacking the site also won't compromise the whois contact info, where as a hacked site could have the security contact page changed to not reach the actual owner. – AJ Henderson Feb 04 '13 at 21:45
  • @AJHenderson Good point about the hacked site. Presuming the site is not hacked though (or presuming someone reporting an issue will be diligent enough to verify contact details via WHOIS before submitting anything), posting the PGP key there removes a step from the process and means you're two less e-mails away from securely receiving the information you need in order to resolve the security issue. – Iszi Feb 04 '13 at 21:49
  • @Iszi - yeah, it does save a step, but it is also an extra thing to do that potentially fails catastrophically if relied on and doesn't save significant time if it works ideally. It just seems like a solution looking for a problem to me. Not that there is anything wrong with it, it just doesn't offer much advantage for the work involved and does increase risk that someone who doesn't realize that if the server is compromised so is the page. A much better trick would be a key field being added to WHOIS, or perhaps some tie-in to DNSSEC. – AJ Henderson Feb 04 '13 at 22:08

3 Answers3

5

Answering Question 1:

I'm not sure what the connection to Ruby on Rails is, but your PGP Public Key provides your users (presuming they also use PGP) with two things:

  1. A means of verifying e-mails they receive from you, which include your PGP signature.
  2. A means of sending e-mails to you, using PGP encryption.

However, both of the above do not offer much assurance unless the end-users can verify that the PGP Public Key posted on your site is actually yours.

Tangentially related: Does hashing a file from an unsigned website give a false sense of security?

Certainly, the users could use that Public Key for either of the purposes mentioned above. However, without authentication of the key itself, they cannot know for sure that received e-mails are being sent by you or that the e-mails they send aren't being actually decrypted and read by someone else.

Answering Question 2:

This can be done by one or a combination of two means:

  1. Implement SSL on the site that hosts your PGP Public Key.
    • (Not quite valid for your attack scenario - see comments.)
  2. Get your key signed by other PGP users (Note, that's users - plural - more is better.), so that it joins and can be verified with a Web of Trust.
Community
  • 1
Iszi
  • 26,997
  • 18
  • 98
  • 163
  • About the answer to question 2, SSL does nothing to answer this question. If the server itself is compromised, then the files being hosted would be changed and the connection would still be valid over SSL. It prevents a MITM, but the question was about the server being compromised, where as a MITM isn't a server issue, it's a communication issue. – AJ Henderson Feb 04 '13 at 21:47
  • @AJHenderson Sorry, it seems I might have had some misconceptions about SSL. It seems question #2 could actually be made a bit broader, then: "Since SSL only authenticates the *server*, what can be done to assure users that a *web page* is authentic?". – Iszi Feb 05 '13 at 13:55
  • basically nothing, that's why I suggested that WHOIS is a better alternative. It can't be "proven" authentic either, but at least requires control of the domain, which is generally a little more difficult. Certainly the being signed by either a CA (S-Mime cert) or some web of trust (like you mentioned) raises the confidence as long as the person visiting knows that it should be, but if that isn't part of the proposed system, then it doesn't really help since it wouldn't lead a visitor to detect a forged one that lacks the signing. That's why I'm wondering if there might be more... – AJ Henderson Feb 05 '13 at 14:09
  • that the original poster might not have seen as key details in whatever proposal he was reading. As it is currently stated, the proposal doesn't seem to add a whole lot. – AJ Henderson Feb 05 '13 at 14:10
  • @Igor - Oh, just to clarify, you could do something like sign a hash of each of your pages if they are static, and if someone knew to check your CA provided or web of trust based cert, then they could see if the pages were altered, but they would have to know to check it. Since it isn't standard, the attacker could simply remove the hashes and nobody would realize that they should be there. It also wouldn't work for dynamic content since the hash would change and thus the server would need the private key to generate a valid hash, which can't be on the server or the attacker would get it. – AJ Henderson Feb 05 '13 at 14:12
4

The only guess I could make is that they might want a PGP public key so that they can disclose the vulnerability without fear of it being leaked to an attacker. If an attacker has already compromised your site, then having the attacker gain access to their e-mail wouldn't really matter. It still seems like a weird recommendation though as WHOIS info for the domain should already let them know who to contact and chances are that even if it takes a couple days, it isn't going to be a critical issue since it is unlikely that a researcher will stumble across the problem immediately.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
3

A PGP key, by itself, gives you no guarantee whatsoever. You cannot trust a PGP key by virtue of it being published on a Web site, since it could be altered in transit or even directly on the site itself, should that site be hijacked (and that unfortunately happens). What (theoretically) gives guarantees that a PGP is genuine and really owned by the individual whose name is in the key is the Web of Trust.

In practice, you cannot know whether the key is really the sysadmin key, but, at least, PGP protects against passive eavesdropping. Also, the presence of a PGP key shows that the sysadmin, at some level, cares. That's the main purpose of including a PGP key in the "security contact" page: to (try to) exhibit a basic level of competence and savviness. It is a fashion statement.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475