3 ms·
>No, that doesn't actually solve this problem because then it just turns into a he-said-she-said. then I fail to understand what you plan to do with the encryp
by snagg 16y ago
>No, that doesn't actually solve this problem because then it just turns into a he-said-she-said.
then I fail to understand what you plan to do with the encrypted stuff that you get from the researcher since the only one able to decrypt it would be the vendor.
At that point the scenario is: researcher says this is vulnerable, vendor denies it, somebody needs to decrypt the content of what the researcher has sent to the vendor.
In contrast what happens without having the encrypted content is:
researcher says this is vulnerable, vendor denies it, the researcher can publish the un-encrypted original advisory on your website if he feels like it.
Regardless the SSL trick is a nice one I just don't see the point of the third-party involved and I somewhat doubt that a website like this can be useful to the end-user or to put pressure on the vendor.
- zedshaw 16y agoLet's try a few of your supposed scenarios: 1. Researcher posts it. 2. Vender pulls it down and looks at it, then says it's harmless or not an issue. 3. Researcher thinks it is, and since the vendor says it's not, the researcher posts a cleartext version for them. 4. If it really is, then the vendor should have paid attention. Next scenario (not sure why you can't think past solving these yourself): 1. Researcher posts bogus spam. 2. Vendor decrypts, sees that it's bogus spam. 3. Vendor posts the decrypted version and flags it as spam. 4. It gets taken down or ignored if it is, and researcher is blocked eventually. Next scenario: 1. Researcher posts a vulnerability. 2. Vendor fixes it but half-asses it. 3. Researcher tells them it's not fixed, they say yes it is. 4. Researcher calls their bluff and posts the original cleartext. 5. If it really is fixed, then no harm done. If it's not, then vender screwed up. Pretty much, in most of the situations you've envisioned, you've assumed that the communication is one-way from researcher->vendor. Is there a reason you assumed that vendors wouldn't be able to post their replies back or decrypt and post the decrypted vuln for others to see?
- snagg 16y agoYou are missing the point: is there anything of the above that can't be done without a third party having access to the encrypted content vs having a simple hash of the email/poc sent to the vendor?