So you knew "since ages" that if only foreign characters are used in a domain, major browsers would bypass converting them to punychars?
Sure you did Einstein.
If this is "Phishing 101" - then what do you teach in "Phishing 201"?
Yeah cause I regulary have to read security bulletins and stuff like that. Part of my work consists of knowing attack vectors and educating coworks how to avoid that get shit like that in our daily mails.
No need to be butthurt or upset if someone knows more or long before you. Shit like that worked mid 90s for ICQ usernames iirc.
If understand that "new" vulnerbility correct it's just an extend of something that worked and works at least for 10+ years. To be fair the trigger of the flaw has changed a bit, but also some browsers had settings to not show punny code or plugins that turned punycode to unicode.
Also that stuff is mentioned in the RFC as "may be converted to punycode" and not must. So the flaw may have it'S starting point there. Also those RFCs are from the early 2000s.
Anyway, maybe you wanna educate yourself a little more on how URLs, IRIs & Punycodes work please read the according pages on the RFC and W3org as a basic.
I linked em below for you:
rfc3987
rfc3492
http://www.faqs.org/rfcs/rfc3490.html
http://www.faqs.org/rfcs/rfc3491.html
http://www.faqs.org/rfcs/rfc3454.html
https://www.w3.org/International/articles/idn-and-iri/
Also I would almost bet, if you generate an url or to be exact a domain name long enough you will trigger some hardlimit that will make the browser discard the conversion to punycode. even if the RFCs for http don't specify or force a hardlimit for urls doesn't mean that browsers won't enforce such.
This attack vector becomes even more fun I guess when you take into credit that some antivirus tools out there bring their own ssl certificate that is link between your session and the original server.
But I don't want to over stress your brain, as this maybe covered in Pishing 301...
