> The cookie spec RFC 6265 section 5.1.2 defines the host name in a way that makes it ignore trailing dots. Cookies set for a domain with a dot are valid for the same domain without one and vice versa.
Well... that's not what the browsers do. If you're logged in to HN, try it now. Add a dot to the host name. Cookie is gone. Remove the dot. It's back.
Another fun interaction of trailing dot in URLs and web browsers: password management.
This is layers far above the curl internals discussed in the article.
On some platforms, the built in web password management considers web passwords for URLs with or without a trailing dot as distinct situations. Same for the 1Password manager.
I can't think of problems this might cause.
As long as we're trying to break things, I presume it would be easy enough to use JavaScript to switch the current URL to the one with a different trailing dot situation than the current application flow. Like in the middle of a hand-off from one authorization screen to another.
I tend to consider multi-page web application issues as a much higher plane than something curl library internals. But essentially, the back-and-forth of web communication isn't so different.
I don't understand the HSTS part/situation. If trailing dot vs. non-trailing dot are to be treated as different identities because they could theoretically serve different vhosts, why is it (technically) not correct to ignore HSTS for one if only set by the other?
I assume a big reason is cookies, which are specced to be shared across the two versions: an attacker could relatively trivially trigger a request to http://example.com. which would get example.com's cookies, but not the HSTS upgrade that would prevent them from being sent in plaintext.
> The cookie spec RFC 6265 section 5.1.2 defines the host name in a way that makes it ignore trailing dots. Cookies set for a domain with a dot are valid for the same domain without one and vice versa.
Well... that's not what the browsers do. If you're logged in to HN, try it now. Add a dot to the host name. Cookie is gone. Remove the dot. It's back.
That wouldn't be the first time web browsers do something that's contrary to spec (and sanity).
Also, I think the section that was intended to be referenced was section 5.1.3.
Another fun interaction of trailing dot in URLs and web browsers: password management.
This is layers far above the curl internals discussed in the article.
On some platforms, the built in web password management considers web passwords for URLs with or without a trailing dot as distinct situations. Same for the 1Password manager.
I can't think of problems this might cause.
As long as we're trying to break things, I presume it would be easy enough to use JavaScript to switch the current URL to the one with a different trailing dot situation than the current application flow. Like in the middle of a hand-off from one authorization screen to another.
I tend to consider multi-page web application issues as a much higher plane than something curl library internals. But essentially, the back-and-forth of web communication isn't so different.
I don't understand the HSTS part/situation. If trailing dot vs. non-trailing dot are to be treated as different identities because they could theoretically serve different vhosts, why is it (technically) not correct to ignore HSTS for one if only set by the other?
I assume a big reason is cookies, which are specced to be shared across the two versions: an attacker could relatively trivially trigger a request to http://example.com. which would get example.com's cookies, but not the HSTS upgrade that would prevent them from being sent in plaintext.
That makes sense. What a stupid mess all of this is.
[dead]