4 ms·
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
by 45h34jh53k4j 10y ago
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.
- bandrami 10y agoThe 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.
- 45h34jh53k4j 10y agoI 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.
- bandrami 10y agoI 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.
- function_seven 10y agoThe 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?
- bandrami 10y agoWhat 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.
- deleted 10y ago[deleted]