4 ms·
To which browsers will warn the user that the certificate is invalid. Something that, if it was an HTTP site, the user would never be made aware of. The user wo
by Nadya 8y ago
To which browsers will warn the user that the certificate is invalid. Something that, if it was an HTTP site, the user would never be made aware of. The user would then need to ignore the certificate warnings at which point you've done your job by having HTTPS - the rest is up to the user to not ignore security warnings, you can't control that part. Having to generate false certificates at scale for an attack on a number of websites is unlikely - even with the Comodo/DigiNotar blunders of the past. Especially when arguments against these attacks are "nobody would attack me anyway" (you're only making it easier for them to target your visitors by not requiring them to jump through a hoop to get a fake cert).
If they send your user to https://dvfjsdhgfv.com https://dvfjsdhgfv.com (malicious server) instead of https://dvfjsdhgfv.com https://dvfjsdhgfv.com (your server) the browser will yell at them about the site being insecure. If they try to use http://dvfjsdhgfv.com http://dvfjsdhgfv.com your user can see that it isn't secure. They would need a fake certificate for dvfjsdhgfv.com to serve with their malicious version of the site. Arguing against the increased security theoretical attacks exist is a bit misguided - especially when certificates have been revoked or CA's been blacklisted/go out of business for this behavior. It's extremely uncommon - there have only been a handful of instances of it occurring/being caught (an important distinction I'm sure you'd bring up). Because of the difficulty in getting an invalid cert signed by a CA they tend to only go after the big fish (Google/Alibaba/Facebook) and hope they don't get caught quickly.
If fake certificates were as common as having an unlocked bike left in central L.A stolen, the argument would be a lot stronger.
>It encrypts traffic between the two endpoints, that's it.
Which is why it is important. The attack is called "man in the middle" and not "man at the ends". Also "mass propaganda"? Propaganda from who exactly?
I don't understand the refusal to implement https, even on static sites. It takes literally minutes and provides additional security to your readers/users. Refusal to do so is laziness at best and maliciousness at worst. I have a personal file host that receives <5 unique views/day, mostly only by friends, and 99% of all traffic only comes from me - I still took the time to set up TLS [1]. It took me under 10 minutes to implement and it was my first time ever doing so. If you expect to have 0 visitors ever why not just use localhost?
[0] http://techgenix.com/understanding-man-in-the-middle-attacks-arp-part2/ http://techgenix.com/understanding-man-in-the-middle-attacks...
[1] https://kimiwo.aishitei.ru https://kimiwo.aishitei.ru
- dvfjsdhgfv 8y ago> To which browsers will warn the user that the certificate is invalid. Only if the attacker is very, very stupid. They will happily redirect the request to paypal.com to https://www.paypаl.com https://www.xn--paypl-7ve.com (which resolves to https://www.xn--paypl-7ve.com https://www.xn--paypl-7ve.com that Let's Encrypt will happily give you a certificate for). The latter looks exactly like paypal.com and has a green padlock - so for an unsuspecting user it's "secure". Only having implemented DoH correctly you could talk about benefits you mentioned, without it it only gives the user a false sense of security. Seriously, people need to be aware of that. EDIT: HN formats the IRIs so that the above makes little sense, see https://people.csail.mit.edu/ayf/IRI/index.htm https://people.csail.mit.edu/ayf/IRI/index.htm for more examples.
- deleted 8y ago[deleted]
- Whitestrake 8y ago> They will happily redirect the request Doesn't HSTS thwart this? Unless paypal.com were omitted from the preload list, AND you had never browsed to paypal.com before with that browser, it should refuse to connect over HTTP and the attacker won't be able to issue their redirect. It will try HTTPS instead and immediately fail out of certificate validation.
- Nadya 8y agoThat wasn't quite what they were talking about. They were talking about IDN Phishing [0] and not http-->https redirection (which is what HSTS is directed towards). But since we're talking about DNS redirection the http:// http:// handshake against the legitimate server never happens, you're only ever visiting a malicious website (which the certificate checks would all fail - except visually in the case of IDN phishing which only works against Firefox users). [0] https://www.xudongz.com/blog/2017/idn-phishing/ https://www.xudongz.com/blog/2017/idn-phishing/ [1] https://www.аррӏе.com/ https://www.xn--80ak6aa92e.com/ (this will show the punycode domain on HN, visit it in Firefox it will look just like https://apple.com https://apple.com ) [2] The cert still shows punycode though most users wouldn't check the cert: https://kimiwo.aishitei.ru/i/MMFWtvE5ZgYdHWki.png https://kimiwo.aishitei.ru/i/MMFWtvE5ZgYdHWki.png