4 ms·

I learned once of a quick workaround that's baffling - putting a dot at the end of the domain name (example.com/page becomes example.com./page) Apparently this

• airstrike 2y ago
  > so it would bypass the limit, but if you kept doing it then it'd probably accumulate free articles still and stop working at which point one could perhaps try visiting example.com../page
  • bqmjjx0kac 2y ago
    The reason the trailing dot works is that it represents the implicit root DNS node. Browsers do the dumb thing and consider it a different domain, but AFAIK there's no good reason not to canonicalize the domain name. All that to say, no, you sadly can't add another trailing dot.
    • jonhohle 2y ago
      I had never thought about having a local search domain so something like google.com.mynetwork. would resolve (the tailing dot prevents search domain lookups). Would a browser allow that internal site to access google.com cookies (since the lookup would be for google.com, no trailing dot). I suppose that would only work for unsecured traffic anyway so maybe not a huge attack vector. Edit to add: if you have web services that are resolved via DNS, it may be a performance advantage to configure clients with the trailing dot. A lifetime ago we ran into intermittent latency issues when some DNS resolvers would try to search before checking the canonical entry.
      • cortesoft 2y ago
        That wouldn't work because Google would not return the proper content, since the host header would not match google.com. HTTPS would not work either, like you said, because the cert would not match the new domain. If they didn't check host headers, then no, the browser would not send the cookies for google.com, since the browser has no idea about your DNS changes and is only looking at the domain name itself.
    • WarOnPrivacy 2y ago
      > Browsers do the dumb thing I could use more browser dumb things like this. Like when the browser won't ever forget that you once visited an HSTS server at this domain and now+forever won't let you visit the http server (at the same domain).
      • sunshowers 2y ago
        There's a string you can type in blind that bypasses HSTS. Works on Chromium browsers. I don't want to make to too easy to find so I won't say it here but you can look for it.
        • cortesoft 2y ago
          You really think HN readers can't find the interstitial bypass keyword? It shows up in the very first Google search for it, I am not sure who you think you are protecting. I also find it goes against the ethos of HN to try to prevent a user from controlling their own hardware... if I want to MITM myself, I should be able to.
          • sunshowers 2y ago
            I was more concerned about it becoming more prominent in Google search results but I was just having a moment, never mind :)
        • WarOnPrivacy 2y ago
          > Works on Chromium browsers. Saw that a few days ago but I don't do Chromium browsers. Cest la vie. Appreciate the attempt.
        • tiberious726 2y ago
          Don't be ridiculous. The string is 'thisisunsafe' just type it when the hsts whining page has focus, no text box.
• kazinator 2y ago
  That kind of bug happens under the "everything is a string" software paradigm. Abstractions that have more than one string representation inadvertently end up treated as different.
  • darby_nine 2y ago
    They are semantically different—one is a relative domain name, the other is distinct. I'm not sure how this impacts localstorage or cookies but it might.
    • deleted 2y ago
      [deleted]
    • OptionOfT 2y ago
      Localstorage and cookies are stored by domain. If the relative domain is kept relative then it will never be equal to the absolute domain. Or let map = HashMap::from_iter([ "www.domain.com.": Cookiebag::new(), "www.domain.com": Cookiebag::new(), ]);