Story time. Someone I know once got laid thanks to Facebook not encrypting their sessions

My university was still using basic ass unencrypted WiFi with some kind of terrible dns-hijack sign in to “auth”. This of course meant that everyone put their shiny MacBooks on essentially public wifi and logged in to social media in the clear in class.

Some enterprising chaps made a browser extension that made it trivial to snoop any open sessions and impersonate that session in a new tab.

Someone I know would do this during lecture and post to people’s social media as them saying they should pay attention in lecture. Possibly some other scandalous things were said. The hilarity that led from that stranger doing so led to the beautiful nerdy girl sitting behind this person noticing and daring them to post more. That became hanging out, parties, and as far as I know they got married and have kids now.

Literal people exist that wouldn’t otherwise because Facebook didn’t have HTTPS

Firesheep was super big for a while, yeah. I used it to show a few coffee shops that yes, really, WiFi with a password of "password" was measurably better for their customers than no password: https://en.wikipedia.org/wiki/Firesheep

It works. It's fine. No, it does not need ssl. What, someone is going to hack a floppy driver for a computer, which doesn't even have a built in network stack?!

No, I am not going to do work on it, any work, at all.

Millions of such sites exist, are fine, are safe.

Depending on what the drivers are for, you may be a prime candidate for MitM. People already go to your site to download software they're going to run in the most privileged mode. This is a perfect candidate for a type of watering hole attack.

Considering you're providing those for 90s machines, you could be the last resort website for a few interesting industry computers with no security restrictions around them.

Doing that MitM is technically very easy, but in practice pretty hard. You'd have to have an adversary on your network path watching for connections to this particular esoteric low-volume site hosting drivers for machines from the 80s and 90s.

That is extremely unlikely.

I have a much easier way to target that content: Just put up a new site hosting the same content with malware attached. No need for MitM shenanigans.

Security isn't about absolutes, it is about risk managment and being aware of the likelihood and consequence of the risks is important.

Without HTTPS, the content can be replaced entirely. Last time it was JavaScript that DDOS'd github. If you don't want to serve content over HTTPS, then you don't care what your users receive. Just delete the site and they all get 404's instead, since you already admit that you don't care either way.

If it makes you feel any better, HTTP without HTTPS was a mistake we all made together. It should never have happened.

Given that http predates SSL 1.0 by a few years, somewhat inevitable.

You're at a coffee shop or library using their WiFi. Your computer sends a plaintext HTTP message. The attacker just needs to be able to see that message and get a response back to you before the real site does, and the real site is a lot further away than the guy sitting at the table next to you (or the hacked router, if he doesn't want to be there in person). Then they can feed your browser whatever they want.

A login form to phish you, perhaps?

They can even start replying, then go off and fetch from the actual site before finishing the response, if it helps to incorporate the real data.

>are safe

No, they are not.

>No, I am not going to do work on it, any work, at all.

If you are too lazy to do it securely maybe you just shouldn't do it at all.

HTTPS everywhere by default can't come fast enough. There is no excuse at all to not have HTTPS support today and browsers should deny access to these lazy and careless sites by default. Anyone who can't spend the 5m to set it up for their website can go kick rocks as far as I'm concerned.

There is nothing wrong with your website. However, you shouldn't be surprised when modern browsers stop working with it. Progress doesn't come free.

This genuinely happens a lot in the 2020s.

More likely sites get cloned, improve their SEO over the original, and distribute malware.

Sceptical of that claim, can you provide a few documented cases?

Particularly for low-volume sites like the parent post.

And update all links to not go back to the HTTP site...

And troubleshoot weird issues (TLS errors are generally not helpful)...

And maintain that setup for years...

Not an insurmountable effort for sure, but if you estimate 30 min for the total additional effort of adding HTTPS to a site then I have a bridge to sell you.

Frankly, even sadly, they are also entirely forgettable and don’t add enough value to hold back the modern web.

I always chuckle at this site does not need SSL post from n-gate.

PS: Use the URL directly in browser because the site doesn't like traffic from HN.

Or just fix your browser settings to not send cross-domain Referer headers.

HTTPS can introduce all scenarios for not being able to connect.

I'm not hosting any secret data, but I do want to be able to post from anywhere.

Literally to this day one can read things like the NSA manual for using their software that enables real-time absolute surveillance of Skype: "User's Guide For PRISM Skype Collection." [2] The idea of any degree of privacy from any tech company hosted in America is a lie. The main difference with China is that we lie about our surveillance state, and force companies to lie about it, while China openly advertises theirs.

[1] - https://en.wikipedia.org/wiki/PRISM

[2] - https://www.aclu.org/sites/default/files/field_document/Guid...

In many cases you can even determine which protocols and general content they are consuming from that IP based on traffic shaping/fingerprinting. The burst of traffic your browser sends when loading a particular site is quite exploitable. There's plenty of software already available that makes use of this.

but this just reminded me of the failed FB phone and the failed microsoft phone...

Looking at the ones I use daily... headphones, TV soundbar, Xbox controllers, TV remote. None of those provide an interesting attack vector.

My iPhone isn't really going to be connecting to random stuff and leaking data, so I don't really see the risk here. Maybe I'm missing something?

Incorrect -- BT scanners and loggers have been LONG tracking your things avail...

and the fact that Apple doesnt allow you to "turn off" it merely pauses..

both wifi and BT...

they use prox sensors for BT for airtags, wifi etc and ALL OF THAT data in mined like mad.

Any Apple person that says otherwise is lying to you.

How would they do the same for bluetooth? Broadcasting "Dans iPhone" doesn't tell you much.

they have so many correlation engines for device location, that it will soon be impossible to be "off grid", if its not already.

