Hacker News Reader

Comment by sheerun | Hacker News Reader

From my experience, non-tech people just leave browser defaults. I'd argue this is better than letting them to use public wifi without VPN. If you really care about security you won't use it, of course

View on HN

Public Wi-Fi in the world of HTTPS is not exactly terrifying.

> Public Wi-Fi in the world of HTTPS

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

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

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

Fuck, HTTPS was already popular by the time I went to college. That explains everything.

I credit the fact that basically nothing was encrypted over the wire when i got into computers in the 90s for learning how protocols work.

To be fair this needed HTTP and WPA(?) lol. Old school wifi let you see everything every other client sent.

Is your friend Samy Kamkar?

Plus, Firefox is soon implementing HTTPS-Only by default if I remember correctly. What was it, maybe 2016 there was a big push for SSL and the majority of the web, even login and payment pages, were HTTP? Now only a small percentage of the web isn't HTTPS. I have HTTPS-Only enabled in Firefox and rarely do I have to click the 'Continue Anyway' button to browse an HTTP page. For most general users that only use popular services, I'm sure it's even more rare.

Its so easy, even a dummy like myself can grab a cert for my self hosted services. I dont give any HTTP only sites any slack

I have a site from 1997, pure html, with drivers, install disks, documentation for computers from the 80s/90s.

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.

> with drivers, install disks

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.

> Depending on what the drivers are for, you may be a prime candidate for MitM.

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.

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

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.

> 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.

Given that HTTP without TLS can provide backwards compatibility while anyone and their dog is advocating for deprecating TLS versions and them being too complex for most people to maintain on their own, I respectfully disagree that plain HTTP was a mistake.

Seems ,like since inception internet protocols was designed with foreseeable security implications, Gnunet is project is attempting to solve this

The site contents don't necessarily matter.

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.

That is fine. The site itself is safe. Accessing it over untrusted transits is not. What has changed since 97? Well, attacks became far more sophisticated, and the transits that people access stuff over became far less trustworthy.

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.

You are hosting executable data of some kind on a non-authenticated protocol. That's totally not dangerous at all. A MITM definitely couldn't cause any damage by altering executable data in transit on unsuspecting users. This has never happened to anyone.

>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.

It is all fun and games until one of the downloads from your site picks up malware in transit and the user goes "why did this web admin infect my computer? Sue!"

This genuinely happens a lot in the 2020s.

I think of you say "genuinely happens a lot" you should give some examples, because this seems odd to me.

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

Ok since it happens a lot can you cite it happening in 3 different occasions since 2020?

> This genuinely happens a lot in the 2020s.

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

Particularly for low-volume sites like the parent post.

Please provide citations for those lawsuits.

Not caring about whether some segment (possibly even a majority) of users can or are willing to jump through hoops to access your site is a valid choice, just like publishing through gopher is. You do you.

You could host hashes of the downloads on an https page. Should be quite simple. Malware can still work on a computer without a built-in network stack and if users are getting downloads onto that computer, then data can leave through the same means.

Putting stunnel Infront of that site and opening 443 is about a solid 30 minutes of effort

And set up certbot/whatever..

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.

Set up a gopher mirror too :)

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

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

No one is forcing you to use TLS. Do whatever the fuck you want, it's your site?

http://n-gate.com/software/2017/

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.

> 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.

I keep my site HTTP for compatibility and accessibility.

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.

Recently I noticed that FF doesn't even let you accept invalid (meaning no longer recognized as valid by FF because they changed the rules to requrie SAN) certificates for HSTS-enabled sites. The bug report's response was that the HSTS standard specifies that. Fuck that, the users should always be the one in control of such decisions in the end.

You forget exactly how much the government felt they got out of just knowing whom was talking to whom, not even bothering to collect the data of the conversation itself.

Now they only have to subpoena/hack/partner with microsoft for that

Microsoft was one of the first companies to sign up for PRISM [1], doing so in 2007. I think there's a subconscious feel among many that because the media stopped reporting on these things, that it stopped happening. PRISM never ended, and almost certainly has only expanded and grown even more invasive and brazen largely owing society's apathy towards what Snowden revealed.

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...

You can learn a lot about a person based on the IPs they visit. HTTPS/SSL doesn't protect you from that.

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.

Public wifi and bluetooth detectors all over is whats scary, as most public wifi is used by phones, not machines and who the hell is running edge on their phone?

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

What bluetooth devices are you concerned are going to leak private data?

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?

>>My iPhone isn't really going to be connecting to random stuff and leaking data

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.

So deanonymizing bluetooth device IDs. I know the Canadian spies used airport Wifis to deanonymize Wifi MAC addresses then set up wifi stations all over Toronto to experiment in tracking people.

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

Correct, but its a more insidious web on this level...

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?

