search

tasn / webext-signed-pages

A browser extension to verify the authenticity (PGP signature) of web pages
BSD 3-Clause "New" or "Revised" License
190 stars 12 forks source link

How is PGP better than EV SSL? #4

Closed Madis0 closed 6 years ago

Madis0 commented 6 years ago

I'd like to know, why should any site owner bother with creating a PGP key for a site when there is already a widely known and used alternative - Extended Verification SSL certificates.

The only pros for this I see are:

but I don't think these reasons are good enough for most sites to care. I believe it could be a good fit to .onion sites though.

tasn commented 6 years ago

Hey @Madis0,

Thanks for reaching out.

EV certs are great for increasing user trust when users visit a website for the first time. Using EV they can be certain (close to certain?) that the server they are talking to is indeed an agent of the company they were looking for. Or as an example: be certain that mozilla.org is indeed the website for "Mozilla Corporation (US)". Other than that, they serve the same purpose as normal SSL certificates. For example, Google and Amazon don't have EV certs, but that doesn't make them less secure.

So assuming that other than identity verification DV and EV SSL certs are the same, we can now reduce the problem to why PGP is better than SSL. The main reason is where point of failure is located. With SSL, if your server is hacked, it's game over. The hacker most likely has access to your private key, or at the very least, the hacker can modify the HTML/JavaScript that the server is serving users. This means, that if the server is hacked, the hacker can serve JavaScript malware at best, or if the website in question is a highly-sensitive web app that does client-side (end-to-end) encryption, can steal your encryption password making end-to-end encryption almost pointless. With PGP however, the key is not on the server, but on a secure and air-gapped computer, a secure hardware token or at the very least on a computer that is sitting behind a firewall. Which means that even if the server is hacked, you can be certain that the content came from the developers. Think of it as giving almost the same level of assurances of when installing packages from a package manager on Linux or when downloading signed packages.

To be honest, I haven't considered it for onion sites in particular, but it's an angle worth mentioning. Worth mentioning though is that it doesn't replace ssl, because it doesn't do any encryption, only signatures, which means your content will be in clear text. This extension, however, could be extended to support verifying signatures on, for example, previously untrusted (self-signed) SSL certs for such sites.

I hope this clarifies things. I'm closing this ticket because I think I answered your question. If I haven't, please let me know and reopen it.

P.S: You can read more info on the announcement blog post.

Madis0 commented 6 years ago

The main reason is where point of failure is located. With SSL, if your server is hacked, it's game over. The hacker most likely has access to your private key, or at the very least, the hacker can modify the HTML/JavaScript that the server is serving users.

Maybe I'm misunderstanding this a bit, but isn't SSL key stored on the authority that gives the certificate?

Either way, with PGP I consider expectancy also a problem. With SSL it's easy - if the site uses https protocol, it must also have a valid SSL certificate. With PGP, users don't really know to expect it if the site doesn't point it out and it can also be used on interceptable http, which defeats it's point.

tasn commented 6 years ago

Maybe I'm misunderstanding this a bit, but isn't SSL key stored on the authority that gives the certificate?

No. SSL works roughly like this: you generate a private and public key pair. You then, using this key pair, create a certificate that matches your website. The certificates has the domain (e.g. stosb.com) and the public key used for this domain among other things. This certificate is then sent to the CA for signing. The CA signs this certificate (with their private key, maybe this is where the confusion stems from?) and sends it back for you to put on the server. The certificate is not secret and is served to clients on every connection. Clients verify the signature on the certificate to make sure it's from a CA they trust. The clients then encrypt with the public key in the cert, and only the server can read them, because only the server has the corresponding private key to the public one used in the cert. So no, the private key is only available at the server, and never to the CA.

Either way, with PGP I consider expectancy also a problem. With SSL it's easy - if the site uses https protocol, it must also have a valid SSL certificate. With PGP, users don't really know to expect it if the site doesn't point it out and it can also be used on interceptable http, which defeats it's point.

It's not very different to guessing that a site uses https when you access it through. It's only very recently that people started expecting all websites to have https. Look at issue #3 btw, I plan on improving this extension to alert users that they are using a website that supports PGP and that they should probably add the setting. Additionally, the site can have banners (like https://client.etesync.com does) to advertise the PGP usage. I don't see it as a problem, especially since it's a something we already lived through with http.

Using a website through http does not defeat the point of this extension. This extension will still verify the integrity of the content, so even if you have an active mitm (or as I said, a hacked server) it's great and verifies the content of the web app making sure everything is secure. Just to give you a more concrete example: while it's better to use SSL, using 0bin with this extension, even without SSL is absolutely fine and poses no risk to your data.

Madis0 commented 6 years ago

This extension will still verify the integrity of the content, so even if you have an active mitm (or as I said, a hacked server) it's great and verifies the content of the web app making sure everything is secure.

Let's assume the website is using http and has its contents modified during traffic, but the written key is the same. How does one verify the integrity of the page?

tasn commented 6 years ago

The same way it protects against a hacked server, verifying the signature. The key is not sent with each page, but rather a signature of the page. The user already has the key from before which was acquired from a trusted source such as offline, cross-referenced among a few places, PGP key server or whatever.

Please read more about public key crypto on Wikipedia and potentially also about PGP to familiarise yourself with the concepts used by this extension.