how the heck do you think there are fn leaks from over a decade ago of "text messages received by the government reveal that person X who is on the shit-list was quoted as saying [BULLSHIT] sources close to CNN have stated.."]

ASIDE: Famous story from ~20 years ago was talking about the CIA handlers at CNN... and the revolving door of in-q-tel emps from fb moving back and forth within the security team (one of which had to be walked out of the building for [things])

you dont need "dan's phone" they have had eschelon for DECADES and were able to literally do 6-degrees ppl tracking since the 1990s...

WTH do you think they named it "starlink" instead of sky-net...

And when they built the first part, they were advertising the wonderful things the rural folks in africa's greater continent will benefit, then after a few years they showed that the system will primarily service the dense populations of the coasts of places like the USA and AUS -- which is where a big portion of the five-eyes service.

IMEI and such is a bitch..

iOS is the biggest location tracking platform ever...

Remember when the founder of Android (from Danger) was let go from google with a ~200MM$ golden parachute at $90MM to gtfo?

Aside from that, this isn’t possible for HSTS sites.

Even more, for self-signed certificate on chrome, there is no button to continue for example. Check https://self-signed.badssl.com/

Tech support comes in many forms. The owner of the website, a friend who knows about computers, someone else in the workplace, the vendor they purchased their laptop from.

handelsbanken.se danskebank.se unicredit.it fideuram.it sella.it

I once wrote them a long email about what two-factor is actually supposed to be and why it exists, and got a reply basically saying "lol ok, our security is great ok?"

I've since switched away from them for a bank which does 'two-factor' by sending codes via SMS, but only when its algorithm decides that it needs to. That's not very often.

unicredit.it is not on the list, but unicredit.ba and unicredit.ro are. (Lines 7331 and 7332) It does send HSTS headers.

danskebank.se and sella.it are not in the file, nor are the base strings, but both sites do send HSTS headers.

fideuram.it is not on the list, and does not send HSTS headers, so they don't seem particularly interested in security. They also haven't set an A record for the root domain, so visiting `fideuram.it` returns NXDOMAIN. Only `www.fideuram.it` exists.

Isn't it possible for the user to disable HSTS. A simple web search produces detailed instructions, from a CA.

https://sectigostore.com/blog/how-to-disable-hsts-in-chrome-...

Also, what does "HSTS sites" mean. Does it mean (a) "official" HSTS via HTTP header alone, (b) "unofficial" HSTS via preload list (see RFC 6797 section 12.3), i.e., the list maintained by Google, hardcoded into a browser, or (c) both. The "unofficial" approach only seems feasible for a limited number of domainnames and unworkable for every domainname in existence.

In tests I have done on Chrome (YMMV), executing "Clear site data" via Developer Tools, or including

   Clear-Site-Data: *

Besides being generally annoying, HSTS allows for setting "supercookies" that persist even in "Incognito" mode

https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-bro...

The RFC for HSTS even admits how it can be used for web tracking. Not too concerning for the advertising company sponsoring the RFC.

14.9. Creative Manipulation of HSTS Policy Store

Since an HSTS Host may select its own host name and subdomains thereof, and this information is cached in the HSTS Policy store of conforming UAs, it is possible for those who control one or more HSTS Hosts to encode information into domain names they control and cause such UAs to cache this information as a matter of course in the process of noting the HSTS Host. This information can be retrieved by other hosts through cleverly constructed and loaded web resources, causing the UA to send queries to (variations of) the encoded domain names. Such queries can reveal whether the UA had previously visited the original HSTS Host (and subdomains).

I use a loopback-bound forward proxy to enforce zero tolerance for HTTP across all programs, not just the web browser. Everything is sent via HTTPS. The proxy is configured to to check certificates, and deny connections, according to rules I set. I use a text-only browser for noncommercial, recreational web use so I need a forward proxy, if for nothing other than to deal with the spread of TLS. But I also use it for a whole laundry list of tasks.

Maybe it is just me, but HSTS, like much of Google's rhetoric, comes across as unfriendly if not hostile to proxies, regardless of who is running them. Consider this line from the RFC

"The rationale behind this is that if there is a "man in the middle" (MITM) -- whether a legitimately deployed proxy or an illegitimate entity -- it could cause various mischief (see also Appendix A ("Design Decision Notes") item 3, as well as Section 14.6 ("Bootstrap MITM Vulnerability"));"

"Mischief." Does that include inspecting one's own HTTP traffic on one's own network. How about blocking certain methods of tracking, data collection and advertising. Apparently it includes disabling HSTS.

Let's be honest. Google is an undisputed king of "mischief". The stakes for Google mischief are much higher and there have been too many fines to count. Consider the latest. How many people deploying their own proxies get fined $4B. (Arguably, an issue of "control" was at the heart of that decision.)

https://www.theregister.com/2022/09/14/european_court_fines_...

If the proxy is "legitimately deployed" then why not stay out of the network operator's way. Let them have control. Give the option to cede control to Google instead of making it a default.

I use HSTS for commercial, nonrecreational web use, when I have to use a "modern" browser. That is a small fraction of total web use for me.

Here, try this link in Chrome: https://untrusted-root.badssl.com/. When you click Advanced, it tells you "the website sent scrambled credentials that Chrome cannot process". And beyond that there's just no button to bypass it. You can't visit the site. (Sure, there's probably a chrome://flags or --disable-web-security way to bypass this, but that's well beyond the average user's comfort zone, as well it should be.)

I tried on a blank profile to make sure there were no strange settings.

EDIT: It turns out there is a "visit this website anyway" option in Safari, but it is not a button, it's a link which you only notice when you click "Show details" button and read the warning.

[1]: https://twitter.com/cyb3rops/status/1561995926666985472?s=20...

Not sure how that matches.

The user mistake is just clicking "advanced" then "proceed". I know all my family members would do that without questioning.