4 ms·

One reason that comes to mind immediately: self-signed certificates offer no protection against MITM attacks. It's worse than without a cert, since it gives a

One reason that comes to mind immediately: self-signed certificates offer no protection against MITM attacks. It's worse than without a cert, since it gives a false sense of security.

dm33tri 7y ago
You can't assume protection, whereas with http you assume no protection. So, if you can't trust certificate (not when it is invalid), just show same level of protection as http.
- zozbot234 7y ago
  The problem is that a http: protocol specifier implies no protection; the moment you follow the link, you know that the connection is not secured. Whereas a self-signed https: connection could be due to someone MITM'ing a site that generally uses CA's, in which case "no warning message" implies that the site is secured. The browser message has to make it clear to the user that something possibly unexpected is going on.
deleted 7y ago
[deleted]
JackRabbitSlim 7y ago
Which CAs have never been subject to a National Security letter? Can't say cuz you can't know? Lets talk about that false sense of security indeed.
- arminiusreturns 7y ago
  Yep, for years when everyone was talking about NSL's and other corporate strong-arming by the gov, I started saying I suspect most major CA's are compromised. At least you know your threat model though, because only the nation states are going to have that. CA's and DNS are two parts of the internet that have become way too centralized in my opinion.
- daxelrod 7y ago
  This is one of the threats addressed by https://www.certificate-transparency.org/ https://www.certificate-transparency.org/ . If a CA issues a rogue cert and _does_ add it to the CT log, it's discoverable, at least in retrospect. If a CA issues a rogue cert and _doesn't_ add it to the log, some browsers will refuse the connection when presented with that cert. https://www.agwa.name/blog/post/how_will_certificate_transparency_logs_be_audited_in_practice https://www.agwa.name/blog/post/how_will_certificate_transpa... has more details about Chrome's implementation.

One reason that comes to mind immediately: self-signed certificates offer no protection against MITM attacks. It's worse than without a cert, since it gives a false sense of security.

dm33tri 7y ago

You can't assume protection, whereas with http you assume no protection. So, if you can't trust certificate (not when it is invalid), just show same level of protection as http.

zozbot234 7y ago
The problem is that a http: protocol specifier implies no protection; the moment you follow the link, you know that the connection is not secured. Whereas a self-signed https: connection could be due to someone MITM'ing a site that generally uses CA's, in which case "no warning message" implies that the site is secured. The browser message has to make it clear to the user that something possibly unexpected is going on.

deleted 7y ago

[deleted]

JackRabbitSlim 7y ago

Which CAs have never been subject to a National Security letter? Can't say cuz you can't know? Lets talk about that false sense of security indeed.

arminiusreturns 7y ago
Yep, for years when everyone was talking about NSL's and other corporate strong-arming by the gov, I started saying I suspect most major CA's are compromised. At least you know your threat model though, because only the nation states are going to have that. CA's and DNS are two parts of the internet that have become way too centralized in my opinion.
daxelrod 7y ago
This is one of the threats addressed by https://www.certificate-transparency.org/ https://www.certificate-transparency.org/ . If a CA issues a rogue cert and _does_ add it to the CT log, it's discoverable, at least in retrospect. If a CA issues a rogue cert and _doesn't_ add it to the log, some browsers will refuse the connection when presented with that cert. https://www.agwa.name/blog/post/how_will_certificate_transparency_logs_be_audited_in_practice https://www.agwa.name/blog/post/how_will_certificate_transpa... has more details about Chrome's implementation.