What is the proper HTTP response to send for requests that require SSL/TLS

Question

I'm designing an RESTful API where some calls are public over HTTP, and some require an API key and encryption over HTTPS. I'm deliberating on what response code should be sent if an HTTP request is sent to one of the private resources. So far the only one that jumps out at me is 412 - Precondition Failed, but the standard indicates that the precondition is imposed by the requester not the server.

Is there an appropriate response code for this condition or do I just need to give in and do 400?

Solution 1

The most secure way to force HTTP client to use HTTPS is HTTP Strict Transport Security.

Previously a common suggestion was to drop the connection, but this practice has been removed in favor of HSTS (OWASP website).

Solution 2

I cannot say if this is broadly accepted by HTTP clients, but speaking strictly RFC, the server should respond with:

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

Source:
https://www.rfc-editor.org/rfc/rfc2817#section-4.2

Solution 3

The appropriate error code to return would be similar to 403.4 - SSL required.

Although not explicitly documented in the RFC for HTTP 1.1, this behavior does match the requirements outlined there:

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

Adding your own subcode (as with the SSL example) might be helpful in some cases, but since this subcode would not be meaningful to third parties, I would recommend against it.

So, your final error message would be something like "403 - Private Resource". Note that, even in the case of a missing API key, "401 - Unauthorized" should not be used, unless your API key can actually be transmitted in a WWW-Authenticate header field.

Solution 4

Returning a 403 with reason phrase "HTTPS Required" seems like a practical option and what I use.

see https://en.wikipedia.org/wiki/HTTP_403

Redirecting a REST Api is not a good idea especially as you may have no idea as to how or what is consuming your service.

View more solutions

Comments

[Jan Algermissen]

Note that the IIS status codes are bogus. HTTP status codes are composed of numbers only (3 exactly). See w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1 Also note that the reason phrase for 403 is "Forbidden" and that this is not subject to modification. Any further explanation should go into the response body.

[Sripathi Krishnan]

There's a security risk. "An attacker performing a man in the middle attack could intercept the HTTP redirect response and send the user to an alternate page" - from OWASP SSL Best Practices

[gtd]

Yeah, as appealing as that subcode is I can't behind the non-standardized nature of it.

[Agoston Horvath]

That does not stop users from still referring to the http url, in fact, with most http clients they won't even see that an http redirect took place. Sweeping the problem under the rug is probably not the approach you want to take.

[Jan Algermissen]

Yes, sorry. You guys are right. Sending a redirect is the wrong thing to do. Thanks for pointing that out.

[prashant]

1. The HSTS draft has been moved to the IETF. 2. reading it does not actually give a good answer to the OP's question.

[Chris H.]

I agree with other commenters that a subcode should not be used, but a case could be made for a plain 403. For example, that's what Twitter is using for their API. See dev.twitter.com/docs/security/using-ssl

[Fred]

HSTS enforces HTTPS on the <b>entire</b> site. The above poster wanted some resource to be available over HTTP while others only over HTTPS. So HSTS cannot be used since it applies for all resources.

[BadZen]

This doesn't answer the OP's question. He was asking about what to do when a client connects over http, not HSTS headers which only have effect when the user has already connected over https.