-1

I'm currently thinking about writing a Firefox/Chrome and Python/PHP/JS plugin to accomplish the following:

Assuming you are on a non-SSL secured site or you simply don't trust any CA like Let's Encrypt, Comodo, Symantec etc. but you still want to accomplish maximum security for your clients/users. What if you give every user the possibility to enter his public PGP key at his account-settings or sign-up and afterwards encrypting the whole html content you send to the client with his public key? Afterwards on receiving of the pgp-message or "pgp wrapped html message" the Chrome/Firefox plugin will decrypt the received pgp-message and displays it as HTML like a normal website. By this concept you don't need any CA or SSL at all because proper decryption can only be accomplished if the plugin holds your private key file to decrypt the received content.

As far as I understand SSL, only the connection is encrypted but not the actual content. Tell me what you think? Do I miss something here or is that simply a cool idea?

schroeder
  • 125,553
  • 55
  • 289
  • 326
V O
  • 109
  • 5
    What do you mean by "only the connection is encrypted but not the actual content"? The data from the server is encrypted in transit, after being generated in clear text form, just as with your idea. You might want to look up client authentication (https://security.stackexchange.com/questions/187694/how-does-do-client-authentication-work-over-https), which allows a custom certificate on a per-client basis. – Matthew Mar 22 '19 at 10:25
  • 3
    I think your underlying assumptions can be answered by the question [How does SSL/TLS work?](https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work) – schroeder Mar 22 '19 at 10:42
  • @Matthew data from the server *and* client are encrypted. – schroeder Mar 22 '19 at 10:48
  • @schroeder True, but the question didn't mention any data going the other way! – Matthew Mar 22 '19 at 10:49
  • 1
    @Matthew but that's a massive weakness in the proposed scheme – schroeder Mar 22 '19 at 10:50

2 Answers2

9

This is a bad idea.

HTTPS encrypts the whole request & response, and every encrypted message is authenticated by a certificate, which proves that the messages were encrypted by the real sender.

If the website traffic isn't encrypted, then an attacker could intercept the public PGP key the user is trying to configure, and replace it with his one, which will allow him to intercept the rest of the traffic while giving to the user a sentiment of "false security".

This is why we use certificate authorities: both clients & servers are configured to know them and trust them, so they can tell clients which servers are trustful or not.

Benoit Esnard
  • 13,979
  • 7
  • 65
  • 65
  • Public keys are public. That's not the problem. The problem is that the client has no idea if the encrypted content is actually from the legitimate server and not a mitm. – schroeder Mar 22 '19 at 10:50
  • Another weakness to add is that the URL and query parameters are not encrypted – schroeder Mar 22 '19 at 10:51
4

Your scheme is a bad Idea. As others mentioned, not all data is encrypted, there is probably authentication missing, and by designing your own scheme, you will make many mistakes others made in the past and which are fixed in TLS 1.3

Also, how would you secure the upload of the public key? A MitM attacker could just replace the PGP key and you would encrypt all data to the wrong person.

If for some reason you really want to use OpenPGP certificates instead of X.509 certificates, first look at RFC6091. It seems GnuTLS supports this.

But then think again: How will people check that the server key is really the key from the correct trusted server? And how does your answer to this question differ from using self signed certificates and checking the hash?

Unless you have a good answer to that question, your whole proposal lacks base!

Community
  • 1
Josef
  • 5,933
  • 26
  • 34