If you are paying the cost of a TLS handshake, which you will have to anyway, why not just use client certificates to authenticate (mTLS) instead of hand rolled and rudimentary auth tokens on top. gRPC has built-in support for mTLS and it could be a good time to modernize your endpoints if you are looking to invest time to improve your API security.
API Shouldn't Redirect HTTP to HTTPS
211–220 of 310 posts
Re: API Shouldn't Redirect HTTP to HTTPS
#212Earlier quoted context omitted.
If you're serving web traffic and API traffic on the same domain, which many services are, then not listening on port 80 may not be possible. Even if you do use a different domain, if you're behind a CDN then you probably can't avoid an open port 80. I do keep port 80 closed for those of my services I can do so for, but I don't have anything else that needs port 80 to be open on those IPs. I think Stack Exchange's so…
I always thought it was bad practice to use the same domain for API and non-API traffic. In the browser there'll be a ton of wasted context (cookies) attached to the API request that isn't needed. So it's better to have "api.example.com" and "www.example.com" kept separate, rather than using "www.example.com/api/", where API requests will have inflated headers.
What matters is that there is nothing listening on port 80 on the same IP address. That may be hard to control if you are using an environment with shared ingress.
Re: API Shouldn't Redirect HTTP to HTTPS
#213Great article! We've updated the OpenAI API to 403 on HTTP requests instead of redirecting. $ curl http://api.openai.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 123" \ -d '{}' { "error": { "type": "invalid_request_error", "code": "http_unsupported", "message": "The OpenAI API is only accessible over HTTPS. Ensure the URL starts with 'https://' and not 'http://'.", "param"…
Why not just stop listening on port 80, period?
Because the whole point is a mitm can compromise it, and the mitm can listen on 80 regardless if you turn yours off.
Re: API Shouldn't Redirect HTTP to HTTPS
#214The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.
The client-side library should disable HTTP by default to ensure that raw data never leaves the local environment, thereby avoiding any leakage.
Re: API Shouldn't Redirect HTTP to HTTPS
#215My personal website (darigo.su) doesn't have HTTPS. I just deployed it a few months ago and haven't really done much with it yet. I guess I'll have to get around to it eventually, but I find charm in small old sites that haven't implemented modern protocol stuff. My site also uses and tags all over the place. Maybe I'll do some more quirky anachronisms, like only serve the site via HTTP 1.0 or something. Who knows. S…
I see this a lot. You've just made a small non-interactive site, and there's nothing secret. So why bother either https? Well, firstly, I'd say, make ot https for fun. It's pretty simple to do, makes itself automatic, and costs no money. Just exploring this route can be very illuminating. Secondly it prevents your site from being altered by the outside. There's a lot of equipment between your site and the client. Bei…
Honestly, hard disagree. I get the push for HTTPS, but setting up HTTPS nowadays isn't fun. It's more or less 4 steps;
1. Install and run certbot (+the DNS plugin for your DNS provider).
2. Find an nginx config file on the internet that only includes the necessary ciphers to work on modern devices. Then include that config file + lines to your cert paths that certbot spits out into your nginx config.
3. Set up a generic redirect server block to send everything on port 80 to port 443.
4. Reboot nginx.
It's at least better than fiddling with openssl directly, but this isn't fun, it's busywork.
Re: API Shouldn't Redirect HTTP to HTTPS
#216Earlier quoted context omitted.
that's more secure, but still not bulletproof: A MITM (e.g. a router along a multi-hop route between the victim client and StackExchange) could silently drop the unsafe HTTP requests and maliciously repackage it as an HTTPS request, thereby circumventing the revocation. Also: even if an insecure HTTP request isn't dropped / makes it through to StackExchange's endpoint eventually (and thereby triggering the API key re…
There's absolutely nothing you can do to prevent an active MITM attack over HTTP
I think the CONNECT proxy protocol carrying TLS over HTTP/1 is a counterexample.
ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CO...
Re: API Shouldn't Redirect HTTP to HTTPS
#217npm is misusing 426 Upgrade Required. https://httpwg.org/specs/rfc9110.html#status.426 : > The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s) (Section 7.8). https://httpwg.org/specs/rfc9110.html#field.upgrade : > The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch the underlying connection (transpo…
TLS is in fact a valid protocol to use in an Upgrade header: HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade So you can use 426 Upgrade Required here, and I'd argue it's the most correct code to use in such a case. npm doesn't send the Upgrade header though, so that's a mistake. https://www.iana.org/assignments/http-upgrade-tokens/http-up... https://www.rfc-editor.org/rfc/rfc2817.html#sec…
That’s something different: that’s for upgrading to TLS within the same connection. As in, approximately http://example.com/ → https://example.com:80/ (but without the URL’s scheme actually being allowed to change), whereas https://example.com/ is https://example.com:443/. I was only a child when RFC 2817 was published, but I’ve never heard of any software that supported it, other than the Internet Printing Protocol which can use it for ipp: URLs, kinda like SMTP has STARTTLS. As for the motivations of RFC 2817, they’re long obsolete: encryption should no longer be optional on these sorts of things so that the parallel secure port problem is gone (not sure when this became actual IETF policy, but I’m going to guess towards ten years ago), and the virtual hosting problem is solved by SNI (supported by everything that matters for well over a decade).
Re: API Shouldn't Redirect HTTP to HTTPS
#218The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.
that's more secure, but still not bulletproof: A MITM (e.g. a router along a multi-hop route between the victim client and StackExchange) could silently drop the unsafe HTTP requests and maliciously repackage it as an HTTPS request, thereby circumventing the revocation. Also: even if an insecure HTTP request isn't dropped / makes it through to StackExchange's endpoint eventually (and thereby triggering the API key re…
> that's more secure, but still not bulletproof
Re: API Shouldn't Redirect HTTP to HTTPS
#219Earlier quoted context omitted.
that's more secure, but still not bulletproof: A MITM (e.g. a router along a multi-hop route between the victim client and StackExchange) could silently drop the unsafe HTTP requests and maliciously repackage it as an HTTPS request, thereby circumventing the revocation. Also: even if an insecure HTTP request isn't dropped / makes it through to StackExchange's endpoint eventually (and thereby triggering the API key re…
> that's more secure, but still not bulletproof I've never heard of bulletproof ever actually being achieved in IT security. Not even air gaps.
You tend to only hear about the systems where security was successfully broken, not the systems nobody managed to penetrate.
Re: API Shouldn't Redirect HTTP to HTTPS
#220[deleted]