Hindsight is 20/20. As seen in the post, there’s not that many APIs that don’t just blindly redirect HTTP to HTTPS since it’s sort of the default web server behaviour nowadays.
Probably a non-issue in most cases since the URLs are usually set by developers but of course mistakes happen and it absolutely makes sense to not redirect HTTP for APIs and even invalidate any token used over HTTP.
This is why most http clients don’t follow redirects by default.
v9CYKjLeia10dZpz88iU@programming.dev
on 29 May 16:26
nextcollapse
I disagree.
You shouldn’t serve anything over http. (The article argues that there’s risk of leaking user data) Whatever you’re using for a webserver should always catch it. A 301/308 redirect is also cached by browsers, so if the mistake is made again, the browser will correct it itself.
If you make it fail, you’re just going to result in user confusion. Did they visit the right website? Is their internet down? etc.
This article isn’t about browsers or websites, and even acknowledges in the opening that it makes sense as a usability tradeoff in that context.
v9CYKjLeia10dZpz88iU@programming.dev
on 29 May 16:38
collapse
I clearly didn’t read it. It makes sense, if users aren’t visiting the API then it really doesn’t matter that it’s not redirected on insecure connections.
pinchcramp@lemmy.dbzer0.com
on 30 May 08:12
collapse
I clearly didn’t read it.
I love the honesty. It’s really refreshing to see someone take accountability instead of becoming defensive.
I’d like to mention one exception, because it took me ages to properly debug.
If your endpoint is serving mirrors for APT, don’t redirect to HTTPS.
APT packages are signed and validated, so there is no need to use TLS. Lot of docker images (such as Kali) do not have root certificates by default, so they can’t use the TLS, because cert validation fails. You also can’t install the certificates, because they install through APT. If your local mirror redirects to https by default, it will break it for people who choose the mirror, which IIRC happens automatically based on what’s closest to you. I think this issue is still there for Czech Kali package mirror, and it took me so long to figure out (because it’s also not an issue for most of the users, since they have different mirrors), so I like mentioning this when talking http/s. It’s an edge case, but one that I find interresting - mostly because it would never occur to me that this can be an issue, when setting up a mirror.
But that was more than a year ago, it may be better now.
nickwitha_k@lemmy.sdf.org
on 29 May 21:42
nextcollapse
I’ve taken to just using HTTPS only. No redirect. Just an error.
Deebster@programming.dev
on 30 May 08:44
nextcollapse
It’s interesting that the author and most others went with 403, when 426 seems to be the most appropriate.
Neither are perfect matches, since 403 is about authentication and 426 is for Upgrade semantics (i.e. the upgrade is over the same transport protocol, not switching from http to https). npm isn’t sending an Upgrade header, which is required, but I think if it sent Upgrade: TLS/1.0, HTTP/1.1 then that would be claiming they supported TLS on port 80 (STARTTLS style) - possible but unconventional.
When selfhosting stuff, it’s just incredibly difficult to properly set this up while maintaining compatibility with http for other stuff. Usually you’ll have one reverse proxy (eg. nginx) handling http/https encryption and forwarding to a socket (or in case of docker, one of a dozen open ports on one of a hundred interfaces, fuck you docker), over http. The APIs themselves almost never have direct https support, and even if I wanted to manage them directly, certbot only supports reverse proxies directly. So you need to differentiate between api and non-api in the reverse proxy.
This. I was reading through some of the comments, but this is the most accurate one I’ve read thus far. All the APIs I’ve dealt with are just vanilla HTTP and use a reverse proxy for https. A reverse proxy like nginx is also convenient for path pattern matching to different API services but only having to setup https in one spot, nginx
threaded - newest
This seems like common sense, no? Return 403 or better yet reject TCP connections on port 80 entirely.
That initial HTTP request header and body is sent in clear text, and that’s more than enough to leak credentials or other sensitive data.
Hindsight is 20/20. As seen in the post, there’s not that many APIs that don’t just blindly redirect HTTP to HTTPS since it’s sort of the default web server behaviour nowadays.
Probably a non-issue in most cases since the URLs are usually set by developers but of course mistakes happen and it absolutely makes sense to not redirect HTTP for APIs and even invalidate any token used over HTTP.
Invalidating creds sent over http is a great point!
This is why most http clients don’t follow redirects by default.
I disagree.
You shouldn’t serve anything over http. (The article argues that there’s risk of leaking user data) Whatever you’re using for a webserver should always catch it. A 301/308 redirect is also cached by browsers, so if the mistake is made again, the browser will correct it itself.
If you make it fail, you’re just going to result in user confusion. Did they visit the right website? Is their internet down? etc.
This article isn’t about browsers or websites, and even acknowledges in the opening that it makes sense as a usability tradeoff in that context.
I clearly didn’t read it. It makes sense, if users aren’t visiting the API then it really doesn’t matter that it’s not redirected on insecure connections.
I love the honesty. It’s really refreshing to see someone take accountability instead of becoming defensive.
I’d like to mention one exception, because it took me ages to properly debug.
If your endpoint is serving mirrors for APT, don’t redirect to HTTPS.
APT packages are signed and validated, so there is no need to use TLS. Lot of docker images (such as Kali) do not have root certificates by default, so they can’t use the TLS, because cert validation fails. You also can’t install the certificates, because they install through APT. If your local mirror redirects to https by default, it will break it for people who choose the mirror, which IIRC happens automatically based on what’s closest to you. I think this issue is still there for Czech Kali package mirror, and it took me so long to figure out (because it’s also not an issue for most of the users, since they have different mirrors), so I like mentioning this when talking http/s. It’s an edge case, but one that I find interresting - mostly because it would never occur to me that this can be an issue, when setting up a mirror.
But that was more than a year ago, it may be better now.
.
I’ve taken to just using HTTPS only. No redirect. Just an error.
It’s interesting that the author and most others went with 403, when 426 seems to be the most appropriate.
Neither are perfect matches, since 403 is about authentication and 426 is for Upgrade semantics (i.e. the upgrade is over the same transport protocol, not switching from http to https). npm isn’t sending an Upgrade header, which is required, but I think if it sent
Upgrade: TLS/1.0, HTTP/1.1then that would be claiming they supported TLS on port 80 (STARTTLS style) - possible but unconventional.When selfhosting stuff, it’s just incredibly difficult to properly set this up while maintaining compatibility with http for other stuff. Usually you’ll have one reverse proxy (eg. nginx) handling http/https encryption and forwarding to a socket (or in case of docker, one of a dozen open ports on one of a hundred interfaces, fuck you docker), over http. The APIs themselves almost never have direct https support, and even if I wanted to manage them directly, certbot only supports reverse proxies directly. So you need to differentiate between api and non-api in the reverse proxy.
This. I was reading through some of the comments, but this is the most accurate one I’ve read thus far. All the APIs I’ve dealt with are just vanilla HTTP and use a reverse proxy for https. A reverse proxy like nginx is also convenient for path pattern matching to different API services but only having to setup https in one spot, nginx