yeah but im pretty sure 99% of the population just clicks past those SSL certificate warnings, in part because they don't understand what that means, and in part because there are way too many sites that let their certificates expire.

HTTPS is trivial to break with a man in the middle attack, yes you get a scary warning in your browser about an invalid certificate, but I'd bet that 90% of people will just click through it and ignore it.

I highly doubt this prediction is accurate. Most people will think something is broken and call tech support.

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

Really? Most people? I cannot think of anyone from my family who would even think about it for a second - they would just get annoyed they can't get to their bank website or whatever and just click continue. Also what tech support? Me?

But now there is no button "continue", you have to click multiple buttons, which are not clearly labelled, in order to see the page. I'm sure 90% of people would not even be aware that you are able to continue.

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

In your example, all I had to do was click advanced then proceed(Chrome on Android)

Ok, on chrome desktop there is no way to bypass the security

Yes, there is. I often have to use it to deal with some internal misconfigured site inside the corporate intranet (the cause is almost always that a certificate has expired, when it isn't it's because a host can be reached with two names and the cert matches only one of them, but that case can be fixed by using the proper URL). I have no trouble telling chrome desktop to bypass.

... and I always read the details before proceeding (finding out what chrome's problem with the cert is).

For some type of errors it is possible, for some other it isn't. Check the badssl website and test the various type of bad certs, you'll see.

From my experience working as on-campus tech support in college, most people who aren't tech savvy will quickly give up or look to someone else for help. They will likely not think to click Advanced -> Continue Anyway (unless they have been taught to do that before).

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.

HSTS cannot be overridden. Which bank domain names are you thinking of that are not one of the twelve thousand names on the HSTS preload list? https://source.chromium.org/chromium/chromium/src/+/main:net...

I tried 5 banks (swedish and italian). None of them are in the list. I feel safer now :D :D :D

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

Banks often have awful security systems. Kiwibank in NZ has a "two-factor security" system. All it is is a security questions thing where you click on screen to fill in 3 letters of the hidden answer. The on-screen keyboard makes it secure, you see? Against keyloggers.

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.

handelsbanken.se is on line 163144. (I was a little bit off on the length of the list before)

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.

So this shows that your statement about the security of hsts headers was overblown?

You got me. I wildly overestimated the competence of Eurobanks. I'll never make the mistake of assuming an institution knows what it's doing again.

fideuram removed the phisical tokens for 2fa and moved to SMS, saying that it was because of some european directive… I went to read the directive. It basically said to not use sms and avoid apps in favour of dedicated 2fa devices for banking.

Hsts solves sslstrip, I do not believe it enforces cert pinning. Iirc browsers deprecated cert pinning some time ago.

I've seen HSTS not let me continue without the server having the expected certificate recently, so I think that's still a thing.

That might be because of certificate transparency rather than certificate pinning.

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

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: *

in an HTTP response header, e.g., added via a user-deployed proxy, will clear an "official" HSTS block, allowing the "MITM" to proceed.

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.

Thanks for the informative post.

I'd argue the invalid certificate would only get the middle segment of semi-tech literate but security illiterate people. So maybe a lot of people on this site . The average user, based on my observations, tends to take these warnings very seriously.

Have you looked at what the UX is for invalid certificates in 2022? It's not like ten years ago where you just click enough times and "visit anyway".

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.)

Uh I just have to click "advanced" and then "proceed anyway".

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

I clicked that link - in Chrome on Android all I had to do was click "advanced" then "proceed anyway". I have never changed any flags or default settings in this browser.

I just tried to open the site in Safari, and there's no "Continue anyway" button, only "Go Back". I did not change any default settings, because I use Firefox as my daily driver ( and Firefox does have "Accept risk and continue" button, but I think the word "risk" on it is scary enough for many people to not click it).

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.

A slight digression, but I read[1] recently that typing “thisisunsafe” while the tab has focus is sufficient for bypassing the warning.

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

it's not so easy to click through, because I often try and it really seems like they don't want you to, the dialogs are very confusing.

>trivial >requires user mistake

Not sure how that matches.

It's trivial to set it up for the attacker. If you have a Linux laptop you can set up a redirect for all the traffic on the network through your machine with two commands, then there's plenty of tools that will intercept any incoming HTTPS certificate, replace it with your own, the decrypt the traffic. It sounds like a lot but anyone can set this up in about 15 minutes - that's why I said it's trivial.

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

Maybe teach them to not do that.

What percentage do you think of all network traffic that Edge handles is 1) Over wifi? 2) Over unencrypted wifi?

From my experience, tech people with non-default browsers can't use the internet :(

We had recently hired new programmers, 2 freshgrad and 1 junior. All of them use edge on their personal laptop and I didn't notice extension button anywhere.

Reply on news.ycombinator.com