Hacker News Reader

Comment by 45h34jh53k4j | Hacker News Reader

I don't think you can say that self-signed is strictly better than plaintext.

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.

View on HN

Sigh. This nonsense again.

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.

subs TLS then; this isnt about the semantics of names. Server Authenticated TLS provides 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."

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.

The self-signed cert you are seeing could be the one that my MiTM proxy has substituted on your connection!

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.

I do not believe you understand MITM attacks.

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.

I think you're still misunderstanding MiTM attacks. There is no "third party". I'm not communicating with my intended recipient at all: I'm communicating with precisely one person, the phisher. And this can only be "solved" with PKI if we have CA's who don't do the sort of thing outlined in this bug report. But we do.

The MitM is in the middle of something, no? You're "A", the site you intend to connect to is "Z", and the MitM is "M".

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?

What mechanism can you use to verify the authenticity of the other end that can't be spoofed by M

No such mechanism exists, as this bug demonstrates.

Is authenticity provided by third parties really "grafted onto" HTTPS? As far as I can tell, that was part of SSL from day one.

And it shouldn't have been. These are two separate questions.

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.

No, but that's not the case I care about; I care about whether when I go to my bank's Web site I'm actually talking to a server controlled by my bank.

So do you trust that Comodo (or any one of the other 180 or so CAs your browser trusts) will not issue a certificate for your bank to the wrong person, after reading this bug report?

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.

If that happens (and there are a fair number of pieces that had to fall into place for this attack to work) it puts us back to where it would be if we had no CA. So, do I have absolute confidence? No. But I think the risk is significantly reduced.

Right, which is why I said we should treat Comodo certificates as if they were self-signed.

I don't think you really got what I was trying to say if that's your response.

What use is TLS if I can't know that when my browser says I'm talking to example.com, I'm actually talking to example.com? I've got a secure connection... to literally anyone who can mitm me. PKI isn't 100% secure, but it raises the barrier significantly. I, as someone who owns a coffee shop or runs a corporate network, can't just go out and get a cert for google.com.

> Plaintext HTTP gives no illusion that your connection has confidentially, authentication nor integrity.

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.

> This is not true, as this could easily be my MiTM Proxy that is substituting your self signed public key

Yeah, but with the current model it could also be subsituted with a cert for which comodo has fucked up the verification again.

Reply on news.ycombinator.com