Slashdot Mirror

reminds me of this

On 44.0.2403.89, I get that "http://a/%%30%30" does not crash, but "data:text/html,test" (sans quotes) does when you hover over the link. It seems to rewrite it into something safe(r) without the extra indirection.

It's not broken, it's just dumb.

curl -vL http://goo.gl/5WtI0B
* Ignoring the response-body
* Connection #0 to host goo.gl left intact
* Issue another request to this URL: 'http://a/%2500'
* Could not resolve host: a
* Closing connection 1
curl: (6) Could not resolve host: a

But I couldn't get http://a/%2500 to break any of my browsers, so not sure what to do with that.

They are just trying to rickroll you

I'm fustrated, has /. become a text version of bad tumblr GIF's?

http://a/%2500

Piffle...

ftp://a/%%30%30

The certificate won't be valid for the site that you wanted, but that won't matter because it'll have redirected you to https://a/ load of characters that look like 'paypal.com/somepath' but are actually non-ASCII characters].evil.com with a wildcard certificate for *.evil.com and look like https://paypal.com/some-path-here-that-is-really-really-really-really-long.evil.com/

Hrm. I must have missed that; it's a clever trick. Then again, I've always thought international domain names were gratuitously unnecessary.

The solution to this problem is simple, and I'm surprised browsers don't do this already: add fake '/' character isn't in the IDN blacklist. In Firefox, network.IDN.blacklist_chars already contains plenty of things that look like '/'. Maybe other browsers need to follow its example.

If you read some of the articles (Forbes and a linked one) he can spoof the appearance of a valid certificate as well using International Domain Names. The certificate won't be valid for the site that you wanted, but that won't matter because it'll have redirected you to https://a/ load of characters that look like 'paypal.com/somepath' but are actually non-ASCII characters].evil.com with a wildcard certificate for *.evil.com and look like https://paypal.com/some-path-here-that-is-really-really-really-really-long.evil.com/

For the basic attack then actually checking for HTTPS and a proper validation (not just a padlock, but a padlock and the other markers), but for the fuller attack that takes advantage of the IDN then you'd probably need to read the certificate itself, which would require you to know which certificate you're expecting, which would require something like a page with the signature on saying "look for this", which could then also be spoofed (in cases where it was worth it, e.g. a bank).

One thing that DNS did badly in the early days, was to add extensions for email (the MX tag). That was an application-specific addition to something which was basically a globalised /etc/hosts file.

This was spotted early on, and although we are stuck with that mess now, adding more application-specific crap into DNS would make the existing DNS mash worse than it already is.

I would rather that someone suggest a method to remove MX stuff from DNS without breaking the existing email infrastructure... I don't have the answer myself, but if some genius can find a way to do that, then the Internet can become a better place.

http://a/

Mod parent up! by Anonymous Coward (Score:5) Thurs, June 31, @13:37

your sig is brilliant! had me confused for a minute there :P

"* Mod parent up! by Anonymous Coward (Score:5) Thurs, June 31, @13:37"

Best. Sig. Ever.

mgoo
ewve
xext
ncvg
zgif
dydg
hhtn
jiwh
pywr
\ | o ">gcma
| / a ">xbby
|_/ t ">vylp
/ \ s ">hvyf
nfmm
kmun
jntb
ktml
kjon
vktd
jggn
qavl
zaoh
tlmt