4 ms·

What does immutable really mean when you only rent a domain name? I think about this occasionally with domains and email addresses, they've become a trusted pie

What does immutable really mean when you only rent a domain name? I think about this occasionally with domains and email addresses, they've become a trusted piece of information, but over time the ownership of that thing changes, does make me wonder about fraud in the future when sizeable companies die off and their domains free up.

deleted 9y ago
[deleted]
__jal 9y ago
It is no different than, say, incorporating. If you fail to perform certain rituals each year, you can lose your legal status. The odds of this happening any time soon with Coke are slim, similarly with ownership of coke.com, but it could. Nothing is 'immutable' if you look at it hard enough. The Bible's teachings have changed over time. On the right scale, the Earth is a temporary novelty and questions about proton decay become relevant. Tl;dr: set your expiration dates appropriately and you won't have a problem.
- AgentME 9y ago
  The issue is that an attacker could buy a domain, serve content from it with the cache-control: immutable response, and then later someone else buys the domain, puts their own content on it, but a lot of their users (who had accessed the domain when it was owned by the attacker) have a lot of the attacker's immutable content permanently cached. Even if the second owner follows the advice of setting expiration dates appropriately, nothing helps them.
  - taeric 9y ago
    That ignores attacks on dns and certificate authorities. I could readily see a fun novel about a nation state or isp using this trick to seed malicious code to a lot of public sites. Imagine setting it for index.html on any site with a source that merely bootstraps to the intended site. Along with the malicious code.
    - mseebach 9y ago
      In an attack where DNS and CAs are compromised, immutable caching is going to be be least of our problems, frankly.
      - taeric 9y ago
        Hasn't this happened? Several times? I'm not trying to say it is everyday. But it is easier than you think. Browsers are removing bad authorities. Which is good. There are a lot of them, though. Which is a larger attack surface than many folks acknowledge.
icebraining 9y ago
In this case, if a company dies and a malicious actor gets the domain, there's not much they can do besides tell the browser to load those assets - but they could probably just take a copy of the original site and serve a copy of those assets themselves. The attack might work the other way around: the attacker buys a bunch of domain names, serves "sleeper" malicious JS files with this on common paths (say, the paths used by Wordpress and other common CMSs), then releases the domain. When the new owner installs a CMS and start serving their site, the browser loads the malicious JS instead, which is now running under the new site's Origin (security context).
- prolurker 9y ago
  That's an interesting attack vector, in the section 3 of the RFC they recommend to ignore the directive unless it's a secure connection which would mitigate that kind of problems. Another solution would be to use an unpredictable versioning scheme so the attacker can't anticipate the name of the resources.
  - AgentME 9y ago
    The attacker who buys a bunch of domains and legitimately owns them for a period of time wouldn't have any issue getting SSL certificates for them.
    - prolurker 9y ago
      Correct, but, even if not explicitly said, the cached entries should be associated to the certificate's fingerprint and immediately discarded once the certificate expires or is changed.
      - rav 9y ago
        Certificates often change for legitimate reasons, e.g. Let's Encrypt certificates which must be changed every 3 months.
        9y ago

deleted 9y ago

[deleted]

__jal 9y ago

It is no different than, say, incorporating. If you fail to perform certain rituals each year, you can lose your legal status. The odds of this happening any time soon with Coke are slim, similarly with ownership of coke.com, but it could. Nothing is 'immutable' if you look at it hard enough. The Bible's teachings have changed over time. On the right scale, the Earth is a temporary novelty and questions about proton decay become relevant. Tl;dr: set your expiration dates appropriately and you won't have a problem.

AgentME 9y ago
The issue is that an attacker could buy a domain, serve content from it with the cache-control: immutable response, and then later someone else buys the domain, puts their own content on it, but a lot of their users (who had accessed the domain when it was owned by the attacker) have a lot of the attacker's immutable content permanently cached. Even if the second owner follows the advice of setting expiration dates appropriately, nothing helps them.
- taeric 9y ago
  That ignores attacks on dns and certificate authorities. I could readily see a fun novel about a nation state or isp using this trick to seed malicious code to a lot of public sites. Imagine setting it for index.html on any site with a source that merely bootstraps to the intended site. Along with the malicious code.
  - mseebach 9y ago
    In an attack where DNS and CAs are compromised, immutable caching is going to be be least of our problems, frankly.
    - taeric 9y ago
      Hasn't this happened? Several times? I'm not trying to say it is everyday. But it is easier than you think. Browsers are removing bad authorities. Which is good. There are a lot of them, though. Which is a larger attack surface than many folks acknowledge.

icebraining 9y ago

In this case, if a company dies and a malicious actor gets the domain, there's not much they can do besides tell the browser to load those assets - but they could probably just take a copy of the original site and serve a copy of those assets themselves. The attack might work the other way around: the attacker buys a bunch of domain names, serves "sleeper" malicious JS files with this on common paths (say, the paths used by Wordpress and other common CMSs), then releases the domain. When the new owner installs a CMS and start serving their site, the browser loads the malicious JS instead, which is now running under the new site's Origin (security context).

prolurker 9y ago
That's an interesting attack vector, in the section 3 of the RFC they recommend to ignore the directive unless it's a secure connection which would mitigate that kind of problems. Another solution would be to use an unpredictable versioning scheme so the attacker can't anticipate the name of the resources.
- AgentME 9y ago
  The attacker who buys a bunch of domains and legitimately owns them for a period of time wouldn't have any issue getting SSL certificates for them.
  - prolurker 9y ago
    Correct, but, even if not explicitly said, the cached entries should be associated to the certificate's fingerprint and immediately discarded once the certificate expires or is changed.
    - rav 9y ago
      Certificates often change for legitimate reasons, e.g. Let's Encrypt certificates which must be changed every 3 months.
      - 9y ago