(In fact, I would argue that free certificates from Let's Encrypt are more trustworthy since the ACME protocol drastically reduces the surface area for attacks on the verification process. See slides[1].)
[1]: http://www.thedotpost.com/2016/10/matthew-holt-go-with-acme
Regardless, look at the vast majority of technical users relying on SSH without using a CA for secure communications, had browsers done a better job at self-signed certs we could be doing the same on the web.
How many technical users actually check the fingerprint matches the expected one of the server, out-of-band? Almost everyone I know just accepts the unknown fingerprint, so almost nobody knows who the endpoint they're actually connected to is.
In the mid-90's, CA certs were put into Netscape Navigator (IE joined later) in order to facilitate the new wild wacky concept that someone might buy something online. They called it "e-commerce".
Trust was centralized because it was far easier to add the then ~half-dozen CA's rather then somehow vetting every joe that wanted to self-sign their certs. PGP's web-of-trust existed but it was deemed less viable.
Besides, the whole SSL certs thing was a major business premise behind creating Netscape - profits. Without that there might not have been a dot-com and the huge amount of money that followed since then.
I think it would be cool to have a standard URL (/.well-known/certificate or something) that explains why you should trust their self-signed certificate, and have the browser show that as part of the view when you encounter a self-signed cert.
The current PKI system allows you to make an unsolicited encrypted connections to an internet origin over an untrusted connection with strong server authentication.
Self signed can not provide this. We do not want the web to be like SSH.
Also, PGP is a very different security model - in order to effectively use PGP, you need to go disclose your government identity to a handful of other people who are already in the strong set. That's not a great fit for the web.
Now, if you have a CA who gives out certificates to parties who should not have them, and that CA can sign certificates for any domain, how do you know if any connection is a MiTM or benign? Do you actually check the issuer every time you connect to a secure site?
CAs give a false sense of security. We need to move off this model.
How?
CAs give a false sense of security. We need to move off this model.
Maybe, but not by adopting the politician's syllogism. We should only move to a better model. As easy as it may be, it's still slightly harder to get a CA to sign a cert for a domain you don't control than it is to sign them yourself, and that shouldn't be dismissed.
If I go to a bank or business, and as part of setting up a relationship they hand me a pamphlet printed with their Public Key Fingerprint, AND the browser shows me that fingerprint image at first use, ..... then that's pretty reliable verification, isn't it?
Obviously we've never had face-to-face relationships with the likes of Paypal, Stripe, etc, and would still rely on our browser and operating system vendors to validate the chain of authority.
There's IIRC no mechanism for that, but for the single-domain CA key it'd make sense to sign the new one with the old one.
There will be some jurisdictions where MiTM is always and unavoidable. TOFU can't work here.
These things must be universal, and TOFU can never be universal.
[1] https://blog.chromium.org/2016/09/moving-towards-more-secure... [2] https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...
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.