Slashdot Mirror

Just like every homeowner is expected to buy connectivity and addressing from their isp?

And when smartphones were new, a lot of people were reluctant to buy a cellular data plan because they were already buying connectivity from their home ISP. Some householders just don't want yet another perpetual utility bill, which means yet another company dipping into the family's checking account and potentially exposing said account to accidental or fraudulent withdrawals that cause overdrafts.

if you're content to use the same domain as thousands of others then there are many free options

You mean free dynamic DNS? One drawback of this has been that Let's Encrypt issues only 20 certificates per registrable domain per week. The dynamic DNS provider has to apply to Mozilla for inclusion on the Public Suffix List, which is administered on a Microsoft-run website. Some are unwilling, and last I checked, others' applications were in a months-long backlog.

and nothing to stop the isp from allocating a subdomain to their customers.

Of course there is: The major last mile ISPs have a business policy not to let home users run servers in the first place. I concede that ISPs have power to amend this policy, but you'd have to show ISPs a good case for amending this policy, as upgrades to more expensive business-class service make them money.

Plus there is always .local and llmnr/mdns if you don't need global reachability of your hostnames.

Neither Let's Encrypt nor any other trusted-by-default HTTPS certificate authority does .local. It violates the CAB Forum's Baseline Requirements.

The web browser caches resources delivered through HTTPS the same way as resources delivered through cleartext HTTP. The only thing you lose is being able to cache on an intermediate proxy, but that is relevant if you're splitting one dial-up connection among multiple clients.

Then there is the issue of small timers who want to serve a web page from home, using an old computer and dynamic hostname.

File a support ticket with your dynamic DNS provider to request addition to the Public Suffix List. If a dynamic DNS provider is on the Public Suffix List, Let's Encrypt issues 20 certificates per customer per week instead of 20 per provider per week. The other benefit of being on the PSL is that sites on the same dynamic DNS provider can't see each others' cookies.

So if someone can come up with a characteristic specific to tracking, I can block only those pages and allow the ads that support my favorite web sites.

A site with ads but no tracking will have its own store front where advertisers can buy ad space. This process doesn't need to place third-party cookies or images on viewers' devices. Therefore, to block tracking, block the loading of resources from unaffiliated domains. Use the Public Suffix List to find which hostnames are part of the same domain, and add cookieless domains used for static resources to a whitelist if they're obviously operated by the same publisher. Yes, this breaks CDNs used to deliver widely used script frameworks, such as jQuery, but a lot of tracking haters on Slashdot also seem to think script in the browser should never have existed anyway.

There are quite a few free subdomain providers out there too, usually offering dyndns options and the like.

The problem is that a lot of these free subdomain providers aren't listed on the Public Suffix List. For example, afraid.org is not. And if a domain isn't on the Public Suffix List, Let's Encrypt issues no more than 20 certificates per week for that domain. This means 20 other users of that same domain will probably have already obtained their certificates before you, causing Let's Encrypt to reject your attempt to obtain a certificate with an error message to the effect:

Error: rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: no-ip.biz

So it appears to be either A. use Let's Encrypt for the certificate and pay for the domain or B. use a free subdomain provider for the domain and pay Namecheap for the certificate.

You don't need to own a domain for Let's encrypt; controlling a subdomain is enough.

Only if the subdomain is a subdomain of a domain in the Public Suffix List. Let's Encrypt limits how many certificates may be issued per domain per 7 days:

