Great, but if they're treating unvalidated certificates as in any way worse than plaintext (they're strictly better), they are still completely wrong.
Plaintext HTTP gives no illusion that your connection has confidentially, authentication nor integrity.
HTTPS is meant to provide all of these things. With a validated, trusted certificate, you get these things. With a self-signed cert, you have none of these things.
Knowing that I don't have things is better than thinking i have these things and not.
So no, untrusted self-signed can't ever be better.
Note cant reply to reply, but all i can say is
"With a self-signed cert, I know I am talking to exactly one party and that no third party can surveil or monitor that communication. "
(This is not true, as this could easily be my MiTM Proxy that is substituting your self signed public key). Once you introduce 'trusts' you are back to CA land.
HTTPS is meant to provide all of these things.
No. This is absolutely false. HTTPS is a transport protocol (that's the second T) and provides point to point security, only. The fact that we have grafted onto this protocol the notion of authenticity as verified by a warden is an historical accident (and frankly the cause of many problems).
With a self-signed cert, you have none of these things.
With a self-signed cert, I know I am talking to exactly one party and that no third party can surveil or monitor that communication. This is a channel over which the second party and I can then negotiate authenticity, which is a much better way to do it than the two-headed monster we've built for ourselves.
Furthermore, for the vast majority of websites I visit, an assurance from a third party that they are who they say they are is of absolutely no value to me. Take HN: I do not particularly trust ycombinator.com more than I would trust a phisher trying to convince me he is ycombinator.com, so a third party's assurance that this is in fact ycombinator.com doesn't give me any useful information.
Think about it. If you connected to my blog, would it actually give you any useful information if Thawte assured you I am who I say I am? You don't have any reason to trust me more than you would trust someone pretending to be me, because I'm some rando with a blog you got linked to.
I mean, obviously my dream solution where my bank hands me a USB stick with their public key on it when I open an account isn't really feasible, but this bug report makes me wonder what value PKI is really adding.
"With a self-signed cert, I know I am talking to exactly one party and that no third party can surveil or monitor that communication."
You can't state this. The self-signed cert you are seeing could be the one that my MiTM proxy has substituted on your connection! The only thing that saves you is your Trust Store. I feel like you don't quite understand public key substitution and MiTM attacks. This isnt a Phishing problem, its a 'breaking the encryption between client and server' problem.
"Furthermore, for the vast majority of websites I visit, an assurance from a third party that they are who they say they are is of absolutely no value to me. Take HN: I do not particularly trust ycombinator.com more than I would trust a phisher trying to convince me he is ycombinator.com, so a third party's assurance that this is in fact ycombinator.com doesn't give me any useful information."
This is HIGHLY ALARMING! If this is the case then please use my proxy server and do your banking. Im sure its cool, you don't need to check with a third party that i'm not messing with your encrypted connections.
Which makes that MiTM the one and only one party with whom I am communicating. And I know no other party is surveiling or altering this phishing attempt.
Over this secure channel, my phisher and I can negotiate authenticity, which hopefully he will fail.
If this is the case then please use my proxy server and do your banking.
Sigh. My bank is not ycombinator.com. I don't think YC is even a bank. My bank is one of the few sites I mentioned where I do care about their authenticity because I do trust them more than I trust a potential phisher.
You are not simply substituting the origin with a phish, you are reading/modifying traffic by a third party without any possible detection from the server.
There are three parties. You, Me (the mitm) and your bank. (assuming your bank uses self signed, which it doesnt). Ive substituted my self-signed cert with the banks in your TLS handshake. I then reencrypt everything you send me to the bank. Bank can't distinguish you and I.
We solve this with PKI and trusts.
In this scenario, you're communicating with Z, while M listens in. Anything you send down the pipe can be transparently proxied by M and relayed to Z.
What mechanism can you use to verify the authenticity of the other end that can't be spoofed by M, now that they're inserted into the communication path?
No such mechanism exists, as this bug demonstrates.
Without an explicit warning, it's not going to be at all obvious to the average user - or anyone who forgets to check the address bar/isn't enforcing HTTPS - that the connection lacks those properties.
Yeah, but with the current model it could also be subsituted with a cert for which comodo has fucked up the verification again.