9 ms·
Does “www.” Mean Better Transport Layer Security?
- temptemptemp111 7y agoJust translates to 666 in Hebrew. Ya, they're hopelessly obsessed. "World Wide Web" even has fewer syllables than "WWW." I don't know why they think they're so clever.
- numlock86 7y agoInteresting. From my observation less and less sites actually use the www subdomain. Some give plain 404, domain not found, certificate errors and similar when browsing them with (or without) www, depending on how they are set up. It's a mess, really. Usually they actually behave the same, including TLS configuration etc. Also something I observe daily: When I tell someone to go to "example.com" some will punch in "www.example.com", others will simply do "example.com". There is also the ultra rare occurrence of someone typing in "http://www.example.com" http://www.example.com". Personally I just configure www to point at the same as the regular domain and have the www as a "subject alternative name" in the certificates. And in Nginx it's as easy as just adding it to the "server_name". I suspect it's the same for all other major HTTPDs.
- xg15 7y agoI wonder how generalizable your experience is, though. I imagine this could very well be a trend in tech circles, where knowledge is widespread that "www" is mostly optional and the domain name is the relevant part. (And people tend to enter a lot of urls manually so they shorten them as much as possible). I could imagine that this might be different among non-technical users, where the exact meaning of domains, subdomains and the "https" and "www" prefixes are less well-known. I have no data to back that up, though.
- toomanybeersies 7y agoMy (also non-data backed) guess would be it's a generational thing. When I was a kid in the early 2000's, most web addresses were "www.domain.com", that's what you'd see on written material like advertising or articles. These days if an ad has a web address it usually doesn't include the `www.` subdomain.
- feanaro 7y agoI would say the opposite. From my experience technical users are the ones that insist on "www" while non-technical users just follow the general trend of eliding it and are unaware of what it means exactly.
- tester344 7y agoWeird. I'd rather say that tech users would use shorter version because there should be no diff between www/nowww
- gumby 7y agoWhy should there inherently be no difference?. They are simply nMes. I’ve had people tell me things are broken when I send them to foo.example.com and they insist on typing the nonexistent www.foo.example.com.
- feanaro 7y agoExactly. The point is that there is a difference between www and nowww. The only reason they usually lead to the same result nowadays is a social convention and those can change arbitrarily. Tech people are aware of this but non-tech people notice and learn this convention by association and might be (and from my experience, are) unaware that it is not a technically guaranteed one.
- 6nf 7y agoAnnoyingly Chrome doesn't even show the 'www' any more unless you actually click on the URL bar
- numlock86 7y agoFor me it even takes two clicks: The first will just mark the visible URL, the second will reveal the complete URL including the protocol.
- feanaro 7y agoThese URL mangling behaviours of Chrome are getting really insane. It kind of works for very well known, ultra large sites like Facebook, Youtube, Google and other large corporations, but how are you supposed to know whether you're at the right place for the myriad of smaller and/or personal websites if most of the URL is hidden?
- Avamander 7y agoHonestly, you should be redirecting from either www. to . or vice versa, having one of them broken or doing something else is bad in 99.99% of cases.
- notfashion 7y agoThe way you are using "www." and "." is incorrect. The dot isn't part of the local hostname "www". It is a separator or delimiter for the textual elements in the domain name. "Redirecting from (or to) ." is a weird and as far as I know completely wrong way to talk about redirecting from or to the domain name one level up in the hierarchy. The only time a dot plays any role in a domain name (other than that of a simple separator) is when it's used at the end of the fully qualified domain name.
- Avamander 7y agoWhat if I'm talking about redirecting an entire TLD "www" to ""? Obviously it's a separator, I just found writing "" and "www" too weird. Not to mention that in this context where you're not really a recursive DNS resolver it really doesn't matter how one specifies the existence or lack of it of a subdomain. In addition to that some things use "@" (instead of the dot I used).
- z3t4 7y agoFor SEO reasons you should redirect to either one.
- parsimo2010 7y agoA quick summary from a layman: Most websites that have both a www-domain (www.example.com) and a plain domain (example.com) tend to have better security configurations on the www-domain. It's worth noting that they seem to have scanned only for some known weaknesses, and that there is no law stating that www-domains must be stronger. Also, some websites that implement both www and plain may implement a redirect to a weaker configuration (oops). They analyzed about 1.3 million websites, so it's a decent chunk of the internet. Of note to me is that they didn't comment on why they might be configured differently. As in, does following a popular tutorial to configure Apache or Nginx neglect the plain domain? You couldn't determine the reason through a web scan so I don't blame the researchers for offering the reason. They also don't offer any way to fix the disparity. Obviously, the best practice is to just configure your server's www and plain domains correctly, but clearly most of the internet isn't following their best practices checklist.
- windowsworkstoo 7y agoThe crap apex domain difference is probably explainable due to the fact you can't CNAME an apex (Yes, some CDN's/systems have work arounds). So www gets put behind a nicely configured CDN with decent TLS settings, whereas the apex gets a crappy HTTP redirection service or maybe worse, the actual origin itself, serving up a half baked config.
- aloknnikhil 7y agoHighly probable. Cloudflare, for example, has CNAME flattening to address this problem. https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/ https://blog.cloudflare.com/introducing-cname-flattening-rfc...
- nik736 7y agoI use www. for everything because of cookies, when having cookies on the plain domain they are on every subdomain automatically, while having them on www. is exclusively for www.
- numlock86 7y agoI like your idea but it's based on false assumptions. See RFC6265. Depending on the implementation on the backend side (specifically the "Set-Cookie" header) it's possible to handle a cookie generated on "www.example.com" on "example.com" or "sub.example.com" ... and all other possible combinations. [1] https://tools.ietf.org/html/rfc6265 https://tools.ietf.org/html/rfc6265
- g105b 7y agoWith the correct configuration, www.example.com cookies do not leak over all subdomains, but it's impossible to configure example.com cookies to _not_ leak over all subdomains.
- colinsidoti 7y agoIf you omit the domain it shouldn't leak, though as with many things web it's browser-specific: https://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_path https://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_path
- uberswe 7y agowww is more secure to use than the root domain because of how cookies are set. Setting a cookie for the www subdomain ensures that it’s only available for that subdomain and not globally across all subdomains. It makes sense that sites that use www are generally more secure.
- robocat 7y agoNote that by default Google analytics puts the cookies on the root domain, and you need to change the JavaScript snippet to avoid that. Cloudflare also puts cookies on the root domain. I definitely agree though.
- numlock86 7y ago> www is more secure to use than the root domain because of how cookies are set. > Setting a cookie for the www subdomain ensures that it’s only available for that subdomain and not globally across all subdomains. No, www is not more secure because of cookies. As you said, it depends on how cookies are set, which is up to the host, as this is defined in the HTTP headers coming from the server. It's possible to access a cookie from "www.example.com" on "example.com" or "sub.example.com" if it's configured like that on the backend. Also the browser needs to comply. (Protip: most browsers do)
- snowwrestler 7y ago> It's possible to access a cookie from "www.example.com" on "example.com" or "sub.example.com" if it's configured like that on the backend. Ok but to my knowledge it is impossible to set a cookie on example.com and make it inaccessible to subdomain.example.com.
- type0 7y agoIt's not a bug, it's a feature /s
- megous 7y agoThat's not true at all. Try document.cookie = 'a=b' in a browser console on non-www domain and then do document.cookie on the www variant. You'll see it not set. (The cookie will only be accessible on subdomains if you include the domain explicitly, like document.cookie = 'a=b;domain=toplevel.domain')
- adrianmsmith 7y ago> Additionally, 24.71% of these redirections contains [...] HTTP intermediate URLs. One problem I've found is that if you have a redirect from HTTP to HTTPS, then you don't notice an extra redirect from HTTPS to HTTP (e.g. redirect from HTTPS plain domain to HTTP www, which then in the next request get upgraded from HTTP www to HTTPS www). Combine that with the fact that it is surprisingly difficult to prevent the AWS load balancer from redirecting from HTTPS to HTTP. Literally Apache, Nginx, Tomcat, Jetty all get it wrong out of the box. I had to write this blog post to prevent myself from getting it wrong in the future: https://www.databasesandlife.com/jetty-redirect-keep-https/ https://www.databasesandlife.com/jetty-redirect-keep-https/ The particular application I discovered that on did not accept HTTP traffic, so I discovered the extra redirect. Most people don't.
- TazeTSchnitzel 7y agoThere is thankfully HSTS and upgrade-insecure-requests, but they shouldn't be needed here…
- Avamander 7y ago> Literally Apache, Nginx, Tomcat, Jetty all get it wrong out of the box. Absolutely correct, it's surprisingly difficult to get a really good working configuration with no weird fallbacks or side effects and have working http2. I have five server blocks per domain name when using nginx, some are reusable though, here: * Port 80 with wrong domain - close connection, nothing legit does this * Port 80 with right (www. and .) domain - redirect to https:// https:// * Port 443 with no SNI - close connection, nothing legit does this * Port 443 with www. SNI (http2 enabled) - redirect * Port 443 with . SNI (http2 enabled) - display proper page Not surprisingly it tremendously cut down the amount of exploit scanners and bad bots from logs (they seem to rely on everyone not enforcing SNI) and managed to hide the server from Shodan :D. This is of course not to diss nginx, other servers e.g. caddy and apache were worse or even impossible to configure to the same point.
- zamadatix 7y agoIf you're just going to redirect www to . why not make it a CNAME instead of a hop?
- hannob 7y agoThis may be surprising to some people, but it's not a new pheonoema and I feel it's kinda known in TLS circles. Everyone who's done scans on TLS vulnerabilities should know this (speaking as one of the authors of the ROBOT attack). What's often going on is that the www domain is delegated via DNS to a thirdparty service provider, while the apex domain is hosted on some appliance and just does a simple redirect. The reason for that is that you can't do DNS delegation for an apex domain. During our ROBOT investigations we found a particularly weird example: We found a particularly severe variant of our vulnerability in old versions of Cisco ACE load balancers. Cisco told us that these were out of support, so they're not gonna get fixed. Turns out: they used one of them to redirect cisco.com to www.cisco.com.
- segfaultbuserr 7y agoAnother implication of this result is: even if the transport layer security appears to be secure, it's possible that it only indicates the CDN setup, and the actual upstream servers are insecure. Which means, a latest and greatest TLSv1.3 server you see may be ultimately backed by a vulnerable TLSv1.0 upstream server (or even unencrypted HTTP!). Great news for the NSA indeed!
- Jestar342 7y agoDisclaimer: Asking from a place of ignorance/naivity What does this mean for SSL termination? E.g. SSL terminates at cloudflare, internal (behind firewall) all http-sans-s?
- josteink 7y ago> Further analysis of the top domains dataset shows that 53.35% of the plain-domains that show one or more weakness indicators (e.g. expired certificate) that are not shown in their equivalent www-domains And Chrome still wants to fool the user into thinking these two domains are the same.[0] Great job, Google. [0] https://news.ycombinator.com/item?id=20626807 https://news.ycombinator.com/item?id=20626807
- chrisweekly 7y agoRelated tangent: use of a "www" CNAME provides a convenient safety net of sorts when it comes to mitigating DDoS attacks.
- vallismortis 7y agoI asked a question about this exact topic on Information Security over 4 years ago, which received very little attention but the one answer it received came to the same general conclusion (possibility of protocol differences): https://security.stackexchange.com/q/91717/78662 https://security.stackexchange.com/q/91717/78662 However, if these are hosted on the same server, there is a long-standing bug in Apache that forces the same protocol and cipher suite for all virtual hosts: https://serverfault.com/a/698478/293818 https://serverfault.com/a/698478/293818