[deleted]
Google-hosted malvertising leads to fake Keepass site that looks genuine
181–190 of 197 posts
Re: Google-hosted malvertising leads to fake Keepass site that looks genuine
#182Punycode is of questionable use anyway. Granted I'm mostly looking into this from a primary latin alphabet perspective, but for the various non-latin alphabet sites I've browsed over the past decade all of them just stuck to regular ASCII domains. (Heck you see this even with usernames on websites that allowed Unicode to be used; most non-latin alphabet users will still stick to the Latin alphabet for usernames.) The…
> Punycode is of questionable use anyway Lots of people might want to register their name, or the name of their city, etc. These all sound like valid use cases. You could say that anything beyond ascii is of questionable use, but non-English natives will always digress.
Humans survived with [0-9] as the main identifier for their phone line for 100 years. ASCII is actually a great improvement in that regards. Unicode just introduces too much ambiguity to be used in security critical context as in a hostname.
Re: Google-hosted malvertising leads to fake Keepass site that looks genuine
#183See: https://keepass.info/integrity.html (you may want to manually type it into the address bar...) and download their PGP keys. That way you can verify KeePass downloads using their signatures, which you can save and sign with your own key to really verify the paranoid way. If you ever land on a bad download site, you'll know something's up after you verify and it doesn't match.
Also, on Windows, both the installer and the main executable are digitally signed with a valid code signing cert: 'Open Source Developer, Dominik Reichl'
Re: Google-hosted malvertising leads to fake Keepass site that looks genuine
#184Earlier quoted context omitted.
The first "punycode attacks" were using letters that were completely indistinguishable from the "real" ones (e.g. by using Cyrillic letters). I guess the assumption is that the user would be able to identify any letters with diacritics (even if they're indistinguishable from specks of dust on your screen) and avoid them - after all, you wouldn't go to "göogle.com" either?
As a german I wouldn't go to göogle.com. If my native language didn't include ö? Then that might be a speck of dust to me as well. A safer approach would be to only ever show a user the characters they expect to see (and are familiar with), e.g. based on their language setting. Assuming that every language has a finite list of characters used in its written form such a whitelist approach should be possible and much b…
> Assuming that every language
Oof.
Take for example, both 糉 and 糭 are valid characters in Chinese. One is a variant of the other. Which one is "canonical" depends on who (i.e. which authority, of which there are many) you ask. And FWIW the language and regional settings don't necessarily give an answer to the canonical representation.
Those characters mean the same thing with or without the specks of dust.
So, what's your solution here?
To be fair, Unicode domains are inherently a huge mess. The thing is that we don't need more armchair experts dreaming up Euro-centric solutions.
Re: Google-hosted malvertising leads to fake Keepass site that looks genuine
#185Earlier quoted context omitted.
That would cost Google and Facebook revenue. They are not going to do it unless a government makes them do it, or if the legal liability risk is too great.
This is why punitive damages were invented: companies who didn't want to do the right thing because of money would be made to pay even more than if they had done the right thing in the first place.
[flagged]
Re: Google-hosted malvertising leads to fake Keepass site that looks genuine
#186Earlier quoted context omitted.
As a german I wouldn't go to göogle.com. If my native language didn't include ö? Then that might be a speck of dust to me as well. A safer approach would be to only ever show a user the characters they expect to see (and are familiar with), e.g. based on their language setting. Assuming that every language has a finite list of characters used in its written form such a whitelist approach should be possible and much b…
> Assuming that every language Oof. Take for example, both 糉 and 糭 are valid characters in Chinese. One is a variant of the other. Which one is "canonical" depends on who (i.e. which authority, of which there are many) you ask. And FWIW the language and regional settings don't necessarily give an answer to the canonical representation. Those characters mean the same thing with or without the specks of dust. So, what'…
It still sounds like an improvement: while they might still fall for malicious URLs in their own language, they would not for other scripts.
But as someone said, tiny, valid differences are easy to miss anyway, and original URL attacks were replacing similar-looking ASCII graphemes (eg. l for 1), so this will all continue.
Re: Google-hosted malvertising leads to fake Keepass site that looks genuine
#187Earlier quoted context omitted.
I fully support national languages, ASCII is not suitable for a huge part of mankind. But it's obvious that Unicode as it is is not suitable for security critical applications. Myself, speaking several European languages, I need less than 10 Unicode characters (each of them actually still 8 bit ISO 8859-15 codes). Well, need and need, most of the sites don't even register a punycode domain, but some uglified ASCII ve…
> As a practical step browsers should ask the user whether... No, humans are far too well-trained in "just say yes and forget it". The browser should loudly flag any non-ASCII name (maybe there's a buried-deep option somewhere, to less-loudly flag it), or else it should do a bit of OCR and pop up a "DANGER - Look-Alike Domain Name..." warning.
This case is a clear case of "letter k with a cedilla below": this is encoded in Unicode as a composed character that can be decomposed.
No OCR needed.
For all of these accented cases where no mixing of scripts occurs, browsers could simply decompose to Unicode Canonical (Decomposed) Normal Form, and flag any accented letters (eg. render them in red in the URL bar).
Re: Google-hosted malvertising leads to fake Keepass site that looks genuine
#188Earlier quoted context omitted.
> Assuming that every language Oof. Take for example, both 糉 and 糭 are valid characters in Chinese. One is a variant of the other. Which one is "canonical" depends on who (i.e. which authority, of which there are many) you ask. And FWIW the language and regional settings don't necessarily give an answer to the canonical representation. Those characters mean the same thing with or without the specks of dust. So, what'…
It still sounds like an improvement: while they might still fall for malicious URLs in their own language, they would not for other scripts. But as someone said, tiny, valid differences are easy to miss anyway, and original URL attacks were replacing similar-looking ASCII graphemes (eg. l for 1), so this will all continue.
> while they might still fall for malicious URLs in their own language, they would not for other scripts.
That's totally backwards. If the assumption is that users of language X will legitimately visit sites of language Y with sufficient frequency, then all that language-specific filtering makes no sense.
Re: Google-hosted malvertising leads to fake Keepass site that looks genuine
#189Punycode is of questionable use anyway. Granted I'm mostly looking into this from a primary latin alphabet perspective, but for the various non-latin alphabet sites I've browsed over the past decade all of them just stuck to regular ASCII domains. (Heck you see this even with usernames on websites that allowed Unicode to be used; most non-latin alphabet users will still stick to the Latin alphabet for usernames.) The…
Unpopular opinion: Trying to shoehorn all of Unicode into domain names was a bad idea. We should have stuck with case-insensitive ASCII [A-Za-z0-9-].
Re: Google-hosted malvertising leads to fake Keepass site that looks genuine
#190Punycode is of questionable use anyway. Granted I'm mostly looking into this from a primary latin alphabet perspective, but for the various non-latin alphabet sites I've browsed over the past decade all of them just stuck to regular ASCII domains. (Heck you see this even with usernames on websites that allowed Unicode to be used; most non-latin alphabet users will still stick to the Latin alphabet for usernames.) The…
One of the issue with ascii domains is the phonetic mapping for CJK languages. For instance right not asahi.com is taken by 朝日 (Asahi shibun, the newspaper), thus the Asahi town (旭) cannot use it. Mind you, the town could take asahi-town.co.jp or something like that, but there is other Asahi towns and places with different writings (including 旭日, 朝陽、浅緋 etc.) Wanting all of them to have some random ascii diversificati…
That seems to be mostly accidental and unrelated to ASCII: there are multiple towns named "London" and by the way that DNS works, only one of them can be "london.com" or "london.info" or...
While I can see an argument for expecting to find whatever brand you think most relevant at BRAND.com(mercial), first-come-first-served is as fair as we can realistically get to (with some protections against misrepresentations and squatting).
Note that I am not against IDNs: I just think your argument is flawed in their support.
Again, Unicode is what allows all languages to be written out, and the fact similar-looking-URL issue is more present (it's present with ASCII too) is not a slight against Unicode and IDNs: we just need to solve for it.