API Shouldn't Redirect HTTP to HTTPS

True, but if we actually did that, it would make those systems very unpleasant to use. The age-old tradeoff of security vs convenience is still as much a force today as is always has been.

Having technically the tightest possible security is not always the right answer. The right answer is whatever balance people are willing to work with for a particular use case. There's a reason that most people don't secure their houses by removing all windows and installing vault doors.

On the subject though, an example of how it could cause a lot of pain, many bigger corps don't allow developers to have "real" API keys, and they certainly can't generate new ones themselves, so this might mean one slip-up with curl results in at best a ticket with another team. It also might end up bringing down production in a horrible way, for example if the dev or an ops person is debugging and curls the endpoint from a pod in prod and forgets to explicitly put the https, curl will default to http which would then immediately cause the prod key to be revoked with no second chances. That could even happen on a GET request, which normally GETs are supposed to be safe/side-effect free! If you're operating at a big scale, that could be utterly disastrous, causing a widespread production outage immediately.

If it's a dev that is just testing a key locally that isn't used anywhere else, then it's obviously less of an issue, but taking that into account starts to balloon the complexity around your token revocation code.

It might just be settings? Do you have "Always use secure connections" turned on? I don't remember if that was a manual toggle or not.

However it's triggered, I hope they make the UI better before they deploy it more widely.

And I'll quote the exact text for you:

[warning triangle]

The connection to 192.168.0.40 is not secure

You are seeing this warning because this site does not support HTTPS. Learn more

[Continue to site] [Go back]

Then when I click continue, the only sign it's doing anything is that the reload arrow becomes a stop X. After 20 seconds it moves on to "This site can't be reached".

You're right, my initial comment wasn't detailed enough to make the point I was trying to make. Let me try again; and just to be certain we're all on the same page, and not to patronise you - MITM here stands for 'Man In The Middle'.

Per your original comment:

> You have to mitm in order to evesdrop on an encrypted channel.

This is correct. The reason for this is important - the evesdropper has to decrypt the traffic, and the only way they can do that (assuming TLS or equivalent) is to get involved in the initial key exchange. If Alice and Bob are trying to communicate, and Eve wants to listen in, Eve has to spoof both Alice- and Bob's connections so that they (unwittingly) each negotiate an encrypted connection with Eve, instead of with each other. Then, Eve is 'in the middle' of the connection - all traffic explicitly travels through an endpoint controlled by Eve. The communication looks like Alice Eve Bob. Alice and Bob think they are communicating with each other, and as you point out, indirectly they are, but there is a Man (or Woman) In The Middle of the channel - Eve. Eve can do whatever she likes with the data - just store it, or modify it in some way. No matter what Eve chooses to do, the topology of the attack is, by definition, a MITM attack.

> If you do nothing but evesdrop, isn't it still mitm?

It depends on the topology of the connection. In the scenario above, then yes. However if Eve is just sniffing unencrypted wifi packets then no, because, again by definition, there is no third party in the middle of the communication channel. Wifi traffic is broadcast and therefore can be logged by anyone nearby without affecting the connection - just as you and I can both listen to the same radio station using different handsets (that's why busy wifi networks suffer congestion and have to use all kinds of tricks to deal with that - if every device is talking at once then the router can't easily pick them apart; they have to find ways to take turns).

In this situation it's more like Alice and Bob shouting at each other across a room, while Eve hides behind a curtain and listens in. Eve doesn't have to do anything to make this happen, apart from showing up - she is not involved in the communication channel in any way.

> If mere evesdropping is still mitm, then as far as I'm concerned any other evesdropping is also mitm.

Hopefully this is clearer now, but no, that's not true. The mechanism by which the evesdropping occurs defines whether or not the attack is a MITM attack. As an aside:

> Then again, I guess a keylogger is evesdropping and not called mitm.

Yes, a keylogger works as a kind of MITM - all communication between the keyboard and the applications travels through a third party of sorts.

Hopefully that's more useful?