Comments

[Acconut]

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:

• Blocking outgoing traffic to TCP port 80 (if the client also controls the firewall)
• Configuring the HTTP client to only allow HTTPS connections

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.

[MikeBishop]

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.

[Acconut]

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:

• for API consumers:
  • configure client library to disable HTTP altogether or at least respect HTTPS record
  • configure firewall to disallow outgoing traffic on default HTTP port
• for client libraries
  • provide option to disable insecure HTTP requests
  • respect HTTPS record (either by default or via option)
• for service providers
  • reject insecure authenticated requests and invalidate involved credentials

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.

[MikeBishop]

I believe that #2 addresses the suggestions discussed here.