9 ms·
Actually, both Chromium [1] and Firefox [2] are working on showing plain HTTP as insecure. [1] https://blog.chromium.org/2016/09/moving-towards-more-secure-web
by zetafunction 10y ago
Actually, both Chromium [1] and Firefox [2] are working on showing plain HTTP as insecure.
[1] https://blog.chromium.org/2016/09/moving-towards-more-secure-web.html https://blog.chromium.org/2016/09/moving-towards-more-secure...
[2] https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/ https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...
- bandrami 10y agoGreat, but if they're treating unvalidated certificates as in any way worse than plaintext (they're strictly better), they are still completely wrong.
- 45h34jh53k4j 10y agoI 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.
- bandrami 10y agoSigh. 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.
- 45h34jh53k4j 10y agosubs 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.
- Aaron1011 10y ago> 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.
- pacey 10y ago> 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.
- rnhmjoj 10y agoThat's good but it should require a confirmation like it's done for self-signed certs, at least when submitting a form.