Comment by Joeri
11 years ago
Self-signed certificates are still better than http plain text. I understand not showing the padlock icon for self-signed certificates, I don't understand why you would warn people away from them when the worst case is that they are just as unsafe as when they use plain http. IMHO this browser behavior is completely nonsensical.
How would a browser know that the the self-signed certificate that was just presented for www.mybank.com is intended to be self-signed (show no error, but also show no padlock) or whether it's the result of a MITM attack because www.mybank.com is supposed to present a properly signed certificate (show error)?
How would you inform people going to www.mybank.com which is presenting a self-signed cert in a way that a) they clearly notice but that b) doesn't annoy you when you connect to www.myblog.com which also is presenting a self-signed cert?
If the user typed www.mybank.com, let the server redirect to https but don't show the lock icon if it's self-signed. This is no worse than an impostor that just doesn't redirect to https.
If the user typed https://www.mybank.com, show the usual warning for self-signed certificates.
How many people are careful to type "https" every time they visit a website? How many people pay close attention to the lock icon/color of the URL bar? This advice seems to ignore the existence of sslstrip [0] and related attacks, and the numerous countermeasures that have been designed to deal with this problem (e.g. HSTS).
[0] http://www.thoughtcrime.org/software/sslstrip/
This is EXACTLY what I want for my intranet sites. It lets me protect my users from the wireshark in the next cubicle.
2 replies →
How would a browser know that the fact that www.mybank.com doesn't use SSL at all is intended by the bank, or the result of a MITM attack? At the end of the day it all relies on the user seeing the (lack of) a padlock in his browser. So as long as you don't show a padlock (or a different kind of padlock) for www.mybank.com when the certificate is self signed, you're good.
You would have to simply install the certificate for the CA that signed the certificate. Self-signed just means that YOU are the CA.
No. Self-signed certificates are much worse because they bring a false sense of security.
A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate. At the moment CAs are the best known way to do that (and before anyone brings certificate pinning or WoT, they come with their own problems, please read this comment of mine https://news.ycombinator.com/item?id=8616766).
EDIT: You can downvote all you want but I'm still right.
Each time anyone repeats the "self-signed certificates are still better than HTTP plain text" lie is hurting everyone in the long run.
They're much worse, both for the users and from a security perspective. Self-signed certificates are evil unless you know exactly what you're doing and are in full control of both ends of the communication (in which case just trust it yourself and ignore the warnings).
The extent to which this is true depends on browser behavior. With some browser behavior self-signed certs could make some users safer against some threats; with other browser behavior they could make some users more vulnerable to some threats.
An opportunistic privacy solution with no legacy installed base to worry about is tcpcrypt:
http://www.tcpcrypt.org/
So if anyone wants to make progress on opportunistic unauthenticated encryption without having to fight about UA behaviors, tcpcrypt may be more fertile ground than self-signed certificates.
> With some browser behavior self-signed certs could make some users safer against some threats
How exactly? Did you read my linked comment?
As far as I can tell, self-signed certs are always a no-no. As soon as one is compromised and has to be revoked the whole system breaks apart.
The only situation where a self-signed certificate makes sense is when you control both ends of the communication and can revoke the cert on the client yourself.
In the age of WiFi, you can't dismiss active attacks.
EDIT: Again, whoever is downvoting can downvote all he wants but I'm still right. If I am not, prove it via comments, not downvotes, and we'll be able to discuss each other's views.
Even parent's Tcpcrypt link says it is vulnerable.
> By default Tcpcrypt is vulnerable to active attacks
> Tcpcrypt, however, is powerful enough to stop active attacks, too, if the application using it performs authentication.
How are you going to perform authentication via insecure channels without CAs?
3 replies →
> A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate.
Trivial? Yes. As trivial as intercepting plain HTTP? No.
The NSA or adversary du jour can vacuum up anything sent over plain HTTP with zero risk. Self-signed HTTPS forces the attacker to commit some resources and, more importantly, run the risk of exposure. Security is not a binary (no encryption scheme is perfect), it's about increasing the cost to attackers.
https://news.ycombinator.com/item?id=8625420
1 reply →
Reddit discussion about this, with much of the same arguments there as here (and talking past each other just as much):
http://www.reddit.com/r/ProgrammerHumor/comments/2l7ufn/alwa...
The warning is designed to let people know that who you're talking to can't be proven, which is important when someone tries to impersonate a bank, or your email provider, or any other number of important sites.
CA-signed certificates don't prove you're talking to who you think you are either as any CA trusted by your browser/OS can sign any certificate.
Yes. That's not perfect. But it raises the bar for forgery to "can sign certificates as a root authority", which is still fairly high. (e.g. I can't do it, and neither can you.) It stops coffee shop/hotel wifi operators and mobile providers from injecting content into your session.
If we encourage users to blindly accept self-signed certificates (giving us end-to-end encryption but sacrificing identification), nothing would stop those actors from altering your HTTPS sessions as easily as they alter your HTTP sessions today. It's throwing the baby out with the bathwater.
1 reply →
This is true for most sites now, but is being solved gradually, with hard-coded certificate pinning already shipping in Firefox and Chrome, and the HTTP Public Key Pinning extension coming soon.
But when you browse over http, you don't know who you're talking to either, so how are self-signed certificates worse than http?
I'm really having trouble figuring out the attack scenario unique to self-signed certificates that you don't have with plain http.
Security-wise, if they are both vulnerable to trivial exploits, how can you say one is "more secure" than another?
Because encryption with SSL without trust of the SSL cert is meaningless. It might as well be not encrypted.
I wonder if this is true.
If there's a man in the middle, then they can read the traffic. But others still have a problem.
With HTTP, you know that everyone can read the traffic.
I think unsigned certs, especially with pinning, can be used to make wholesale collection of internet traffic vastly more difficult.
Now you are talking about obscurity, not security. In my opinion.