Issuing SSL Certificates for any FastMail.com subdomain

While playing around with my .au domain database, I noticed some entries under fastmail.com.au come up (like obrien.obrien.fastmail.com.au).

This got me thinking. FastMail allow users to reserve subdomains for file hosting on any of their many white-label domains, first come first served. It generally takes the form of:

username@domain.tld provides website hosting at http://username.domain.tld, should the user opt-into it.

Next step? Issue an SSL certificate using Let’s Encrypt’s http-01 challenge.

The result: An SSL certificate issued for helpdesk.fastmail.com.au (revoked a short time later).

I reported this issue to bugreport@fastmail.com, suggesting to make use of CAA records to control issuance. To their credit they responded very quickly, but largely do not consider it an issue:

Thanks for writing to us. There are many fastmail.tlds we don’t own and could be registered for phishing. Anything appearing on one we actually own is much easier for us to shut down and determine who visited! In practice, this doesn’t happen.

We only tell users to trust fastmail.com for logging in, and to look for the EV cert. This is the only domain we use for our interface, and is the only domain we don’t allow user content to appear on (it gets redirected to usercontent.fm/…).

Getting the SSL certificate for a subdomain of one of our alternate domains is pretty irrelevant. You can’t currently use it, because you don’t control the machines hosting those IPs; we do. And we are planning to move all user hosting to HTTPS soon ourselves so soon we’ll generate the certificate for you!

– bugreport@fastmail.com

It’s fair enough that phishing attacks are too hard to control.

That said, one claim they make here is not exactly true (“fastmail.com” … “the only domain we don’t allow user content to appear on”). Their protection in this case is an HTTP redirect to a safer domain, but Let’s Encrypt will follow HTTP redirects to other authorities/origins without failing the authorization:

$ curl -i http://phishing123.fastmail.com/.well-known/acme-challenge/example
HTTP/1.1 301 Moved Permanently
Location: http://phishing123.fastmail.com.user.fm/.well-known/acme-challenge/example

$ openssl x509 -in phishing123.fastmail.com.pem -noout -text | ag CN=
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Subject: CN=phishing123.fastmail.com    

After having shown that the primary fastmail.com domain is not immune, they have taken action to block the /.well-known/acme-challenge path:

This would have been fixed in a few weeks anyway when we move all the hosted websites to HTTPS, as we are using this method to generate the certs with Let’s Encrypt ourselves and already have code in place to intercept /.well-known/acme-challenge/ for this! However, we might as well block this immediately.

– bugreport@fastmail.com

Not an ideal fix, since there are multiple other CAs that support HTTP-validation on other paths 🤔. Combining this with CAA would help with that.