Closed Acconut closed 5 days ago
The HSTS preload is an interesting comparison, but I suspect it ultimately fails because so many API accesses will be using bespoke clients. Certainly shipping something like this in curl
or Python requests
would make it harder to accidentally hit a plaintext API, but I'm dubious we'd get every HTTP client API to respect it or keep the list updated.
Further, I think the HSTS preload list is now semi-obsolete. The reason for having a preload list is to get the signal to the client before the client can make a plaintext HTTP request. There is now a more real-time method for doing that: HTTPS
records, among other things, tell the client about HSTS-like requirements during the DNS query stage, before any credentials are exposed.
I think one of our recommended mitigations should be that API endpoints publish HTTPS
records in the DNS, and that HTTP client libraries respect them, automatically switching to HTTPS endpoints unless explicitly instructed not to.
The HTTPS record is a useful tool, I agree. Thanks for sharing! All in all, there are a few recommendations we can make for the involved parties:
I wonder if it's also helpful to recommend intermediaries to forward insecure authenticated requests (instead of rejecting them early on), so that the target server can then properly invalidate the corresponding credentials.
I believe that #2 addresses the suggestions discussed here.
Thank you for setting up this draft, Rich! I will leave a few comments here, let me know if you prefer to discuss them somewhere else.
In their blog post, @jviide suggested to disable the port 80 for HTTP entirely for API usage. While this might work in some scenarios, it would not work for setups where for example a load balancer is shared between an API and website. HTTP-to-HTTPS redirects are still desired for the website and the hostname is not known before a connection is already established. Therefore, I would be hesitant to include closing the port as a recommendation here.
Rejecting unencrypted but authenticated requests and revoking the credentials is a good approach. But it also gives everybody, who has access to the credentials, the ability to revoke them by issuing an unencrypted requested, which might disrupt the service. While a service disruption is still preferable to the leakage of credentials, it might still be worth including as a caveat to make service operators aware.
I am also wondering how the client-side can protect themselves. A client cannot expect that every service rejects unencrypted requests and even revokes the credentials. Mistakes happen and one might want to prevent them. Proactive measures to avoid unencrypted requests include:
Browsers also have a HTTP Strict Transport Security (HSTS) preload list. If a website is on this list, browsers will only connect to it via HTTPS and not even attempt a first try using HTTP. Would a similar initiative for API clients make sense? As an API operator I could add my domain to this list and the HTTP client would immediately raise a meaningful error if my user tries to access my API using plain HTTP.