221–230 of 310 posts
Excuse me, short question:
If I am not offering a non-TLS endpoint in the first place, and the client, for some reason, decides to take something that is literally called "SECRET", and decides to shout it across the open internet unencrypted...
...how is that my problem again?
Why should my setup be more complex than it needs to be, to make up for an obvious mistake made by the client?
Earlier quoted context omitted.
> You have to mitm in order to evesdrop on an encrypted channel. OK but we're talking about evesdropping HTTP, which is unencrypted.
So what? My point was the encryption doesn't matter, it's just the reason you have to impersonate in order to merely evesdrop sometimes.
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.
I'm guessing there's some (?) advantage of SVCB and HTTPS records that can't be achieved with SRV[1] and TXT records, but I haven't read the RFC yet to know what that advantage is.
[1]: `_https._tcp` or `_http3._udp` or whatever.
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.
As a non-developer, ordinary computer user "providing service" for one user (yours truly) it's easy for me to configure the TLS forward proxy listening on the loopback to send _all_ HTTP requests, from _any_ application, including ones sent to port 80, via HTTPS. This I find preferable to letting a browser try to convert HTTP to HTTPS, e.g., "HTTPS Everywhere", or letting a developer do it with a redirect. Personally…
Do applications with pinned certificates break? A bunch of mobile apps do that to get in the way of Wireshark.
Earlier quoted context omitted.
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.
> all for the sake of encrypting things that were fine in plaintext What was fine in plaintext?
Encryption is for more than secrecy, folks.
Earlier quoted context omitted.
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?
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.
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.