The main limit is Certificates per Registered Domain, (20 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name www.example.com, the registered domain is example.com. In new.blog.example.co.uk, the registered domain is example.co.uk. We use the Public Suffix List to calculate the registered domain.

Because afraid.org is not in the Public Suffix List, no more than 20 certificates for subdomains of afraid.org will be issued in one week.

You don't need to own a domain for Let's encrypt; controlling a subdomain is enough.

Only if the subdomain is a subdomain of a domain in the Public Suffix List. Let's Encrypt limits how many certificates may be issued per domain per 7 days:

The main limit is Certificates per Registered Domain, (20 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name www.example.com, the registered domain is example.com. In new.blog.example.co.uk, the registered domain is example.co.uk. We use the Public Suffix List to calculate the registered domain.

Because afraid.org is not in the Public Suffix List, no more than 20 certificates for subdomains of afraid.org will be issued in one week.

SSL is now completely free via let's encrypt.

Let's Encrypt requires a fully qualified domain name (FQDN) under a well-known top-level domain (TLD), not an IP address in RFC 1918 space or a name under a made-up TLD such as .local or .internal. So do all other CAs whose root certificates are included in Mozilla NSS, as a FQDN is one of the Baseline Requirements adopted by the CA/Browser Forum.

Domains are cheap.

Cheap enough for every head of household to buy and to continue to renew in perpetuity? Because buying a domain is the only way to get a certificate for hosts on your LAN that visitors' devices will trust, and a certificate is the only way you're going to satisfy the "Secure Contexts" requirement for recently introduced JavaScript APIs.

Free ones are available.

Namely?

If you're referring to subdomains offered by dynamic DNS providers, these providers have to be on Mozilla's Public Suffix List (PSL). If a domain isn't already on the PSL, and 20 other users of subdomains under the same domain have obtained certificates in the past week, Let's Encrypt will deny you a certificate, citing its rate limit policy. If a domain is on the PSL, each subdomain gets its own separate rate limiting bucket of 20 certificates per subdomain per week. In addition, submissions to the PSL must be made by the dynamic DNS provider as a pull request through GitHub.com, and use of GitHub.com requires running proprietary software written in JavaScript on your computer.

Until ICANN requires those offering registrable subdomains of a domain registered in one of its gTLDs to pass the identity requirement through to their subscribers or risk getting kicked out of Mozilla's Public Suffix List and comparable lists within the ICANN-controlled .org gTLD. If your domain leaves the PSL, your subscribers won't have their cookies separated, nor will they be eligible for a healthy number of domain-validated TLS certificates from ACME CAs such as Let's Encrypt (source).

The only time this could lead to confusion would be if you own a domain for which you have multiple subdomains with certificates signed by different authorities, which probably doesn't (or shouldn't) happen.

And if it does happen, your domain probably is a public suffix.

If a website allows scripts to be placed on their pages from unknown parties without even looking at the scripts, then it's going to invite malware.
I trust Yahoo.com to not write malware on their own pages

Implicit in this is a policy of rejecting scripts and the like that are hotlinked from a different website. But how would a browser determine whether a request belongs to "a different website"? You can't just go by whether the public suffix matches, especially when a site serves its own static resources from its CDN on a different, cookieless domain.

A surprising number of things are starting to rely on these curated lists to handle "most" cases. The valid-key flip-side of this key blocklist is the public-key pinning list, which is also pretty half-assed.

With a different (non-crypto) bit of web technology, there's also the mess of how to determine what the "real" domain of a site controlled by an entity is. E.g. in the UK, a domain like example.co.uk is a third-level domain, but is conventionally treated as domain 'example' with suffix '.co.uk', not as domain 'co' in TLD 'uk', and subdomain 'example'. Whereas in dot-com, a domain like foo.example.com would be treated as domain 'example' in TLD 'com', with subdomain 'foo'. How to tell which is which? Yes, some human maintains a giant list, which browsers all build in.

The public suffix list will need revision, I suppose.

thing is, the advertisers will never do that - simply because their business model relies on tracking impressions and so forth. Hence they have to serve the ads on their own web platforms.

Then each publisher (operator of a web site that includes ads) could make a subdomain that is a CNAME (DNS-based alias) pointing at the ad server. In this way, the ad server will share the same public suffix as the rest of the publisher's site. So how will your browser be able to tell it from a subdomain that's actually operated by the publisher?

Assuming that wasn't sarcastic, one would define "site's name" in terms of the last part of the hostname before a public suffix. For example, in "it.slashdot.org", the public suffix is "org", and the part before that is "slashdot", giving "sla" as the site name.

dig @a.gtld-servers.net example.com in soa

If you don't get NXDOMAIN then it's registered.

What about detecting domains that have just expired, but haven't been removed yet? And not just for .com but for other TLDs (and second-level domains as appropriate, see http://publicsuffix.org/) as well.

That's what highlighting the domain (the public suffix and the hostname element before it) is for. If the domain is the same as the domain printed on the back of your credit or debit card, and the organization name and address in the EV SSL certificate match those of the bank, then you're probably connecting to your bank.