A disquieting thought on DW and DNS privacy

[squirrelitude]

Dreamwidth is a little unusual in giving everyone their own subdomain. Off the top of my head, I can only think of three other sites that do this: Its predecessor (Livejournal), Tumblr, and DeviantArt. There are almost certainly others, but it's uncommon.

Even though all communications to the site are done over a secure connection, so the *contents* of the pages are hidden from your ISP, any government interlopers, nosy parents who have installed spyware on the home router, and people snooping on your use of insecure café WiFi... the domain name you're visiting (here, squirrelitude.dreamwidth.org) is still being broadcast in two ways:

• When your computer asks the Domain Name System for the IP address of the site, it sends the domain name out in the clear[1], and the DNS server of course knows what domain you're asking for
  
• When your computer then connects to that IP address, it mentions the domain name in the initial message to the server[2]
  

That means that within a few minutes of poking around on Dreamwidth, anyone who can watch your internet traffic likely knows 1) who your friends are, and 2) by that token, who *you* are. (If you stick to just your Reading Page, you are not leaking your circle's usernames to any watchers, but you are leaking your own.)

I feel like this is maybe something that could and should be changed, since DW is already a centralized service and doesn't *need* separate domain names. (My social media prototype will *need* it, to some extent, which is a sobering thought.) I don't know if I believe this strongly enough to advocate for it,

Another option is to access DW via Tor! I just fired up TAILS and confirmed that I can log in to Dreamwidth just fine. [3] (No captchas or other nonsense.) Unlinking your home IP from the domain you're visiting (and those domains from each other) in the eyes of someone snooping on network traffic is *precisely* what Tor is for. So regardless of whether DW takes action on this, if this is a privacy issue for you, there is a way you can protect yourself. (Also applies to Tumblr, DeviantArt, etc.)


[1] This first part does not apply for people using experimental DNS-over-HTTPS—only the DNS server can read the request

[2] The Server Name Indication TLS header, which is unencrypted in current versions of TLS. TLS 1.3 allows encrypting it, but that's still being rolled out.

[3] Tor is quite safe to use as long as you're visiting HTTPS websites, which is most sites these days. But advice to heed browser warnings about invalid certificates applies doubly so over Tor. If you ignore those, Tor becomes *less* safe than using the internet directly. So don't. :-)

Comments

[moem]

That is a good point. I've never given it much thought, except for from the other end: I'm a crafter. Sometimes I post stuff on Instructables, and then write about it here on DW. Instructables will show me page views and referrers. And from that I can see which of my friends clicked through.
... I'm not sure that's any of my business.

[squirrelitude]

Ouch, right. I hadn't even thought about referrers.

I don't actually know what the current state of the browsers is w.r.t. Referer headers, especially now that most everything is HTTPS. Do you happen to know if they get the full URL when it's an HTTPS->HTTPS transition, or whether they're stripping it down to the empty path? I vaguely recall some movement towards tamping down on that leakage.

But either way, they're getting the domain, which means either the username of either the author or the reader. :-/

ETA: Probably DW should be setting the Referer-Policy header at minimum. I think I'll recommend that change, since it's a pretty easy one...

[moem]

Do you happen to know if they get the full URL when it's an HTTPS->HTTPS transition, or whether they're stripping it down to the empty path?

Sorry, no... you've hit the limitations of my knowledge here. I'm not that kind of a hacker.

[squirrelitude]

Ah, OK! Wasn't sure.

What I do know is that only a few sites break if you remove Referer altogether (usually bank and corporate intranet sites) but that just passing the origin (scheme, domain, port) will let almost everything work without revealing too much. I think Mozilla was experimenting with having Firefox do this, but I have no idea what Chrome does.

[nablacdotu]

> Do you happen to know if they get the full URL when it's an HTTPS->HTTPS transition, or whether they're stripping it down to the empty path?

Based on an earlier issue with referer that I'm familiar with, I think the answer is yes:
https://blogs.dropbox.com/dropbox/2014/05/web-vulnerability-affecting-shared-links/

[metahacker]

I have been known to break links (i.e. post text instead of a link) specifically to avoid this...Referer really doesn't make a great deal of sense these days, with so many entities watching your every move.

[elusiveat]

I don't know what opinions I have about the privacy issue, but I kind of like automatically having a slick journal URL with my own subdomain...

Everything is hard, I guess.

[siderea]

I feel like this is maybe something that could and should be changed, since DW is already a centralized service and doesn't *need* separate domain names.

That may be incorrect. LJ originally had the subdomain thing only as a paid-account vanity feature, then abruptly rolled it out for all users because for some reason they needed to. I seem to recall it was a security-related thing, but I'm not sure about that. I can try to hunt the info up.

ETA: Aha!

https://indieweb.org/lj2006 which points to:

https://news.livejournal.com/2006/01/19/
https://lj-dev.livejournal.com/708069.html
https://lj-dev.livejournal.com/705401.html

[squirrelitude]

Yup, this is about what I suspected. (I've exploited JS-in-CSS vulnerabilities in several sites.) Thanks for the historical links! It's really interesting to see how they handled the cookies, in particular.

I don't know if any currently popular browser versions still allow it, although I seem to recall that Internet Explorer held onto "CSS expressions" for quite a long time, and maybe IE 11 still has them. With Firefox's move away from XBL, I suspect that the XBL vector is gone.

But the right answer is quite simple: Validate stylesheets against allowlists. This is not actually all that difficult, and what should have been done in the first place. Reddit does this for their custom subreddit stylesheets, for instance. This wouldn't be a quick change to implement, since there's surely quite a bit of broken CSS in custom styles. Users would have to be given maybe 6 months to make any fixes they wanted, and perhaps as a fallback the style would revert to some defaults.

The total work involved is high enough that I don't think the DW admins would decide to take it on, but at this point I feel like I should at least bring it to their attention.

[elusiveat]

To clarify, Squirrelitude, would the simple answer you describe do away with (or at least bypass) the existence of custom subdomains?

Is there any way to solve the problem that would still enable users who want the subdomains to still have them?

[squirrelitude]

Validating CSS would probably be sufficient for allowing links like https://dreamwidth.org/users/squirrelitude to work, instead of redirecting to the subdomain, which is what they currently do. And then there could be a user preference for the reading page, RSS/Atom feeds, etc. to *generate* such links, and to redirect to the URL format of choice. There'd still be some leakage, but not as much.

I don't know if there's another way of solving this. I also haven't convinced myself that it *needs* to be solved. :-)