4 ms·

The CNAMEs change it to a same site / first party relationship. It says it right in the article summary. I assume the way it works is that instead of `trackin

The CNAMEs change it to a same site / first party relationship. It says it right in the article summary. I assume the way it works is that instead of `tracking.example.com` where everyone can block `example.com`, they have users set up CNAMEs instead. So you get: - extras.example.net --> tracking company IP behind a huge CDN - awesone.example.org --> tracking company IP behind a huge CDN The sites are different, but when you visit them you're hitting the tracking servers who get to see you hit both sites. Even worse, they can set cookies on the the domain, which is why someone else said there are security implications. I've been saying it for years. Eventually everything will appear to be first party and hitting huge CDN IPs. It's easy to do right now already. Go read the Cloudflare blog article on proxying Google Fonts via Workers. Then think about the Cloudflare Apps and how easy it would be to build an app that rotated first party CNAMES and used Workers to dynamically rewrite HTML to proxy the tracking to ad companies. TLDR; We're super screwed.

thrwwy0304 6y ago
We're not super screwed. extras.example.net is still third-party to awesome.example.org. The tracking company has no way of knowing that an HTTP request to extras.example.net is from the same user as an HTTP request to awesome.example.org. If you were operating the tracking company, how would you try to determine the same user is behind both requests? Happy to be proven wrong, but I don't believe it's possible with third-party cookie protections in place.
- fluidcruft 6y ago
  Based on reading the links someone posted, my understanding is that the way this CNAME stuff works is: 1. awesome.example.org would add a CNAME record that resolves tracking-you.example.org to the server referenced by evil.com 2. awesome.other.net would add a CNAME record that resolves tracking-you.other.net to the server referenced by evil.com 3. etc everywhere on the internet Because these are CNAME, DNS hides all of this from the browser and it just sees the resolved address and the original requested name. So tracking-you.example.org and tracking-you.other.net both now think the server controlled by evil.com is first-party. evil.com now gets all the first-party cookies. In the past they would have only got third-party cookies and the first-party cookies wouldn't be seen by evil.com. But it gets worse because evil.com is also tracking you (it's what they're explicitly doing) so they can link users across the sites. This means evil.com has all it needs to spoof you cross-site because they now have all the first-party auth tokens. Unless you diligently never use the sites simultaneously and remember to log out between using websites. But even if you did, they can still do anything they want as you while you're logged in to the site. So, yeah. It actually looks like a disaster and we're super screwed.
  - thrwwy0304 6y ago
    Your example is reliant on UserA visiting example.com having the same "auth token" as UserA visiting other.net. That's not the case. Both example.com and other.net are likely to be generating completely unique auth tokens. example.org and other.net can certainly both coordinate with evil.com to manually share more detail (e.g. the current user is UserA@gmail.com), but if that's the threat then browsers have no chance at offering protection.
    - fluidcruft 6y ago
      No, it's not reliant on that at all. The CNAME trick means that the browser forwards each site's auth tokens directly to evil.com's servers whenever you use that site. And since evil.com's entire reason d'etre is to track you across sites, it's trivial for them to store and link your auth tokens from all the sites you visit.
      - thrwwy0304 6y ago
        When evil.com receives an auth token for a user visiting example.org, how does it know which user that token is associated with? Then, when evil.com receives a different auth token for the same user visiting other.net, how does evil.com know that new auth token correlates to the same user on example.org? This is the third-party identity linking that's now impossible for evil.com to accomplish independently. They need other.net and example.org to share some common information (like an email address) to make the link. For logged out users, it should be impossible without resorting to fingerprinting. This was Firefox and Safari's entire reason d'etre for launching Total Cookie Protection and Intelligent Tracking Protection. I don't believe CNAME cloaking overcomes their protections, or at the very least, I don't see where this paper explains an attack vector.
      - tatersolid 6y ago
        Except your auth tokens on the each site should be opaque identifiers and can’t be linked. Unless both sites are using the disaster that is JWT/JOSE as their token format with signing only and not encryption.
- donmcronald 6y ago
  > extras.example.net is still third-party to awesome.example.org Yes, that's right. I'm making the assumption that letting the request succeed at all is on the losing side of the battle. For me, I know I'm 100% trackable across the internet with my IP address (it hasn't changed in 2 years) and my screen resolution (the only 4k monitors behind that IP). If I don't block the request in the first place, the tracking company fingerprints my browser and sets that as a cookie. The reason I say we're completely screwed is that I think we'll see all kinds of dirty tricks. Ex: auth = ads under the header and auth.example.net is actually a tracking domain. That's much harder to prevent than sending ads.example.com to a black hole.
  - thrwwy0304 6y ago
    Agreed - letting the request fire at all is the critical point, and I believe that's the true motivation behind using CNAMEs (they evade blacklists). CNAMEs and first-party cookie access aren't helping networks link identities across sites in Firefox and Safari - at this point they're stuck relying on browser fingerprinting. And as you point out, fingerprinting can be quite effective, especially for people on static IPs :| This paper is claiming that CNAMEs are evading the protections offered by Safari and Firefox but that's just not the case. Or at least, the paper hasn't explained how.
- tinus_hn 6y ago
  They can both set and read cookies for example.org . You can specify the domain when you set cookies, but it is limited to the domain your page is on (and browsers have lists of domain parts that are banned so you can’t for instance set cookies on co.uk )
- nybble41 6y ago
  It's the other way around. The main site is example.com and the ads/tracking are at ads.example.com (which is a CNAME pointing to some server controlled by the advertiser). So they have the same second-level domain and are considered related origins. Of course ads.example.com could just as well have A/AAAA records pointing to the same ad server, which would neutralize any attempt to infer separate origins based on CNAME records. It would just be slightly more difficult to administer since the owner of example.com would need to update their DNS records whenever the ad server's IP address changed—but that could be automated, and the IPs are probably mostly static anyway.
  - mildred593 6y ago
    I always thought that was a bad decision, thinking that subdomains could be related security-wise to other domains looking the same. DNS was thought out from the beginning so you could split it anywhere you wanted to delegate things, and you can also delegate with CNAME too. I'd welcome a security model that does not use origins. It's doable, but the origin trick was a convenient way to enforce some security measures bolted on as an after thought without breaking much the compatibility.
  - JdeBP 6y ago
    It's called "CNAME Flattening" (or "ALIAS records") and has been widely available from hosting providers since 2014. I was talking about server-side aliases a decade before that, and I was far from the only person doing so. You have the explanation right. But your hypothetical future dystopia is actually the world of today. (-:
volderette 6y ago
Nope, not super screwed at all. Safari even limits http cookies if the cname doesnt match. „On Safari 14 (requires Big Sur) and on all major iOS and iPadOS 14.2+ browser apps, expiration of cookies set with Set-Cookie HTTP response headers is 7 days at most, if the response originates from a subdomain that has a CNAME alias to a cross-site origin“ https://www.cookiestatus.com/ https://www.cookiestatus.com/
- Krisando 6y ago
  You should read the paper, it literally discusses how they were getting around that and discovered vulnerabilities because of it.

thrwwy0304 6y ago

We're not super screwed. extras.example.net is still third-party to awesome.example.org. The tracking company has no way of knowing that an HTTP request to extras.example.net is from the same user as an HTTP request to awesome.example.org. If you were operating the tracking company, how would you try to determine the same user is behind both requests? Happy to be proven wrong, but I don't believe it's possible with third-party cookie protections in place.

fluidcruft 6y ago
Based on reading the links someone posted, my understanding is that the way this CNAME stuff works is: 1. awesome.example.org would add a CNAME record that resolves tracking-you.example.org to the server referenced by evil.com 2. awesome.other.net would add a CNAME record that resolves tracking-you.other.net to the server referenced by evil.com 3. etc everywhere on the internet Because these are CNAME, DNS hides all of this from the browser and it just sees the resolved address and the original requested name. So tracking-you.example.org and tracking-you.other.net both now think the server controlled by evil.com is first-party. evil.com now gets all the first-party cookies. In the past they would have only got third-party cookies and the first-party cookies wouldn't be seen by evil.com. But it gets worse because evil.com is also tracking you (it's what they're explicitly doing) so they can link users across the sites. This means evil.com has all it needs to spoof you cross-site because they now have all the first-party auth tokens. Unless you diligently never use the sites simultaneously and remember to log out between using websites. But even if you did, they can still do anything they want as you while you're logged in to the site. So, yeah. It actually looks like a disaster and we're super screwed.
- thrwwy0304 6y ago
  Your example is reliant on UserA visiting example.com having the same "auth token" as UserA visiting other.net. That's not the case. Both example.com and other.net are likely to be generating completely unique auth tokens. example.org and other.net can certainly both coordinate with evil.com to manually share more detail (e.g. the current user is UserA@gmail.com), but if that's the threat then browsers have no chance at offering protection.
  - fluidcruft 6y ago
    No, it's not reliant on that at all. The CNAME trick means that the browser forwards each site's auth tokens directly to evil.com's servers whenever you use that site. And since evil.com's entire reason d'etre is to track you across sites, it's trivial for them to store and link your auth tokens from all the sites you visit.
    - thrwwy0304 6y ago
      When evil.com receives an auth token for a user visiting example.org, how does it know which user that token is associated with? Then, when evil.com receives a different auth token for the same user visiting other.net, how does evil.com know that new auth token correlates to the same user on example.org? This is the third-party identity linking that's now impossible for evil.com to accomplish independently. They need other.net and example.org to share some common information (like an email address) to make the link. For logged out users, it should be impossible without resorting to fingerprinting. This was Firefox and Safari's entire reason d'etre for launching Total Cookie Protection and Intelligent Tracking Protection. I don't believe CNAME cloaking overcomes their protections, or at the very least, I don't see where this paper explains an attack vector.
    - tatersolid 6y ago
      Except your auth tokens on the each site should be opaque identifiers and can’t be linked. Unless both sites are using the disaster that is JWT/JOSE as their token format with signing only and not encryption.
donmcronald 6y ago
> extras.example.net is still third-party to awesome.example.org Yes, that's right. I'm making the assumption that letting the request succeed at all is on the losing side of the battle. For me, I know I'm 100% trackable across the internet with my IP address (it hasn't changed in 2 years) and my screen resolution (the only 4k monitors behind that IP). If I don't block the request in the first place, the tracking company fingerprints my browser and sets that as a cookie. The reason I say we're completely screwed is that I think we'll see all kinds of dirty tricks. Ex: auth = ads under the header and auth.example.net is actually a tracking domain. That's much harder to prevent than sending ads.example.com to a black hole.
- thrwwy0304 6y ago
  Agreed - letting the request fire at all is the critical point, and I believe that's the true motivation behind using CNAMEs (they evade blacklists). CNAMEs and first-party cookie access aren't helping networks link identities across sites in Firefox and Safari - at this point they're stuck relying on browser fingerprinting. And as you point out, fingerprinting can be quite effective, especially for people on static IPs :| This paper is claiming that CNAMEs are evading the protections offered by Safari and Firefox but that's just not the case. Or at least, the paper hasn't explained how.
tinus_hn 6y ago
They can both set and read cookies for example.org . You can specify the domain when you set cookies, but it is limited to the domain your page is on (and browsers have lists of domain parts that are banned so you can’t for instance set cookies on co.uk )
nybble41 6y ago
It's the other way around. The main site is example.com and the ads/tracking are at ads.example.com (which is a CNAME pointing to some server controlled by the advertiser). So they have the same second-level domain and are considered related origins. Of course ads.example.com could just as well have A/AAAA records pointing to the same ad server, which would neutralize any attempt to infer separate origins based on CNAME records. It would just be slightly more difficult to administer since the owner of example.com would need to update their DNS records whenever the ad server's IP address changed—but that could be automated, and the IPs are probably mostly static anyway.
- mildred593 6y ago
  I always thought that was a bad decision, thinking that subdomains could be related security-wise to other domains looking the same. DNS was thought out from the beginning so you could split it anywhere you wanted to delegate things, and you can also delegate with CNAME too. I'd welcome a security model that does not use origins. It's doable, but the origin trick was a convenient way to enforce some security measures bolted on as an after thought without breaking much the compatibility.
- JdeBP 6y ago
  It's called "CNAME Flattening" (or "ALIAS records") and has been widely available from hosting providers since 2014. I was talking about server-side aliases a decade before that, and I was far from the only person doing so. You have the explanation right. But your hypothetical future dystopia is actually the world of today. (-:

volderette 6y ago

Nope, not super screwed at all. Safari even limits http cookies if the cname doesnt match. „On Safari 14 (requires Big Sur) and on all major iOS and iPadOS 14.2+ browser apps, expiration of cookies set with Set-Cookie HTTP response headers is 7 days at most, if the response originates from a subdomain that has a CNAME alias to a cross-site origin“ https://www.cookiestatus.com/ https://www.cookiestatus.com/

Krisando 6y ago
You should read the paper, it literally discusses how they were getting around that and discovered vulnerabilities because of it.