3 ms·

Certificates are broken anyhow, we might as well do away with them all together. How am I ever able to research, verify and in the end trust all the hundreds of

Certificates are broken anyhow, we might as well do away with them all together. How am I ever able to research, verify and in the end trust all the hundreds of certificate providers out there? Answer: I don't, nobody does, and that's why it will never work. What's wrong with SSH's encryption, btw? Can't we put that in a browser?

pitkali 4y ago
The point of certificates is not to encrypt the traffic, but rather to verify that the server you are talking to is who they claim they are. The server showing you their certificate is like you logging into an SSH session, which I've been doing for a long time with a certificate as well, actually.
- BurnGpuBurn 4y ago
  In my browser it is either/or though. I can have encryption and verification, or none of those. Technically it would be feasable to have encryption without verification, and thus without CA's. Why isn't that an option?
  - Avamander 4y ago
    Because encryption without verification is practically useless.
    - SAI_Peregrinus 4y ago
      More specifically, because encryption without verification allows for MITM and other chosen-ciphertext attacks which trivially break the confidentiality provided by the encryption. Encryption needs entity authentication (verifying who you're talking to), data authentication (verifying that the ciphertext has been created by one of the parties in the communication), and a cipher to provide confidentiality in practice.
  - mort96 4y ago
    You can do what you want by creating your own self-signed certificates. It's not that hard, just a couple of openssl commands. Browsers will throw up a big scary warning that the certificate can't be verified (as you'd expect), but most browsers let you click through that warning, and you get encrypted but unverified traffic.
  - benlivengood 4y ago
    You can set up your clients and servers to prefer and/or allow the NULL cipher.
TazeTSchnitzel 4y ago
SSH's encryption isn't much different from TLS. The big difference is in how the authentication works. The way most people use SSH, essentially all certificates are self-signed, and the only way it knows which servers to trust is by storing a list of certificates it's seen before, so you're just hoping that you don't get MITM'd the first time you connect. It's not scalable to a web browser where you're connecting to thousands of hosts you've never seen before.
- BurnGpuBurn 4y ago
  I personally don't visit thousands of hosts I've never seen before on a reasonably short timescale. I do visit some hosts/websites very often. Wouldn't SSH be ideal for those? See it like this: I connect to yc for the first time, hope I don't get MITM'd or have some web-thingy to verify manually, and after that, voila, forever good encryption and verification. This way I don't have to trust some random CA from a long list of CA's I know nothing about. And even for every new site you visit, sure, you must hope you don't get MITM'd. Is that worse than hoping the random CA the site uses isn't compromised and a hacker uses that to MITM you? How does it compare to risk of the site being hacked already? My point is, alternatives exist, good ones, but website security feels like a business that's captured by a bunch of CA's and browser manufacturers that don't want change for selfish reasons.
  - sgjohnson 4y ago
    Why aren’t we using SSH for everything? https://medium.com/@shazow/ssh-how-does-it-even-9e43586e4ffc https://medium.com/@shazow/ssh-how-does-it-even-9e43586e4ffc
  - mort96 4y ago
    What you're proposing doesn't sound that different from public key pinning (HPKP), where the web server tells the browser to distrust anyone any other certificates than the pinned one (or certificates from any other CAs). HPKP is deprecated now though.

pitkali 4y ago

The point of certificates is not to encrypt the traffic, but rather to verify that the server you are talking to is who they claim they are. The server showing you their certificate is like you logging into an SSH session, which I've been doing for a long time with a certificate as well, actually.

BurnGpuBurn 4y ago
In my browser it is either/or though. I can have encryption and verification, or none of those. Technically it would be feasable to have encryption without verification, and thus without CA's. Why isn't that an option?
- Avamander 4y ago
  Because encryption without verification is practically useless.
  - SAI_Peregrinus 4y ago
    More specifically, because encryption without verification allows for MITM and other chosen-ciphertext attacks which trivially break the confidentiality provided by the encryption. Encryption needs entity authentication (verifying who you're talking to), data authentication (verifying that the ciphertext has been created by one of the parties in the communication), and a cipher to provide confidentiality in practice.
- mort96 4y ago
  You can do what you want by creating your own self-signed certificates. It's not that hard, just a couple of openssl commands. Browsers will throw up a big scary warning that the certificate can't be verified (as you'd expect), but most browsers let you click through that warning, and you get encrypted but unverified traffic.
- benlivengood 4y ago
  You can set up your clients and servers to prefer and/or allow the NULL cipher.

TazeTSchnitzel 4y ago

SSH's encryption isn't much different from TLS. The big difference is in how the authentication works. The way most people use SSH, essentially all certificates are self-signed, and the only way it knows which servers to trust is by storing a list of certificates it's seen before, so you're just hoping that you don't get MITM'd the first time you connect. It's not scalable to a web browser where you're connecting to thousands of hosts you've never seen before.

BurnGpuBurn 4y ago
I personally don't visit thousands of hosts I've never seen before on a reasonably short timescale. I do visit some hosts/websites very often. Wouldn't SSH be ideal for those? See it like this: I connect to yc for the first time, hope I don't get MITM'd or have some web-thingy to verify manually, and after that, voila, forever good encryption and verification. This way I don't have to trust some random CA from a long list of CA's I know nothing about. And even for every new site you visit, sure, you must hope you don't get MITM'd. Is that worse than hoping the random CA the site uses isn't compromised and a hacker uses that to MITM you? How does it compare to risk of the site being hacked already? My point is, alternatives exist, good ones, but website security feels like a business that's captured by a bunch of CA's and browser manufacturers that don't want change for selfish reasons.
- sgjohnson 4y ago
  Why aren’t we using SSH for everything? https://medium.com/@shazow/ssh-how-does-it-even-9e43586e4ffc https://medium.com/@shazow/ssh-how-does-it-even-9e43586e4ffc
- mort96 4y ago
  What you're proposing doesn't sound that different from public key pinning (HPKP), where the web server tells the browser to distrust anyone any other certificates than the pinned one (or certificates from any other CAs). HPKP is deprecated now though.