[HN Gopher] API Shouldn't Redirect HTTP to HTTPS
___________________________________________________________________
API Shouldn't Redirect HTTP to HTTPS
Author : oherrala
Score : 224 points
Date : 2024-05-28 19:42 UTC (3 hours ago)
(HTM) web link (jviide.iki.fi)
(TXT) w3m dump (jviide.iki.fi)
| akira2501 wrote:
| > Servers can now send HSTS along with the initial HTTP-to-HTTPS
| redirection response
|
| > Node.js's built-in fetch happily and quietly followed those
| redirects to the HTTPS endpoint.
|
| Okay.. does nodejs fetch respect HSTS?
| Aachen wrote:
| I'm not even sure I'd find it desirable for nodejs fetch() to
| quietly store state somewhere on my server without asking me: I
| wouldn't know to back that file up, it may be trashed regularly
| depending on the infrastructure, it could mess with version
| control by creating a local working directory change, or it
| might run into an error condition if it is on a read-only
| filesystem (either crashing or being unable to use this
| security feature, neither is great).
|
| Config file writes are to be expected for user-facing software,
| but for developers it should error out so they can just choose
| what it needs to do
|
| E.g., "Error: HSTS response received after a redirect from
| HTTP, but no storage location specified for security states.
| Use the https:// protocol, specify a file location, or set
| insecure_ignore_hsts=true."
|
| Edit: but it's a very legitimate question?! Just saw you got
| downvoted, I have no idea why
| moralestapia wrote:
| >Just saw you got downvoted, I have no idea why
|
| I've noticed a gradual increase in this behavior during the
| past ... year maybe? I think for a lot of new people,
| downvoting equates disagreeing, which is not ideal.
|
| Although, I also have no idea why someone would disagree with
| a neutral question like GPs, lol.
|
| Hopefully, it's not the beginning of the end for HN as it is
| a great website.
| iJohnDoe wrote:
| These types of downvotes also discourage discussions. I'll
| upvote a comment when it has been downvoted if it has a
| constructive discussion thread.
| hn_throwaway_99 wrote:
| I think the original question "Okay.. does nodejs fetch
| respect HSTS?" goes into the "not even wrong" bucket, for the
| reasons you point out.
|
| HSTS really only makes sense from a browser perspective (or,
| rather, a "permanently installed, stateful client"
| perspective). For an API like fetch it doesn't even make
| sense as a question IMO.
| moralestapia wrote:
| >For an API like fetch it doesn't even make sense as a
| question IMO.
|
| Why not?
| hn_throwaway_99 wrote:
| Because the way HSTS works fundamentally implies a
| stateful client, and because it was fundamentally created
| to solve a _human_ problem (i.e. humans entering in URLs
| directly in the address bar). It really doesn 't make
| sense with a non-stateful client, and it isn't intended
| for cases where someone isn't manually entering in the
| URL to hit.
|
| E.g. fetch is often loaded in transient situations - it
| really shouldn't be updating its _own_ config because of
| responses it gets. Also, based on the other comment I was
| originally thinking it would be good if fetch would just
| error out if it gets a redirect from http - > https AND
| also a Strict-Transport-Security header, but in that case
| it would still mean it was dependent on the server
| setting up the STS header, and if they could do that they
| should just go ahead and get rid of the http -> https
| redirect in the first place.
| moralestapia wrote:
| I agree with you on things like CORS, but HSTS would
| actually solve the problem stated in this thread quite
| gracefully.
|
| Client fetches http, notices the header, retries https
| then ... ok no, lol. But I guess it's still of some use
| to let clients know "this should always happen through
| https" and make them fail if that's not the case.
|
| Edit: yeah I got it, client fetches http, notices the
| header and then explicitly fails because HSTS is there.
| Aachen wrote:
| I would say it does make sense as a nice upgrade path for
| services that don't yet support https but you'd like to
| switch as soon as they enable it, or if you're forgetful or
| lazy and didn't type https:// in front of the link you were
| given or so
|
| Whether that's still common enough to warrant the extra
| complexity in the fetch function is not something I'm
| qualified to judge
| NewJazz wrote:
| I'm not aware of any general programming language http clients
| that honor HSTS.
| pzmarzly wrote:
| libcurl supports HSTS, but the client has to specify a file
| where the state should be stored
| https://curl.se/docs/hsts.html
|
| Many languages/libraries use libcurl in some shape or form,
| but whether they set up an on-disk HSTS store or not - I
| don't know either.
| g15jv2dp wrote:
| How would that even work? It's up to the developer to consider
| the response and act correctly on it.
| Aachen wrote:
| Same way as TLS session resumption can be handled by
| libraries without you having to touch it, or perhaps
| requiring you to specify a storage file and taking it from
| there
| andersa wrote:
| Just do it like a web browser - when you install Chrome it
| comes with a list of many tens of thousands of domains that
| had HSTS set when GoogleBot visited it.
| akira2501 wrote:
| So if you occasionally forget and use http when you meant
| https and are worried about the consequences of that, you
| should just implement your own HSTS checking layer?
|
| Why not just implement your own fetch wrapper that throws if
| it's not an https connection?
| medellin wrote:
| I fully support this and have always pushed for this. One because
| it becomes a huge mess to maintain over time but also because it
| long term will lower traffic through the LB.
|
| Unfortunately what i see happen all the time is quick fixes are
| pushed to the infra. For example they deploy and typo the URL.
| Now we have a prod outage and infra is pulled in to fix this
| asap. No time to wait for that 10 minute deploy pipeline that
| requires all the tests to run and a deploy to dev.
|
| This happens once and then infra is asked why we don't already
| redirect all URLs. Management doesn't care about security and
| they just lost money. Guess what you are doing now. This is the
| world we live in.
| blowski wrote:
| Indeed. It's probably why so many APIs accept the api key in
| the URL.
| superkuh wrote:
| Or better: actually provide the API on HTTP and HTTPS if your use
| case allows it (ie, non-commercial/institutional, just something
| for human people).
| x86a wrote:
| I don't think this is ever a good idea. Even for non-enterprise
| use cases, you wouldn't want some public hotspot to be able to
| inject random garbage into responses, even if not done with
| malicious intent.
| Wowfunhappy wrote:
| * It allows retro computers to connect.
|
| * It allows very low power embedded devices to connect
| without extra overhead.
|
| * It's not a real security concern if you're on a private
| network.
| rascul wrote:
| > * It's not a real security concern if you're on a private
| network.
|
| I'm not convinced that private networks should be assumed
| secure by default.
| TeMPOraL wrote:
| It's definitely not improving security when, in order for
| a website to interact with an API that both are hosted on
| my private network, possibly even on the same machine, I
| need to set up publicly accessible DNS entries and/or
| hosting my own resolver. That and CORS makes local-first
| anything a huge PITA.
| Control8894 wrote:
| Perhaps, but the other realistic option is a self-signed
| cert. Since browsers refuse to implement any kind of TOFU
| or otherwise 'trust history', a self-signed cert is
| pretty much exactly equivalent to no TLS at all.
| smaudet wrote:
| > Even for non-enterprise use cases
|
| I don't think non-enterprise, non machine use cases should be
| automatically handles, though. Attempting client upgrade is
| better than not, but we should be more clear about whether
| our devices are acting safely, i.e. calling out the change,
| and in the case of http local usage, reminding to use
| visible, out of band verification methods.
|
| Of course this only works if the default is secure, but I am
| glad that browser still let me go unencrypted when I really
| need to, I prefer the giant warning banners...
| moralestapia wrote:
| No, HTTP would expose any sensitive information.
|
| It's just clear text.
| iJohnDoe wrote:
| Does HTTPS also hide the URL request in most logging systems?
| You can always see the domain (api.example.com) but you
| cannot see the URL? The benefit being it hides an API key if
| included in the URL?
| Aachen wrote:
| The benefit is that it:
|
| 1. hides any private information anywhere in the request,
| URL or otherwise, API key or otherwise. Maybe you're fine
| if someone knows you used Bing (revealed through DNS
| lookups), but not what query you entered (encrypted to be
| decryptable only by Bing servers). An API key is obviously
| secret but something as oft-innocuous as search queries can
| also be private.
|
| 2. disallows someone on the network path from injecting
| extra content into the page. This can be an ISP inserting
| ads or tracking (mobile carriers have been playing with
| extra HTTP headers containing an identifier for you for
| advertising reasons iirc) or a local Machine-in-the-Middle
| attack where someone is trying to attack another website
| you've visited that used https.
| yjftsjthsd-h wrote:
| Yes, it hides the URL, although sadly not the domain.
| taftster wrote:
| It hides the domain too, in the literal HTTP request.
|
| What it doesn't hide is the DNS lookup for that domain.
| You still have to translate a hostname into an IP
| address.
|
| This might be a concern for certain uses. But at least
| it's on another port and protocol and not directly
| related to the HTTP request itself.
| yjftsjthsd-h wrote:
| No, HTTPS has the domain in plaintext. There is a plan to
| fix this (Encrypted Client Hello), but AFAIK it's not
| widely used yet.
| taftster wrote:
| Ah yes, apologies. Again, it's not strictly part of the
| HTTP request, but part of the TLS handshake around it.
| And only part of the TLS handshake as part of SNI, if
| supported (which is true by default).
|
| _> "Server Name Indication payload is not encrypted,
| thus the hostname of the server the client tries to
| connect to is visible to a passive eavesdropper."_
|
| https://en.wikipedia.org/wiki/Server_Name_Indication
|
| So you're right, this is more aligned to the HTTP request
| than the DNS resolution of hostname that I mentioned.
| Strictly speaking, it's not part of HTTP per se (it's
| part of TLS), but still, it's in the same request in the
| most common definition, as you are saying.
| justin_oaks wrote:
| I'll disagree on these grounds:
|
| 1) HTTP can be modified by a man in the middle
|
| 2) It's better to default to requests and responses being
| private, even if you're only using a non-
| commercial/institutional service.
|
| You could say "The person chose to send requests to HTTP
| instead of HTTPS" and assume that the consumer of the API
| didn't care about privacy but, as the article points out, it's
| easy to typo http instead of https.
| ozim wrote:
| That is an awful idea - in post Snowden world you encrypt all
| traffic period.
|
| Then you have post Jia Tan world - if there is even slightest
| remote possibility, you just don't want to be exposed.
|
| Just like washing hands after peeing, just do HTTPS and don't
| argue.
| superkuh wrote:
| If that's your threat model then CA TLS is going to make
| things even worse for you because now the nation state
| pressure can be centralized and directed through the CA.
|
| There are trade-offs but HTTP has it's place. HTTP is far
| easier to set up, more robust, far more decentralized,
| supports far more other software, and has a longer lifetime.
| For humans who aren't dealing with nation state threat models
| those attributes make it very attractive and useful.
|
| We should not cargo cult the requirements for a multi-
| national business that does monetary transactions and sends
| private information with a website run by a human person for
| recreation and other humans. There is more to the web than
| commerce and we should design for human persons as well as
| corporate persons.
| bigstrat2003 wrote:
| Dogma is how religion works, not engineering. If someone
| doesn't believe the benefit is worth the cost, they can and
| should question the practice. Blind obedience to a dogma of
| "just do HTTPS" is not a reasonable approach.
| HL33tibCe7 wrote:
| "Rules of thumb" form many of the fundamental tenets of
| engineering practice.
|
| Using HTTPS everywhere is one such rule of thumb.
|
| It's just not worth expending the mental energy considering
| every single edge case (while likely forgetting about some)
| in order to try and work out whether you can cut the corner
| to use HTTP rather than HTTPS, when using HTTPS is so easy.
| codepoet80 wrote:
| You've already been shouted down, but thank you for daring to
| suggest this. I maintain APIs and proxies for APIs for legacy
| devices, and will continue to suggest that _some_ kinds of APIs
| remain appropriate for HTTP access. Never do your banking this
| way, obviously, but where is the harm in allowing older devices
| to access content in a read-only fashion?
| taftster wrote:
| Hypothetically speaking, plain HTTP transport even for "read
| only" content, can be a problem if it can be manipulated in
| transit.
|
| Let's take a weather service. Seems like weather information
| is a read-only immutable fact and should not be something
| that needs protection from MITM attacks. You want to reach
| the largest audience possible and your authoritative weather
| information is used throughout the world.
|
| One day, an intermediary system is hijacked which carries
| your traffic, and your weather information can be rewritten
| in transit. Your credibility for providing outstanding data
| is compromised when you start serving up weather information
| that predicts sunny skies when a tornado watch is in effect.
|
| Additionally, you have now leaked information related to the
| traffic of your users. Even if the request is just vanilla
| HTTP-only, an adversary can see that your users from one
| region are interested in the weather and can start building a
| map of that traffic. They also inject a javascript payload
| into your traffic that starts computing bitcoin hashes and
| you are blamed for spreading malware.
|
| In general, HTTPS protects both your interests and those of
| your users, even for benign data that doesn't necessarily
| need to sit behind "an account" or a "web login".
| smaudet wrote:
| > an adversary can see that your users from one region are
| interested in the weather and can start building a map of
| that traffic
|
| I think this is the most convincing argument, but, I think
| that some data doesn't care if it is not confidential. The
| weather is perhaps more pointed, but I think for large
| protected binaries (either executable or inscrutable, e.g.
| encrypted or sig protected archives), its a bit moot and
| possibly only worse performing.
|
| However, also remember that https does not protect all
| data, just the application portion - adversaries can still
| see, map, and measure traffic to bobthebaker.com and
| sallyswidgets.biz. To truly protect that information, https
| is the wrong protocol, you need something like Tor or
| similar bit mixing.
| Control8894 wrote:
| > One day, an intermediary system is hijacked which carries
| your traffic, and your weather information can be rewritten
| in transit. Your credibility for providing outstanding data
| is compromised when you start serving up weather
| information that predicts sunny skies when a tornado watch
| is in effect.
|
| Why would they want to do that? Is your weatherman always
| right?
|
| > Additionally, you have now leaked information related to
| the traffic of your users. Even if the request is just
| vanilla HTTP-only, an adversary can see that your users
| from one region are interested in the weather and can start
| building a map of that traffic.
|
| Ah, yes, people are interested in the weather. Wow!
|
| Of course, they could get the same info from observing that
| users are connecting to the IP address of a weather API
| provider.
|
| > They also inject a javascript payload into your traffic
| that starts computing bitcoin hashes and you are blamed for
| spreading malware.
|
| Got there eventually. Crappy ISPs.
| jkrejcha wrote:
| > Additionally, you have now leaked information related to
| the traffic of your users. Even if the request is just
| vanilla HTTP-only, an adversary can see that your users
| from one region are interested in the weather and can start
| building a map of that traffic.
|
| One thing to note is that nothing about HTTPS protects
| against this type of attack. Assuming your API doesn't have
| much else going on (most services, probably), an adversary
| can easily see that you visited mycoolweatherapi.example
| regardless of if HTTPS is being used or not.
|
| What TLS protects is higher on the network layer cake
| cqqxo4zV46cp wrote:
| How is this better in literally any way other than it makes
| things (in 2024, only very slightly) easier from an ops
| perspective, and panders to some nerdy fetish for simple 'read
| it over wireshark' protocols?
|
| HTTPS-only should be the default. Plain-text information
| delivery protocols that can easily be MITMd are unsuitable for
| almost all uses.
|
| This just feels like contrarianism.
| justin_oaks wrote:
| I appreciate the author calling this out because creating an
| HTTP-redirect-to-HTTPS is something I'll do almost without
| thinking about it. "If it has HTTPS, I'll set up an HTTP
| redirect." Now I know that I need to think about it before
| setting that up.
|
| It also made me realize that cURL's default to not redirect
| automatically is probably intentional and is a good default.
| Praise be to Daniel Stenberg for this choice when implementing
| cURL.
| tootie wrote:
| Using Cloudfront, the redirect was the only built-in option for
| a long time. They only added pushbutton HSTS recently. But I'd
| say author is correct that if you're hosting an API there's no
| reason to support http at all. Just send a 400 on all requests
| and let the client developers use common sense.
| lxgr wrote:
| Completely agree, and arguably why stop at API servers?
|
| Depending on server-side HTTP -> HTTPS redirects for security
| reinforces/rewards bad practices (linking to HTTP, users directly
| entering HTTP etc.), in a way that makes users vulnerable to one
| of the few remaining attack vectors of "scary public Wi-Fis".
| Aachen wrote:
| We are. Slowly, due to lots of legacy, but surely getting
| there.
|
| See the small steps over the years where it was first an add-on
| to force https-only mode (HttpsEverywhere, 2011), then browsers
| started showing insecure symbols for http connections (e.g. in
| 2019: https://blog.mozilla.org/security/2019/10/15/improved-
| securi...), and more recently I think browsers are starting to
| try https before http when you don't specify the protocol. I've
| also seen a mention of strict https mode or something, not sure
| if that's a private navigation feature or something yet to
| come, but warning screens equivalent to insecure certificate
| pages are getting there
| Dylan16807 wrote:
| Chrome's version of trying https first sure is annoying
| though.
|
| If a site is down entirely, when chrome can't connect to port
| 443 it confidently declares that "the connection is not
| secure because this site does not support https" and gives a
| "continue" button. Then when you click "continue" nothing
| happens for a while before it finally admits there's nothing
| responding at all.
|
| So it gives a misleading error _and_ takes longer to figure
| out if a site is actually down.
| jraph wrote:
| I'm highly surprised by this. It seems very dumb and I have
| never seen anything like this, though I never use Chrome
| and very rarely fire Chromium for testing something.
|
| Is there something to read about this, like a dev ticket?
| Dylan16807 wrote:
| There might be but I'm not aware of any tickets. But if
| you open chrome and navigate to 192.168.20.20 you should
| see it. Or any domain that resolves to a non-responsive
| IP, if you have one in mind.
| o11c wrote:
| Firefox has a similar bug, but for DNS rather than
| connection.
| nimih wrote:
| > arguably why stop at API servers?
|
| I think this is pretty convincingly argued in TFA, honestly:
| modern browsers understand and respect HSTS headers, maintain
| enough local state that such headers are meaningful, and HSTS
| preloading is easy enough to set up that it should be
| achievable by most website operators.
|
| Furthermore, it is actually quite hard to concoct a scenario
| where a user clicking an HTTP link and getting immediately
| redirected constitutes a danger to their security: unlike with
| API endpoints, people clicking links (and in particular, links
| which were typed out by hand, which is how you get the HTTP
| protocol in the first place) are generally not making requests
| that contain sensitive information (with the exception of
| cookies, but I would argue that getting someone to have a sane
| configuration for their cookies and HSTS headers is a far
| easier ask than telling them to stop responding to all port 80
| traffic).
| bigstrat2003 wrote:
| The push for "TLS all the things" was already a massive
| overreach that actively made security worse overall, because it
| further ingrained the user tendency to click through scary
| browser warnings (all for the sake of encrypting things that
| were fine in plaintext). And you want to go even _further_? No
| thank you.
| tomsmeding wrote:
| > because it further ingrained the user tendency to click
| through scary browser warnings (all for the sake of
| encrypting things that were fine in plaintext).
|
| Why should there be more scary warnings when more websites
| use TLS? Sure, you get more scary warnings if you set your
| browser to "warn if it's http", but then you're asking for
| it.
| xboxnolifes wrote:
| > Sure, you get more scary warnings if you set your browser
| to "warn if it's http", but then you're asking for it.
|
| Defaults. They matter.
| snowwrestler wrote:
| HTTPS and SVCB DNS records will hopefully make it more feasible
| over time to drop the traditional HTTP server-side redirect. The
| client agent will be able to read the DNS record and upgrade to
| the highest available protocol prior to sending the first
| request.
| Gigachad wrote:
| Or just add your domain to the hsts preload list and never have
| to worry about this.
| yjftsjthsd-h wrote:
| Is the HSTS preload list used by anything other than browsers?
| I'd expect it to be minimally useful for an API.
| yegle wrote:
| That works for browsers but I doubt any non-browser HTTP
| clients (e.g. curl and wget) or HTTP library (e.g. Python
| requests lib) will check the HSTS preload list.
|
| In fact if they do follow HSTS headers, a simple `Strict-
| Transport-Security: ...; preload` would have fixed the issues
| mentioned in the article.
| cqqxo4zV46cp wrote:
| Please look into the myriad scenarios in which HSTS is not
| honoured.
|
| As usual, any comment stating that people should "just" do x,
| is wrong.
| nimih wrote:
| Did you happen to RTFA, in which the author specifically
| mentions HSTS preloading--helpfully styled as a bold,
| underlined, bright blue link--in the second paragraph? If you
| manage to then get to the third paragraph, a concise and
| compelling reason is given for why it's not applicable in the
| scenario the author is examining.
| iJohnDoe wrote:
| Sort of off-topic. What is a recommended way to sell access to a
| one-off data API? Low code method to control access and
| facilitate payment?
| Aachen wrote:
| As in, selling API keys? Not sure what you're asking for. Are
| you looking for a webshop that has API key sales as a default
| item type or something?
| iJohnDoe wrote:
| Yes, more like a SaaS. Maybe a solution that is tailored to
| selling API access. Generates a unique URL to the user, or
| API key, after they sign up for the API service.
| winddude wrote:
| That's an excellent point, and definitely something I've done
| without thinking about it. I'm going to stop, and disable those.
| Thanks!
| blahyawnblah wrote:
| Don't have HTTP available at all
| lxgr wrote:
| That's literally what the article suggests:
|
| > A great solution for failing fast would be to disable the API
| server's HTTP interface altogether and not even answer to
| connections attempts to port 80.
| davedx wrote:
| It also says
|
| > We didn't have the guts to disable the HTTP interface for
| that domain altogether, so we picked next best option: all
| unencrypted HTTP requests made under /api now return a
| descriptive error message along with the HTTP status code
| 403.
|
| So close and yet ... their misconfigured clients will still
| be sending keys over unencrypted streams. Doh
| hn_throwaway_99 wrote:
| > So close and yet ... their misconfigured clients will
| still be sending keys over unencrypted streams. Doh
|
| And how does disabling the HTTP interface altogether
| prevent that? In that case, any sensitive credentials are
| still already sent by the client before the server can do
| anything.
| whoopdedo wrote:
| Not if the server refuses a connection on port 80.
|
| addendum: How quickly can a server write a 403 response
| and close the connection and can it be done before the
| client is able to write the entire HTTP request? My guess
| is not fast enough.
| lxgr wrote:
| I'd be surprised if most HTTP clients even looked at the
| response code before writing at least the entire HTTP
| request (including authentication headers) out to the TCP
| send buffer.
|
| And if they do that, even if they immediately close the
| TCP socket upon seeing the 403, or even shut down their
| process, I believe most socket implementations would
| still write out the queued send buffer (unless there's
| unread inbound data queued up at the time of unclean
| socket close, in which case at least Linux would send an
| RST).
|
| And with "TCP fast open", it would definitely not work.
| piperswe wrote:
| If the client can't open a TCP connection to port 80,
| there's no unencrypted path to send the API keys down
| wild_egg wrote:
| TCP handshake failure prevents the client from being able
| to send any data, no?
| lxgr wrote:
| Often, but not always:
| https://en.wikipedia.org/wiki/TCP_Fast_Open
| hiatus wrote:
| > TFO has been difficult to deploy due to protocol
| ossification; in 2020, no Web browsers used it by
| default.[2]
| gsich wrote:
| It's in use by Android for DNS over TLS. Ossification
| issues are exaggerated.
| aniviacat wrote:
| Would disabling HTTP change that? Would TCP figure out the
| connection isn't working before the api keys are sent?
| haileys wrote:
| Yes disabling HTTP would prevent keys being sent if the
| remote end isn't listening, unless TCP Fast Open is in
| use, which it is not by default.
| davedx wrote:
| This is better, and the only way to really prevent the primary
| problem. Why would an API be on HTTP at all?
| Aachen wrote:
| Why is it better?
|
| I can't think of large differences. What comes to mind are
| two human factors that both speak against it:
|
| - Having an HTTP error page informs the developer they did
| something wrong and they can immediately know what to fix,
| instead of blindly wondering what the problem is or if your
| API is down/unreliable
|
| - That page, or a config comment, will also inform the
| sysadmin that gets hired after you retire comfortably that
| HTTP being disabled is intentional. Turning something off
| that is commonly on might be a time bomb waiting for someone
| who doesn't know this to turn it back on
|
| Edit:
|
| Just saw this reason, that's fair (by u/piperswe)
| https://news.ycombinator.com/item?id=40505545
|
| > If the client can't open a TCP connection to port 80,
| there's no unencrypted path to send the API keys down
|
| If that immediately errors out on the first try, though, what
| is the risk of the key being intercepted? The dev would never
| put that in production, so I'm not sure how the pros and cons
| stack up. I also loved this suggestion from u/zepton which
| resolves that concern:
| https://news.ycombinator.com/item?id=40505525 invalidate API
| keys submitted insecurely
| rascul wrote:
| The argument I've heard against not having HTTP at all is that
| potentially someone might be able to run something malicious on
| port 80 for that address that the admin is not aware of.
|
| People can make up their own minds if that's a good argument or
| not.
| HL33tibCe7 wrote:
| That's a terrible argument. If someone can run something on
| port 80, they have root on the machine, at which point can do
| whatever they want (including getting rid of whatever
| existing process was listening on port 80 and replacing it
| with their own).
| sdsd wrote:
| My 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 <font> and <center> 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. Since my site has very
| little functionality, it doesn't really matter, it's just for
| fun.
| layer8 wrote:
| That's fine, but rather unrelated to the article, which is
| about the situation that you have an API served via HTTPS, and
| the question of whether you should also have a redirect from
| HTTP to HTTPS in that case, or rather return an HTTP error.
| sdsd wrote:
| Yeah, I should have clarified. Nothing to do with the article
| really, just a random thought. Sorry if too off-topic!
| Aachen wrote:
| I can appreciate this and also run a service that is neither
| meant to be commonly visited (imagine a tor exit node landing
| page explaining what this IP address is doing, but for a
| different service) nor will produce or ingest sensitive
| information
|
| For a personal website that people might commonly want to
| visit, though, consider the second point made in this other
| comment: https://news.ycombinator.com/item?id=40505294 (someone
| else mentioned this in the thread slightly sooner than me but I
| don't see it anymore)
| cqqxo4zV46cp wrote:
| A HTTP website presents an opportunity for an attacker to MITM
| a payload that is ultimately executed in a user's browser.
| Beyond 'getting a moustache tattoo on your finger' quirkiness,
| HTTP-only websites are really inexcusable beyond some very
| niche cases.
| sdsd wrote:
| >Beyond 'getting a moustache tattoo on your finger'
| quirkiness
|
| In that case, seems totally worth it. I, like moustache
| finger tattoos, am aggressively opposed to worrying about
| being perceived as cool. I will just have to live with being
| inexcusable.
| valec wrote:
| not my problem!
| HL33tibCe7 wrote:
| To me, HTTPS is worth it alone to eliminate the possibility of
| the ISPs of people reading my site from injecting shit (ads,
| trackers, etc.) into the responses I send to them.
|
| It's completely trivial to set up, there's really no downside
| at this point.
| dfabulich wrote:
| The author includes a surprising response from "Provider B" to
| the HackerOne report.
|
| > _Provider B: Reported on 2024-05-21 through their HackerOne
| program. Got a prompt triage response, stating that attacks
| requiring MITM (or physical access to a user 's device) are
| outside the scope of the program. Sent back a response explaining
| that MITM or physical access was not required for sniffing.
| Awaiting response._
|
| I think Provider B morally should require HTTPS, but it really
| surprises me that the author would say "MITM or physical access
| is not required for sniffing."
|
| Is that true? Isn't HTTP sniffing an example of a MITM attack, by
| definition? Am I using the words "MITM" or "sniffing" differently
| from the author?
|
| I'm familiar with the following attacks, all of which I'd call
| "MITM":
|
| 1. Public unencrypted (or weakly WEP encrypted) wifi, with
| clients connecting to HTTP websites. Other clients on the same
| wifi network can read the unencrypted HTTP packets over the air.
|
| 2. Public encrypted wifi, where the attacker controls the wifi
| network (or runs a proxy wifi with the same/similar SSID,)
| tricking the client into connecting to the attacker over non-TLS
| HTTP.
|
| 3. ISP-level attacks where the ISP reads the packets between you
| and the HTTP website.
|
| Aren't all of these MITM attacks, or at the very least "physical
| access" attacks? How could anyone possibly perform HTTP sniffing
| without MITM or physical access??
| Aachen wrote:
| Definition question. I can see your reasoning and I can see the
| author's, where they define MITM as requiring an active
| component being in the middle to actually tamper with it and
| not just some far-off device receiving backscatter with a high-
| gain antenna, or a read-only mirror port on a switch or
| whatever is technically not "in the middle" but in a cul-de-
| sac. I'm not sure I've got a strong opinion, claiming one or
| the other is the only correct definition might just be
| nitpicking
|
| They may have chosen this wording ("it's not MITM") to get the
| team into action rather than dismissing the risk
|
| Edit: another legitimate-sounding question downvoted in this
| thread without further comment (since I'm the only comment
| still after it got downvoted). Can people maybe just explain
| what's wrong with a post when it's not a personal attack, not
| off topic, not answered in the article, or any other obvious
| downvote reason? Everyone would appreciate the author learning
| from the problem if there is one
| thaumasiotes wrote:
| > Public unencrypted (or weakly WEP encrypted) wifi, with
| clients connecting to HTTP websites. Other clients on the same
| wifi network can read the unencrypted HTTP packets over the
| air.
|
| That's sniffing. The other two are MITM. The sniffer isn't in
| the middle of anything; you never speak to him.
| HL33tibCe7 wrote:
| MITM generally refers to someone who can intercept and modify
| traffic, i.e. they sit "in the middle", between you and your
| recipient, reading/modifying/relaying traffic.
|
| "Passive eavesdropper" is often used to describe what you talk
| about. Someone on an unencrypted WiFi network sniffing your
| traffic isn't really "in the middle" at all, after all.
| Control8894 wrote:
| I disagree. So does Wikipedia ("where the attacker secretly
| relays and possibly alters the communications between two
| parties who believe that they are directly communicating with
| each other, as the attacker has inserted themselves between
| the two parties ... for example, an attacker within range of
| an Wi-Fi access point hosting a network without encryption
| could insert themselves as a man in the middle") and so I
| believe do most people.
|
| "Active MITM" would be how you describe someone who does
| modify traffic.
|
| And an attacker in each of the scenarios GP mentioned _can_
| modify traffic. (For ISP /attacker-controlled networks it's
| trivial; for other networks you just need to ARP spoof)
| dTP90pN wrote:
| There's no "relaying" when the the attacker just captures
| unencrypted WiFi packets from the air, or more
| traditionally, splits some light out of the fiber line.
| Control8894 wrote:
| > for example, an attacker within range of an Wi-Fi
| access point hosting a network without encryption
|
| The monkey in the middle doesn't get to "relay" anything
| either, but he can sure see it going over his head.
| tsimionescu wrote:
| I agree that's not a case of MITM, but I do think it's fair
| to call sitting in range of the same Wi-Fi access point
| "physical access".
| tsimionescu wrote:
| I don't think people would consider 1 or 3 to be MITM. MITM
| requires someone who is, well, in the middle: you connect to
| the MITM, and they connect to your destination. 2 is clearly a
| MITM.
|
| Also, while 1 is arguably a case of "physical access", I don't
| think 3 is. If you have a tap in an ISP, you don't have
| "physical access" to any of the endpoints of the HTTP
| connection. Otherwise, you could say you have "physical access"
| to literally every machine on the internet, since there is some
| physical path between you and that machine.
| eddd-ddde wrote:
| Now that I think about it, interfaces such as Js fetch should
| make it an error to use http without explicitly allowing in an
| option.
|
| It seems to easy to make an error and end up in a situation like
| the post explains.
| smaudet wrote:
| Hmm. I think, perhaps, release versions should need this,
| without a flag.
|
| For testing/prototyping, it is invaluable to turn off all the
| security to rule out security misconfiguration instead of
| application error.
|
| If your API is non-sensitive/relies on out of band security
| (like large files with checksums), you may still not want
| https, so there should be some configuration to turn it off.
| And for "integrations" like jsdelivr, perhaps https libraries
| should follow this rule, while http ones can have the flag
| off...
|
| Then, if you mix the two (http and https) perhaps they can
| provide an noticeable alert to the user rather than failing
| silently...
| jpswade wrote:
| Nothing should redirect ever. However, it happens.
| GauntletWizard wrote:
| I do redirect APIs to HTTPS, but I'd prefer not to. There's a
| simple reason - My APIs are hosted on the same IP as the public
| website, behind the same load balancer, so something has to be on
| the HTTP port. I would prefer to separate them, and my larger
| customers do - But for smaller customers, it's an unnecessary
| added expense and complication that doesn't make sense.
| zepton wrote:
| The Stack Exchange API used to revoke API keys sent over HTTP
| (and return an error message), which is my favorite way to handle
| this.
| znpy wrote:
| I've been thinking for about 5 minutes about this comment and
| what to write but i've come to the conclusion that this is
| really not the best thing to do, but the correct thing to do.
|
| It's not different levels of good or bad... everything else is
| wrong.
| comex wrote:
| One of the approaches mentioned in the article is to just not
| listen on port 80. Supposedly that's equally good because the
| connection should get aborted before the client has the
| chance to actually send any API keys.
|
| But is that actually true? With TCP Fast Open, a client can
| send initial TCP data before actually learning whether the
| port is open. It needs a cookie previously received from the
| server to do so, but the cookie is not port-specific, so -
| assuming the server supports Fast Open - the client could
| have obtained the cookie from a prior connection over HTTPS
| or any other valid port. That's the impression I get from
| reading the RFC, anyway. The RFC does mention that clients
| should distinguish between different server ports when
| caching refusals by the server to support Fast Open, but by
| that point it's too late; the data may have already been
| leaked.
| pixl97 wrote:
| If someone is in your path they can just fake listen to 80
| and intercept, then forward your call to 443.
|
| Probably best to listen on 80 and trash the token right
| then as the majority of the time there won't be a MITM and
| breaking the application will force the developer to change
| to https
| comex wrote:
| But not listening on port 80 will also usually break the
| application. Though I suppose the same API key may be
| used by multiple applications, or multiple copies of an
| application configured differently.
|
| edit: and even if there's only one application, yet for
| whatever reason it doesn't get taken down despite being
| broken, revoking the key now still prevents against a
| MITM later.
| andrewaylett wrote:
| 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 solution is probably the right one
| in that case -- and hopefully anyone who hits it will do so
| with dev keys rather than in production.
| op00to wrote:
| I love this.
| paulddraper wrote:
| Technically correct.
| croes wrote:
| Maybe shttp would have been better than https to reduce typo
| errors or maybe even something completely different from http.
| toomim wrote:
| Ah... you know, that idea sounds not too shtty to me.
| ikisusi wrote:
| I hope that providers whose APIs responded and interacted fully
| over unencrypted HTTP would go back to their historical access
| logs and check how widespread using plaintext HTTP is. If they
| don't have access logs for their API then they could just sample
| next 24 hours for API accesses.
|
| Popular providers have so many API users today that even a rare
| mistake could expose quite many users in absolute numbers. Would
| rather have providers to check this out rather than have this
| poor practice abused by the next DNS hijacking malware affecting
| home routers.
| barryrandall wrote:
| I agree that APIs shouldn't automatically redirect HTTP to HTTPS,
| but I also think that client libraries shouldn't follow redirects
| by default.
| amanzi wrote:
| Interesting - I hadn't considered this before, but makes perfect
| sense. Feels like it's something that's easy to miss, as lots of
| APIs are hosted behind generic web application firewalls that
| often have automatic HTTPS redirection as a base rule.
| athyuttamre wrote:
| Great 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": null } }
| andrewaylett wrote:
| I've stopped opening port 80 at all for some of my web services.
| The parent domain is in the HSTS preload list, so no modern
| browser should ever be trying to connect to port 80. And (as the
| fine article intimates) API calls shouldn't be available on port
| 80 _anyway_.
___________________________________________________________________
(page generated 2024-05-28 23:00 UTC)