5 ms·

I've used a self-signed cert for years, and eventually I got over being annoyed at browsers for lying to users and telling me that the cert was not to be truste

by klync 16y ago

I've used a self-signed cert for years, and eventually I got over being annoyed at browsers for lying to users and telling me that the cert was not to be trusted. The fact is, as I'm sure most at HN know, that SSL tries to solve two problems - identity and encryption. We definitely need a better way to validate a site's identity. I hope this study provides a kick in the pants toward that end.

robryan 16y ago
It's a tradeoff I guess, at the low end people don't want to provide documents, wait and pay a decent amount to get their identity verified. Maybe it would be best to separate them, you can self sign or equivalent for encryption and the identity system can be separate.
- Retric 16y ago
  There is little point in encrypting traffic if you can't differentiate between a man in the middle and your desired endpoint. EX: Conceder I open encrypted connection to amazone.com which pretends to be amazon.com they open an encrypted connection to amazon.com. Amazone can now pretend to be Amazon and read all my encrypted traffic.
  - Dylan16807 16y ago
    Consider someone sniffing wifi. I'm worried about eavesdropping much more often than man in the middle, and nontrusted SSL could provide that if browsers would stop freaking out and just go without a padlock.
  - klync 16y ago
    Users can differentiate between "amazon.com" and "amazone.com" via the browser's location bar. There's nothing stopping the owner of "amazone.com" from getting an SSL cert signed by a "trusted authority", so SSL does not help in this respect. My opinion is that conflating identity with encryption is a fundamental problem.
    - Retric 16y ago
      Some users can differentiate... assuming they notice. The issue is in the real world building a system to handle both typos and hostel networks requires some form of authentication.
- tbrownaw 16y ago
  You need some amount of identity checking, to tell you that the https://uncesnsored.citadel.org/ https://uncesnsored.citadel.org/ you're talking to today is the same one you were talking to yesterday and last week. SSH handles this by remembering the key used on the first connection; Perspectives goes one better and checks from multiple parts of the network. Tying these online identities to physical-world identities is what can be separate.
arethuza 16y ago
Why do you think browsers were "lying" when they said the certificate wasn't to be trusted? Without any kind of "trusted third party" involved there is no reason at all to trust your self signed certificate.
- klync 16y ago
  Fair question. I just checked what exactly the warning message says in IE, and it's actually a pretty fair warning message. Firefox, on the other hand, has a pretty scary "This connection is untrusted" page with a pretty confusing explanation of the alleged problem. I don't know if this still happens, but I remember a couple years ago, it was impossible to get IE or Firefox to actually save the cert or remember your preference to bypass the warning, so you would get the warning each time you had a new browser session and tried to connect to the server, no matter what. The fact is, my real-life identity was never verified as the owner of the domain by a "trusted" third party. However, the encryption key comes from the same server serving the content, so what, really, is not to be trusted? I.e. the cert applies to "domain.com" and is being used on "domain.com". There is no risk of MITM attack, only that "domain.com" is not what you think it is.
  - JoachimSchipper 16y ago
    Well, anyone can supply a key - the problem is that the client could be talking to anyone.
  - deleted 16y ago
    [deleted]
  - ominous_prime 16y ago
    > There is no risk of MITM attack, only that "domain.com" is not what you think it is. That very well could be a MITM attack
- JoachimSchipper 16y ago
  OTOH, Firefox - and other browsers - make a self-signed or expired SSL certificate look extremely scary, while a totally unencrypted connection is fine. I understand the reason, but it´s still odd...

by klync 16y ago

robryan 16y ago

It's a tradeoff I guess, at the low end people don't want to provide documents, wait and pay a decent amount to get their identity verified. Maybe it would be best to separate them, you can self sign or equivalent for encryption and the identity system can be separate.

Retric 16y ago
There is little point in encrypting traffic if you can't differentiate between a man in the middle and your desired endpoint. EX: Conceder I open encrypted connection to amazone.com which pretends to be amazon.com they open an encrypted connection to amazon.com. Amazone can now pretend to be Amazon and read all my encrypted traffic.
- Dylan16807 16y ago
  Consider someone sniffing wifi. I'm worried about eavesdropping much more often than man in the middle, and nontrusted SSL could provide that if browsers would stop freaking out and just go without a padlock.
- klync 16y ago
  Users can differentiate between "amazon.com" and "amazone.com" via the browser's location bar. There's nothing stopping the owner of "amazone.com" from getting an SSL cert signed by a "trusted authority", so SSL does not help in this respect. My opinion is that conflating identity with encryption is a fundamental problem.
  - Retric 16y ago
    Some users can differentiate... assuming they notice. The issue is in the real world building a system to handle both typos and hostel networks requires some form of authentication.
tbrownaw 16y ago
You need some amount of identity checking, to tell you that the https://uncesnsored.citadel.org/ https://uncesnsored.citadel.org/ you're talking to today is the same one you were talking to yesterday and last week. SSH handles this by remembering the key used on the first connection; Perspectives goes one better and checks from multiple parts of the network. Tying these online identities to physical-world identities is what can be separate.

arethuza 16y ago

Why do you think browsers were "lying" when they said the certificate wasn't to be trusted? Without any kind of "trusted third party" involved there is no reason at all to trust your self signed certificate.

klync 16y ago
Fair question. I just checked what exactly the warning message says in IE, and it's actually a pretty fair warning message. Firefox, on the other hand, has a pretty scary "This connection is untrusted" page with a pretty confusing explanation of the alleged problem. I don't know if this still happens, but I remember a couple years ago, it was impossible to get IE or Firefox to actually save the cert or remember your preference to bypass the warning, so you would get the warning each time you had a new browser session and tried to connect to the server, no matter what. The fact is, my real-life identity was never verified as the owner of the domain by a "trusted" third party. However, the encryption key comes from the same server serving the content, so what, really, is not to be trusted? I.e. the cert applies to "domain.com" and is being used on "domain.com". There is no risk of MITM attack, only that "domain.com" is not what you think it is.
- JoachimSchipper 16y ago
  Well, anyone can supply a key - the problem is that the client could be talking to anyone.
- deleted 16y ago
  [deleted]
- ominous_prime 16y ago
  > There is no risk of MITM attack, only that "domain.com" is not what you think it is. That very well could be a MITM attack
JoachimSchipper 16y ago
OTOH, Firefox - and other browsers - make a self-signed or expired SSL certificate look extremely scary, while a totally unencrypted connection is fine. I understand the reason, but it´s still odd...