More than 10 years ago, a first RFC was published describing the ".well-known" directory for web servers. The idea is pretty simple: Provide a standard location for files that are mostly intended for signaling and automatic retrieval. Before the introduction of .well-known, these files often ended up litering the document root, like for example robots.txt being probably the most popular example. Currently, .well-known is defined by RFC8615 [https://tools.ietf.org/html/rfc8615] . 

Over the years, a number of locations were added to .well-known. You can find the authoritative list at IANA [https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml] and I would like to highlight a few of them here:

• acme-challenges

This is likely the most "famous" .well-known location. This directory is used by clients speaking the "ACME" protocol to leave challenges as they are retrieving TLS certificates from services like Let's Encrypt. Your ACME client (e.g. certbot or acme.sh) will drop files in this location. You will not manage these files yourself typically.

• change-password

Oddly not listed at the IANA site, but already implemented in Safari and some large web sites. This URL will redirect to a page that will allow users to change their password. The feature, at least as implemented in Safari, does not appear terribly useful. Only if you change your password using Safari's built in password manager ("Keychain"), will you have the option to be redirected to the "change password" page. But this feature is particularly meant for password managers. I played a bit with it, and find it doesn't work well as you typically need to log in first before changing your password.

• dnt / dnt-policy.txt

A place to leave a privacy polity (DNT = Do Not Track). There are fairly detailed standards describing how to implemented various policies. There are machine and human readable versions of the policy. This feature was a bit designed around the European GDPR rules.

• mta-sts.txt

This file describes the STARTTLS policy for a particular domain. A DNS record will alert a mail server that supports the feature of the policy. The policy will describe which mail servers are covered by it, and what encryption to expect. This feature is supposed to reduce the risk of MitM attacks being used to strip the STARTTLS headers.

• security.txt

A security contact for a particular domain (this is currently a draft, and the URL is not yet listed with IANA). We talked about this in a recent diary. The main goal is to make it easier for researchers to notify a website's owner of vulnerabilities.

• sshfp

Lists SSH server fingerprints. This is a bit interesting but also dangerous. You could end up publishing a great resource for attackers by giving them nice fodder for recognizance. But it is also an ongoing issue that it is difficult to distribute public SSH keys for servers, and they are often not verified correctly by users.

So what's your favorite ".well-known" feature that may not be so well known?

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|