8 ms·

See TFA, which shows the use of confusable homographs for forward-slash and question mark.

by cryptonector 4y ago

teddyh 4y ago
But if, as I wrote, the registry for .com does not allow homoglyphs, then an adversary cannot register such names.
- cryptonector 4y ago
  You clearly did not read the actual article. Here's a sample from it: $ curl https://google.com/.curl.se curl: (6) Could not resolve host: google.xn--com-qt0a.curl.se Get it? That `/` after `google.com` isn't an ASCII `/`, and the TLD (se) doesn't have anything to do with this.
  - teddyh 4y ago
    Ah, right, if you could find an unscrupulous TLS, say, .evil, one could register xn--com-qt0a.evil and set up so that it has a subdomain "google", making google.com⁄.evil lead there. OK, I guess then that IANA should disallow all TLD registries from registering such names.
    - cryptonector 4y ago
      The registered domainname in the above example is curl.se, and the registry is se. As far as the registry is concerned, the domainname is all ASCII. The evil label is created by the operator of the registered domain, not the registry. The only way the registry can act in this case is to ban the domain if the registry observes the attack, but they might never see it.
      - teddyh 4y ago
        Oh, I see. In that case, I guess it’s up to the browser. Maybe the address bar should not be displayed as a string, but as separate fields for the different URL components? One field for protocol, one for optional user name (for HTTP auth), one field for host name, one for the path, etc.
        cryptonector 4y ago
        Yes, it's up to the browser -- the UI anyways. The UI should do something to protect users from this. One thing that would be nice is that IRIs you enter, should be in Unicode, while other IRIs should be displayed in A-label form (punycoded), and there should be a button you can use to switch from U-label for to A-label form for the window location URI.

See TFA, which shows the use of confusable homographs for forward-slash and question mark.

teddyh 4y ago

But if, as I wrote, the registry for .com does not allow homoglyphs, then an adversary cannot register such names.

cryptonector 4y ago
You clearly did not read the actual article. Here's a sample from it: $ curl https://google.com/.curl.se curl: (6) Could not resolve host: google.xn--com-qt0a.curl.se Get it? That `/` after `google.com` isn't an ASCII `/`, and the TLD (se) doesn't have anything to do with this.
- teddyh 4y ago
  Ah, right, if you could find an unscrupulous TLS, say, .evil, one could register xn--com-qt0a.evil and set up so that it has a subdomain "google", making google.com⁄.evil lead there. OK, I guess then that IANA should disallow all TLD registries from registering such names.
  - cryptonector 4y ago
    The registered domainname in the above example is curl.se, and the registry is se. As far as the registry is concerned, the domainname is all ASCII. The evil label is created by the operator of the registered domain, not the registry. The only way the registry can act in this case is to ban the domain if the registry observes the attack, but they might never see it.
    - teddyh 4y ago
      Oh, I see. In that case, I guess it’s up to the browser. Maybe the address bar should not be displayed as a string, but as separate fields for the different URL components? One field for protocol, one for optional user name (for HTTP auth), one field for host name, one for the path, etc.
      - cryptonector 4y ago
        Yes, it's up to the browser -- the UI anyways. The UI should do something to protect users from this. One thing that would be nice is that IRIs you enter, should be in Unicode, while other IRIs should be displayed in A-label form (punycoded), and there should be a button you can use to switch from U-label for to A-label form for the window location URI.