I'm skeptical that GPG encryption is really useful for such reports anyway. Any attacker with access to important email addresses that would receive such reports probably already has a higher level of access than whatever is being reported. And in the case of bug reports, I don't think being able to verify the sender is all that important.
The purpose of publishing your [company’s] public key is not only to verify the sender. It gives the sender a way to send an encrypted email that only the recipient can read (as long as they still have the key pair.)
Based on the limited public PGP key infrastructure, OpenSSL would seem to be the better solution for this. You already have the companies public key from the site certificate and it provides the same confidentiality and integrity since only their private key would be able to decrypt the message. Being as certificates have to be renewed frequently and verified people would most likely have up-to-date keys.
Level of effort is roughly a one line openssl command for both encryption and decryption.
* I suppose though one thing I didn't consider is follow up messages or correspondence which using PGP would be easier, if everything is already working in your email client. Although it wouldn't be that difficult to include your public key in the initial message, which could be used for responding.
Is there a bit more you can expand on this? A contact form only serves one-way communication and if its sending an email anyway what is the workflow improvement or additional confidentiality/integrity with regards to the message?
The workflow i'm thinking of would be encrypting text with the public key of the website/company you are reaching out to, including your public key in the message or if you have a website as a researcher you can provide the instructions of using your public key for them to send you a response. You then send them an email and attached your encrypted correspondence.
When they respond back they use whatever public key you provided in your initial message and you can decrypt their response. This doesn't require your email client to support PGP or have a keyring setup just simple openssl command(s) that work right from the terminal.
The original goal post was for the original sender to confidentially send a message to the website owners.
> OpenSSL would seem to be the better solution for this. You already have the companies public key from the site certificate and it provides the same confidentiality and integrity since only their private key would be able to decrypt the message.
So a simple form over HTTPS achieves the security researcher -> company part. I agree that it's not sufficient on its own for a confidential two way communication channel, but it can also be achieved over the same technologies. But maybe implementing a messaging platform for the sole purpose of reporting security issues is overkill and could bring its own attack surface.
Having said that, if the problem is the limited PGP infrastructure then I don't see how an ad-hoc protocol that uses the same certificates as the site's HTTPS cert is going to get more adoption. You might as well just put up a messaging dialog at a dedicated security endpoint that is accessible through the browser and let the researcher reuse the same messaging session in some robust way for an effective two-way secure communication channel (login, client certificate).
Yeah I was having the same thought on the web form and if it brings additional overhead maintenance, testing, etc which to me would be the same as trying to get some form of PGP working across mail clients.
> Having said that, if the problem is the limited PGP infrastructure then I don't see how an ad-hoc protocol that uses the same certificates as the site's HTTPS cert is going to get more adoption.
This is the only part I would disagree with and it could be subjective based on your experience with certificates. Using openssl wouldn't really be ad-hoc as this is what certificates are for. If the researcher and the website owner already have certificates for their websites there isn't any other additional work as both public keys are available in the form of their site certificates. There are also a number of sites that provide instructions on generating self-signed certificates [1][2][3] as well as encrypting messages with public certs [4][5][6].
Oddly enough when looking for the (3) openssl commands for encrypting a message I came across this site which recommended using GPG for messages[4], however they all pre-suppose that you have everything setup for using GPG which usually isn't the case and using openssl, in my opinion, has reduced friction being as it doesn't depend on being integrated into a web or email client application, you can simply attach the generated encrypted message like any other email attachment.
The infrastructure concern is really the existing public key availability, accessibility and maintenance options for keys. If the public service is unreliable or lacking robustness then both software developers and individuals are less likely to use or integrate the implementation. There are only a few places to upload your pgp key to that are reliable, compared to the existing certificate system. On my last looking there were maybe (3) sites that were reliable[7] and MIT had been flaky for a while, leaving only two.
However, to your initial point I can certainly see a web interface being a better overall solution as the people set to receive these notifications may not be familiar with the command line or terminal interfaces let alone openssl commands.
Thanks for your response I enjoyed thinking through this.
I understand that. But I also said that I don't think encrypting the message has much of a benefit. I can't imagine many scenarios where a compromised email address would be less of a threat then reading the messages sent to that account.
A security researcher finds a server-side RCE vulnerability and discloses it to security@bigcorp.net. An attacker breaks into security@bigcorp.net because the password was the IT director's dog's name.
Don't you think being able to read that disclosure would give the attacker a bit more access to bigcorp's systems than if it was encrypted?
You must be joking! Do you store all your SSH keys in your email? Do IT directors in big companies even have shell access to production servers? Even if, that would show in the audit logs, whereas an RCE is less likely to. And what if the bug is client-side??
They wouldn't have to have access or SSH keys. The position is usually at a level where people don't question requests or have a heightened guard with emails. It wouldn't be difficult to pivot to requesting an account made for some project or including an attachment that compromises a device which you have phone home. This is shown a number of times publicly with phishing emails that lead to breaches, gift cards scams and wire fraud.
In your proposed situation having access to the director of IT's email account is similar to physical access on a server. The RCE might be another layer of access but its not game changing to what is already available.
