This is a mini-rant, a short essay refuting a common misconception among users of an Internet forum. If you think this essay is FUD, feel free to explain why on the essay's talk page.
As of 2016, certain major web browser publishers such as Mozilla[1] and Google have announced plans to make sensitive JavaScript APIs available only within sites that use HTTPS, not cleartext HTTP, as a way of encouraging more sites to implement HTTPS. This makes life more difficult for operators of a home LAN who run a private internal web server.
Contents
Secure Contexts
The W3C's Secure Contexts spec defines a "secure context" roughly as a document all of whose markup and scripts come from a "potentially trustworthy origin". In turn, a "potentially trustworthy origin" is any of these:
- An origin using an authenticated scheme (
https:orwss:) - An origin on the local computer using IP addresses in
127/8(IPv4) or::1/128(IPv6) - An origin on the local computer using a scheme that the browser considers authenticated (
file:and possibly packaged browser extensions) - An origin that the user has "configured as a trustworthy origin", through a user interface that has not been specified
In particular, this does not include local area networks using private address space as described in RFC 1918 (10/8, 172.16/12, or 192.168/16).
This means that by default, a browser will treat a server on the local area network (LAN) in your home no differently from a random PC connected to a public Wi-Fi hotspot in a restaurant.
So until user agents[2] provide a way to mark an origin as "configured as a trustworthy origin", the only way to make a computer other than the local computer trusted is to implement HTTPS.
Certificate
HTTPS is built on Transport Layer Security (TLS), which associates a public key with a server using an X.509 certificate whose subject alternate name (SAN) matches the server's hostname.
The certificate is issued and digitally signed by a certificate authority (CA) that the device trusts.
In order to gain the trust of device makers and web browser publishers, a CA must show evidence that it follows the practices described in the Baseline Requirements (BR) published by the CA/Browser Forum.
The BR require the hostname in a certificate to be a fully-qualified domain name (FQDN), not a private IP address or a made-up top-level domain (TLD), such as .local or .internal.
The practicality of providing a name for a server depends on several factors: whether it is reachable through the Internet or only a LAN, whether it is a production or testing server, and whether the server's owner is experienced in information technology (IT) or a novice in a home environment. I'll explore several common scenarios:
For a server reachable through the Internet, the requirement of a FQDN poses little trouble, even hobbyists, as the owner of a domain can obtain certificates for plenty of machines that it operates in that domain through the Let's Encrypt CA.
If a registrar's bundled zone hosting makes it difficult to change TXT records quickly, a domain owner could point the NS record for the _acme-challenge subdomain at a specialized nameserver used only for certificate renewals.[1]
A production server on a corporate LAN is managed by IT professionals. The administrator can put the server on a subdomain of a corporate-owned domain and use split-horizon DNS to show some records to the general public (including the CA) and other records only to the internal network. This has the side effect of disclosing internal server hostnames through DNS and Certificate Transparency.
For a testing server on a developer's LAN, it's often enough to operate a private CA using free software such as OpenSSL. The developer can then give the test server a private name, use split-horizon DNS to make this name resolve internally, issue a certificate for that name to the test server, and deploy the private CA's root certificate on all client devices used for internal testing. In a Tweet in July 2021, Twilight Sparkle (@yourcompanionai) recommended FiloSottile's mkcert, a tool written in Go to run a private CA on a computer running Windows, macOS, or GNU/Linux, trust it in many web browsers, issue website certificates, and export a root certificate to import into mobile devices. A business can also use this method to avoid publishing internal hostnames at the expense of making access more tedious for employees who bring their own device (BYOD). However, this method does not work as reliably for Android 7 "Nougat" and later, as applications no longer trust user-installed CAs without explicitly opting in through the manifest.[3] Though Google Chrome opts in,[4] not all other browsers for Android do.[5]
Names for home LAN hosts
The toughest problem is internal production servers for guests and other inexperienced users. Some web applications are intended for use by those people who happen to be authorized to connect to a particular private network at any given time. This may include a network gateway appliance (or "router") for administration of a home network and its connection to a home ISP, a printer or network attached storage (NAS) server for friends and family visiting a home, or a server at a museum that allows its guests to interact.[6] Requiring these non-technical users to trust a private CA isn't practical for production use. Mozilla acknowledges unavailability of a certificate from a public CA when "a device doesn't have a globally unique name" as a problem but has put off solving it.[1]
To work around the lack of PKI for the Internet of Things, it was suggested to install a private root certificate on a smartphone somehow using NFC or QR codes,[7] but this hasn't yet been deployed.
One might try obtaining a globally unique name from a general-purpose dynamic DNS provider.
Many of these providers offer registration of a subdomain within the provider's domain at no charge.
A provider at dyn.example might let a user register abc.dyn.example.
But not all such providers allow users to add the TXT or NS record needed to fulfill the ACME DNS challenge.
Many support only A records (and AAAA if you're lucky).
Nor do all home ISPs allow the port forwarding needed to fulfill the ACME HTTP challenge, especially home ISPs in countries with too few IPv4 addresses to go around that make do by putting customers behind carrier-grade NAT.
For example, ISPs in Myanmar reportedly use CGNAT for all residential customers, allowing only business subscribers to lease dedicated IP addresses, and allowing only businesses to subscribe to business service.
(And some CGNAT fans think this is fine.[8])
Myanmar didn't get IPv6 until July 2019; by June 2020, Mytel's IPv6 launch brought IPv6 share usage in Myanmar to 14%.[9]
Or one might try obtaining a globally unique name from a dynamic DNS provider operated by the manufacturer of a router, printer, or NAS. Plex resells DigiCert certificates for use in its streaming application.[10] But this is a recipe for planned obsolescence once the appliance's warranty expires. HP, for example, is known to remotely disable its printers' ink cartridges once a subscription expires[11] and would probably do the same for dynamic DNS and a TLS certificate. It also does not apply to homemade devices, such as a home-built NAS or a desktop or laptop PC running free media server software.
In addition, Let's Encrypt doesn't know about all subdomain registrars.
LE's ordinary policy is to issue only 20 certificates per registrable domain per week,[12] which is far too low for a dynamic DNS provider with substantial traffic.
For example, only 20 certificates per week may be issued for subdomains of dyn.example,
and subdomain registrants beyond that have to retry obtaining a certificate at random intervals for upwards of two days, as an anonymous commenter on Slashdot suggested.
But if dyn.example is on Mozilla's Public Suffix List (PSL), this makes abc.dyn.example a registrable domain because it has exactly one more label than a public suffix, this label being abc.[13]
Being a registrable domain has two main consequences: cookies set on abc.dyn.example won't be visible from sites hosted on other subdomains such as xyz.dyn.example, and Let's Encrypt will allow up to 20 certificates per week within abc.dyn.example itself.
Even before Let's Encrypt became available, subdomain registrars could have added themselves to the PSL so that a site run by one subscriber can't see cookies set by another subscriber's site.
But the use of the PSL by Let's Encrypt for rate limiting greatly expanded awareness of the PSL among subdomain registrars.
This has led to a huge backlog for dynamic DNS providers to get onto the PSL.[14]
(In mid-2017, someone claimed that PSL may finally be catching up.[15])
As of mid-2018, DuckDNS appears to support TXT and the Public Suffix List.[16][17]
But until PSL inclusion and TXT record support are a given for other major subdomain registrars, each operator of a private server open to LAN visitors must purchase his own domain name, and if an application ends up installed on a million home servers, that makes a million domains that have to be purchased and renewed annually.
But some people, such as gravewax and silanea at Slashdot, believe every head of household on the Internet ought to own a personal domain, that keeping it renewed is just as much an expected recurring expense of Internet use as electric power.
So do members of the IndieWeb community.[18]
Householders will end up having to learn how to hunt for low rates and trick the registrar into offering a renewal promotion.
In some cases, the operator of a service will run a dynamic DNS provider on behalf of the service's subscribers.
One service using this approach is the Rainway video game streaming platform, which operates cya.gg.[19]
But a practical problem with that is delay in getting a newly established provider added to the PSL, or the cost of running a provider in the first place if you are a free software project without outside funding.
Another problem prior to 2018 was that Let's Encrypt did not issue wildcard certificates.[20] This caused problems for users of software that follows a security model like that of the Sandstorm productivity suite, which uses a wildcard DNS record and generates a new random subdomain for each new user session as a means of thwarting cross-site attacks. Though users of Sandstorm itself can use the Sandcats.io CA, other self-hosted free software projects may not have that luxury.
See also this wrap-up comment on SoylentNews.
Use cases
The administration interface for an Internet gateway appliance, also called a home router, presents username and password fields.
This is commonly accessed by navigation to the IP address, such as http://192.168.1.1.
But because the scheme is not https and private IPs are not localhost, both Chrome and Firefox show a warning that the user is entering a password into an insecure form.
The Presentation API allows a web application to display its output in an external monitor. This is useful for showing video on a TV while controlling playback from a PC or smartphone. But in Chrome 61 and later, the Presentation API requires HTTPS.[21] So does any subresource transcluded by an HTML document delivered through HTTPS. This means a home network-attached storage (NAS) appliance cannot use the HTTP protocol to present images, videos, or other media stored on the appliance's drives through the Presentation API.
To avoid warnings and missing JavaScript functionality, the internal server must use HTTPS, which requires the user to buy a domain name and configure DNS for the domain name so that the NAS can obtain the appropriate certificate from Let's Encrypt. This imposes a recurring monetary cost and may prove too challenging for non-technical users.
The HTTPS in Local Network Community Group was launched in 2017 to explore solutions to these use cases,[22] but its chairs have published no reports as of July 2020.
Means of validation
A certificate authority can determine whether a particular customer qualifies for a domain-validated certificate in one of three ways. Not all CAs support all methods.
- Sending a challenge value through SMTP to a well-known administrative address at that domain, such as
hostmaster@example.com,postmaster@example.com, orwebmaster@example.com, and having the user paste the value into a web form at the CA. - Having the customer place a particular challenge value in the web root of a publicly visible HTTP server on that hostname, and reading it back from that server.
- Having the customer place a particular challenge value in a
TXTrecord for the server's hostname in its DNS zone, and reading it back from DNS several minutes later, once the old value has expired from intermediate DNS caches.
As of 2017, Let's Encrypt supports the HTTP and DNS methods, not the mail method.
But because an internal web server is not publicly visible, only the DNS method will work.
This means the operator of a LAN will have to choose a dynamic DNS provider that both is on the PSL and allows prompt updates to a hostname's TXT record.
References
- ↑ 1.0 1.1 "Deprecating Non-Secure HTTP: Frequently Asked Questions". Mozilla, 2015-05. Accessed 2016-08-12.
- ↑ "Web Content Accessibility Guidelines 1.0". W3C, 1999-05-05. Accessed 2017-07-10.
- ↑ "Add & remove certificates". Accessed 2017-04-18.
- ↑ "[https://chromium.googlesource.com/chromium/src.git/+/lkcr/chrome/android/java/res/xml/network_security_config.xml chrome/android/java/res/xml/network_security_config.xml". Git at Google, 2016-06-10. Accessed 2017-10-23.
- ↑ ameshkov et al. "Browsers with no network security configuration #1304". AdguardForAndroid Issues, 2017-06-29. Accessed 2017-10-23.
- ↑ greggman's question
- ↑ Minutes of a W3C meeting. W3C, 2015-10.
- ↑ ILostMyBeaver
- ↑ David Dawson. "Mytel launches IPv6 in Myanmar". APNIC Blog, 2020-06-25. Accessed 2020-07-22.
- ↑ Filippo Valsorda. "How Plex is doing HTTPS for all its users". 2016-06-06. Accessed 2020-01-20.
- ↑ Tweet by Ryan Sullivan on 2020-01-17
- ↑ "Rate Limits". Let's Encrypt. Accessed 2016-08-12.
- ↑ "View the Public Suffix List". Mozilla. Accessed 2016-09-16.
- ↑ Public Suffix List issue #236. GitHub, 2016-06-15. Accessed 2016-09-16.
- ↑ Tweet by Hector Martin on 2017-06-11
- ↑ Paulus Schoutsen. "Effortless encryption with Let's Encrypt and DuckDNS". Home Assistant, 2017-09-27. Accessed 2018-07-25.
- ↑ Andreas Gohr. "HASS, DuckDNS and Let's Encrypt". Splitbrain.org, 2017-08-10. Accessed 2018-07-25.
- ↑ "personal domain" Accessed 2018-01-03.
- ↑ Andrew Sampson. "Encryption For All". Rainway, 2018-06-25. Accessed 2018-08-31.
- ↑ Josh Aas. "Wildcard Certificates Coming January 2018". Let's Encrypt, 2017-07-06. Accessed 2017-07-06.
- ↑ Joseph Medley. "Deprecations and Removals in Chrome 61".
- ↑ History of "TPAC2016/session-https-local-summary". W3C Wiki, 2017-03-02. Accessed 2020-07-22.
External links
Categories: Computer security, Mini-rants