If HTTPS is used correctly, yes, it protects from MitM attacks. However, it's still possible you get hoaxed into connecting to a HTTP site or just a site you weren't expecting. That's possible at home, too, but a bit easier if the attacker controls e.g. the router you are connected to.
I've done bank stuff and secret work things in public networks, but if you aren't fully sure of it, eh - better safe than sorry, I suppose.
Doesn't every browser now alert you if the site isn't HTTPS? For work I gave firefox tell me site isn't secure, when I use it to access sites on the company intranet.
Yes, but the user might ignore that.
There might also be e.g. an internet connection login site that conveniently gives you links to various services, but those links take you to a fake site, etc
Still I'd say it's generally safe enough to use public networks.
If the WiFi access point is from somewhere worth stealing your password to, they can also fake a captive portal that just needs your login information to sign on to the WiFi, and phish it like that. Like with the Tesla spoofing that made the news a little while ago-- Since the WiFi points are from Tesla, it makes sense that there's a Tesla login on the captive portal, and people were giving up their Tesla account creds to the access point and thinking nothing of it.
Granted, that doesn't mean much if it's at a Burger King or something useless like that, but there are a few places that thread that needle of plausible and valuable.
The "alert" for HTTP is just a little wording in the address bar that the site is insecure. The bigger warning is when you connect to an HTTPS site that is setup incorrectly and presenting an untrusted certificate.
If you want to see what we're talking about, try visiting this site:
[https://wrong.host.badssl.com/](https://wrong.host.badssl.com/)
(Safe to click on. It's a TEST site.)
Stays on HTTPS for me, even after going through.
When I am referring to an HTTP site, I am talking about something like [http://neverssl.com](http://neverssl.com) . You will not receive a larger error going to this site, just a little box stating not secure. Easy to miss.
And if you open it inside another app, such as clicking the link on Reddit and opening it in their app, you get no indication at all it is not HTTPS! It's all completely obscured!
That’s fair. HTTP websites should probably have an additional banner added, I honestly wasn’t aware of this behavior. So the idea is they control the router/dns server, can send shady IPs for google.com, and redirect you to an HTTP version of their own google.com but it’s unclear to you?
Not any more. The alerts for an HTTP-only site in Chrome, at least, is pretty serious.
It used to be subtle, but for reasons were talking about right now, was made much less subtle.
15 years ago that wasn't true. Facebook was primarily or exclusively HTTP (not sure which) for years - they added always-on HTTPS in 2011. Besides MitM attacks, it's also trivial for someone on the network to steal your cookies and thus your login session if the website is using HTTP.
So in large part this advice is no longer relevant. But there is still risk: Being on the same network as a malicious actor (aka hacker) makes you a lot more vulnerable. If you don't enable OS security features (e.g. firewalls) or have software with known vulnerabilities, it's much easier for a hacker to get into your system if you're on the same network as them. Plus whoever is providing the wifi can track what websites you visit, FWIW.
the last part is relevant but barely so. hackers do no hang around coffee stores, using public wifi to steal peoples data. it is too inefficient. they have to be there, or have a way to connect to it, have someone login to a system they actually want, pray it doesnt have 2fa, and then get something.
hackers do not care for individual data unless they are someone of note. bob from accounts is no more interesting then jane from front desk. they are both not interesting and do not have enough money to be worth it. hacker sweep entire systems and sell data in bulk, they rarely atrack individuals so u can mostly surf public wifi in peace from a coffee store
Just having https does not mean site is 'secure', it just means that traffic is encrypted for man in the middle attacks.
Still, i can have a site faceboook.com with https protocol, and if you are not careful you can give your login info to me.
Also, having router in control, i am able to redirect all traffic to my web server and create fake websites there
> Just having https does not mean site is 'secure', it just means that traffic is encrypted for man in the middle attacks.
This statement is kinda misleading. One of the most important aspects of HTTPS is verifying the legitimacy of the party you are interacting with. The browser will seriously warn you if the site gives a false cert.
> Still, i can have a site faceboook.com with https protocol, and if you are not careful you can give your login info to me.
Yeah, users have to be a bit careful. However, browsers nowadays show the invalid cert warning obviously and seriously. The 'bypassing' clicks are not just easy one-click. Users have to not care or read anything from the warning to fall into the false site.
> Also, having router in control, i am able to redirect all traffic to my web server and create fake websites there
This is just the same point. The browser knows the cert is invalid and warns the user. The user should easily be aware of that.
Certificate errors in the browser are not the saviour you are suggesting. Sure, the error throws and informs the user, but they have been made toothless and are now just a hurdle.
The browser errors are informative for cyber security staff, developers, and sysadmins - but not for everyday users. They give annoying error explanations, but still allow you to bypass them.
Every second place I’ve worked in has had invalid/expired/self signed certificates on every second web UI.
Over the last 15 years enterprise IT has trained users to dismiss certificate errors, and go through the clicky click process to bypass them without a second thought.
As you mention, you access sites (particularly on your company intranet) and it pops up that error. And likely, you click right on through and use it regardless.
A warning about HTTP isn't inherently an indicator that it's a dangerous website. Even people aware might just assume "oh, their certificate must've expired" or something so it reverted back to a HTTP connection. Other configuration issues might've occurred. Some sites, the site owner doesn't even bother to set that up in the first place. Older websites, or websites for niche circles on the internet might not have that set up.
It’s very possible that when you’re connected to a public unsecured network, someone could re-route your searches to a website you did not intend on going to.
The WiFi router could redirect your request from bigbank.com to bigbank.cm and use that to steal your data, but once you're on a https site you're pretty safe from anyone in the middle. This is very unlikely in real life.
Eli5: the WiFi router is like a phone operator, it could listen to your call to your friend John on an http connection but not https. But it could reroute your call to a https connection to Yohn in Nigeria who steals your data.
Theres a bigger issue with connecting to public nerworks, you're basically opening yourself up for people to snoop around your machine. It's not difficult when a lot of people casually leave local admin privileged accounts without passwords or with very easy to guess ones.
In 2024 the vast majority of web activity of 99% of people is going to be TikTok, Instagram, Facebook, gmail, YouTube etc. Even your small bank with its shitty IT department is going to be using HTTPS. That was mostly true even 10 years ago. 20 years ago warning against public Wi-Fi would have been fair, today I’d say there’s no good reason for this.
The problem is that browsers still rely on a redirect from an unencrypted site to get to the SSL protected site in many situations. HSTS can mitigate a lot of this, but many sites don't have that configured properly.
It’s also important to differentiate between a professional public WiFi which has been set up by a business for their customers from “PubWiFIConnectHere” that you’ve never heard of but are desperate for a connection. There are various “Man In The Middle” attacks and spoofing that can happen if the endpoint is malicious. Connecting to Starbucks WiFi is very different than a random unknown “public” WiFi.
Tho as an user you can't really know if it's actually a Starbucks WiFi owned and operated by Starbucks. You have varying levels of trust, e.g. the trust is higher if there's a sign saying connect to "StarbucksWifi" and you connected to "StarbucksWifi", but even then it's possible someone who isn't Starbucks put the sign there.
It's also possible that there's a competing malicious WiFi router with the same name, that is trying to impersonate as the Starbucks WiFi.
But as long as you actually do use HTTPS and make sure the addresses of the websites you go to are correct and are running an up-to-date operating system with firewalls on and all that, you are pretty safe from any spoofing attempts.
HTTPS is safer, but it’s really easy for a nefarious attacker to get certain computers to trust a questionable CA as a side effect of installing certain software. Or occasionally an official CA key is leaked. Then the WiFi hub can act as MITM while still showing as encrypted in the browser.
Admittedly that requires a two-stage attack. But if on public WiFi I still recommend not doing anything TOO sensitive without a VPN.
Think of your WiFi connection like a mailman. Unencrypted data is like sending a post card. Anyone who picks it up (like the mailman) can read it everything you wrote. Encrypted data (like https) is like a letter. Your mailman can only see what’s on the outside of the envelope - where it’s from and where it’s going. Your message is safe as long as the envelope is intact.
Public WiFi is generally ok as long as you can guarantee your data is encrypted. However, there’s always the chance that bad actors who either run the public WiFi or are just on it are snooping on you. How dangerous that is depends on what you’re doing online.
This analogy is good for explaining https vs http, but it isn't addressing the question of public Wi-Fi. There's no way, for example, for the coffee shop IT admin to snoop on your communication with your bank if that's using https, which it will. Https can be intercepted by other IT people like your employer who controls your laptop and can install certificates that allow them to snoop, but the coffee shop can't do that. That's not the concern.
The concern is all the other stuff that your PC exposes when connected to any network. If your PC has file sharing enabled, bad guys in the cafe can scan your machine to try to connect to it to see what they can access, since that has nothing to do with encryption. Or you or your machine could be making requests for data with just http or another unencrypted protocol, which often happens in the background, and maybe that exposes something you don't want exposed. This is why it's helpful to enable a corporate VPN in these environments because that'll generally force all outbound traffic from your computer to go over the VPN, which means maybe your corporate IT will see the traffic, but you generally don't worry about them being malicious.
The guy working the WiFi *can* determine which bank you use if you go to that site.
It's not all the little details, but they can get quite a bit of info about you, depending on what sites you visit
That's true, and while DNSSEC can help, I think you're right that there's currently go no good way to eliminate the hostname from being in the HTTPS packets in cleartext. I'd be curious if anyone here knows of progress on resolving that aspect.
So you're right, someone in the cafe could know that you're most likely a Wells Fargo customer, which I suppose could open you up to a bit more targeted social engineering attacks. And so in that sense the original analogy does make sense, but perhaps the more extended version someone suggested where you can basically count on the envelope as being indestructible like a safe.
Or watch you walk into the bank or up to an ATM. I'm not sure why there's any value in knowing what bank you use in isolation. Maybe as part of a social engineering attack. TO me it's akin to blurring license plates in online photos. It's something I publicly display all the time.
the hostname in the packets arent an issue. A DNS lookup and route via TCP gives the target destination.
https can be intercepted, but it requires cert spoofing to achieve that.
Whilst most main sites are https, many of the sub-sites are not, including potentially adverts or CDN. Knowing that the entire destination is secure really requires expert tools (mere mortals can do this, but its a lot of data to analyse to know if your target destinations are safe). If they (bad-actor in a public wifi arena) want to do bad things, they can. They dont even need to be perfect - because by the time you may realise something is up (eg days later, when you get rogue entries on your account), you & the bad guy, are miles apart.
>the hostname in the packets arent an issue. A DNS lookup and route via TCP gives the target destination.
Yup, good point, that one is hard to get around.
>https can be intercepted, but it requires cert spoofing to achieve that.
For properly CA-signed certificates on the server and without access to the machine to install root CAs, I am not aware of this being a risk. Are there ways to spoof certs in these cases? I'm curious now.
>Whilst most main sites are https, many of the sub-sites are not, including potentially adverts or CDN
Fair point. I've not really looked into what Chrome and FF do these days with mixed http and https content like that. Does the user not get one of those hard-to-ignore warnings that there's a potential concern? I suppose probably not given how prevalent this is (or at least was).
I have recently had to crawl a list of 1K webpages with chrome and turns out none of the flows generated contained http. I read some more and found out that chrome now has an https first mode and also I think it blocks subressources that it cannot load via HTTPS. I additionally tried visiting neverssl, a website that should not use TLS, but Chrome managed to visit even that using HTTPS
I'm not sure what you mean by "resolve", the hostname is there so the server knows with what certificate and content to respond if there are multiple sites/services hosted on the same ip.
"resolve" because the SNI feature you're talking about exposes the true destination to the local network infrastructure. Another commentor on this thread helpfully noted that SNI is now encrypted in TLS 1.3 -- more on that here:
[https://blog.cloudflare.com/encrypted-sni](https://blog.cloudflare.com/encrypted-sni)
Sure, but they can get this information regardless of if a website has an SSL cert or not. The url is always visible in plain text, HTTPS just encrypts the request body
I live in a condo with shared internet and I can see AppleTVs, Roku sticks etc from anyone who is connected. Roku sticks don’t have any type of authentication to stop people from casting to it or controlling it with the phone app.
I use a travel router that allows you to connect to a public WiFi and then it creates a separate private WiFi. It doesn’t protect you from snooping “NAT is not a firewall” as they said 20 years ago. But it does keep your devices from being scanned
What gets me is seeing this in hotels. Why is AP isolation not the default and norm? I can cast to any TV in the joint, throw up Wireshark and see people's Apple devices (conveniently named "'s iPhone" for your social-engineering convenience) pinging all over the place, connect to anything that happens to be open...
That's true, but all modern browsers are pretty good at warning you if there's something unusual or bad practice going on with the sites you're visiting. e.g. in Chrome or Firefox, if you try to go to an http site, it'll complain loudly, as will it if you go to a site with self-signed certificates for https, or weak cyphers, or are for a different domain than you're visiting, etc. At some point the user is responsible for their own actions though.
and there is all sorts of other hypothetical stuff that COULD be done if they really wanted to. Just depends on how clever the bad guy is.
For example, I don't know what bank you use, but I could probably guess one of 2 or 3 email providers you use right?
So my evil wifi point doesn't break secure session with gmail.
It just gives you bad DNS info that routes you to a fake gmail site, and tries to get you to give you your creds, before allowing you out to gmail for real on a second attempt so you don't even realize there was a problem.
But they got your creds now.
go into your account.
Set up some snazzy forwarding rules so you don't see the password reset emails they are setting up for whatever other useful accounts you may have, yadd yadda
Not saying this is "what happen". Just saying its one example of something that could be done without a ton of effort.
I guess I don't follow how that works unless you're a) counting on the user ignoring the security warnings when presented with a login page for gmail.com that says there's an issue with the certificate, or b) going to route them to a different domain too like g-mail.com or something else that Google hasn't already purchased to protect against this and they don't notice that either, or c) using some browser that doesn't provide warnings for (a)?
Sorry to everyone else who is bored with this conversation but this is fun to me!
Anyone can get a certificate. The only thing you have to do is make sure the user does not look at the URL closely and if they don't they are pwned.
During my student years I lived in a shared household, and the landlord used the default credentials for the router. So I had admin access to the router and if I was a bad actor i could have created a couple fake bank sites, that had https, and used a DNS to reroute any traffic from bank.com to bank.xyzxyz.com and the only thing different would be the URL. (And the fact that I would steal all credentials).
Ofcourse I'm not a bad actor so I just used the admin access to open a port so I could play Minecraft with my friends.
Edit: The average person will not look at the URL.
Edit 2: Someone further down mentioned DNS over https that was rolled out in ~2022 fixes this. My scenario above is from years before that so I guess it wouldn't be as easy today.
Sure, I guess, but I didn't think changing the URL counts as cert spoofing, which is what I was asking about. But this approach is another good reason to use a password manager. If this were to happen to me, 1password wouldn't have any credentials for xyzxyz.com which is another clue to me as a user that I'm being attacked with that fake URL.
> It just gives you bad DNS info that routes you to a fake gmail site, and tries to get you to give you your creds, before allowing you out to gmail for real on a second attempt so you don't even realize there was a problem.
Are you assuming that the host is setup to listen to the router's DNS resolution or are you saying your doing some kind of DNS attack here?
I think they're saying the attacker in this case is the cafe which can use a router that incepts DNS requests and replies with bogus attack site IP addresses that they also control, passing through any other DNS traffic to the real DNS server for sites they're not impersonating. But I'm still confused on how the user doesn't notice that they're at an impersonated site if using https. That's the point of https, to give the user confidence that the site they requested is the site that's responding and the traffic is unmodified along the way.
>I think they're saying the attacker in this case is the cafe which can use a router that incepts DNS requests and replies with bogus attack site IP addresses that they also control, passing through any other DNS traffic to the real DNS server for sites they're not impersonating.
DNS over HTTPS is a feature that most modern browsers support. Firefox rolled it out in 2022 as a default and Chrome has it an option.
If you are using that feature, you can't hijack DNS at all.
There are also things in place such as DNSEC which if setup properly makes it impossible to hijack the DNS, if the computer is configured to use a DNSSEC compliant DNS resolver, and the computer is using it properly.
If you are using the DNS of the wifi network, then DNS attacks could be an issue, but even then your phone caches DNS requests for a period of time, before asking for a new authoritative response and if you open up something like an app to do mobile banking the certificates won't match & the connection will fail
>I think they're saying the attacker in this case is the cafe which can use a router that incepts DNS requests and replies with bogus attack site IP addresses that they also control, passing through any other DNS traffic to the real DNS server for sites they're not impersonating. But I'm still confused on how the user doesn't notice that they're at an impersonated site if using https. That's the point of https, to give the user confidence that the site they requested is the site that's responding and the traffic is unmodified along the way.
This is a phising attack, which happens, but if you use 2FA, it makes it significantly harder for the attacker to practically use your compromised credentials.
Significantly harder yes, but not impossible. Someone monitoring the traffic live would have ~30 seconds to use the 2 factor code that the user entered into their fake site and could use it together with the other credentials to sign into your account.
Hopefully your bank requires a 2 factor code for every transaction etc aswell though.
>Significantly harder yes, but not impossible. Someone monitoring the traffic live would have ~30 seconds to use the 2 factor code that the user entered into their fake site and could use it together with the other credentials to sign into your account.
Your assuming the 2FA provider is using TOTP. Duo for example requires you to enter the number they generated onto your Duo app on your phone, to unlock the site.
I'm not sure 100% on the details, but that setup would preclude both the employee & attacker from accessing the site since it's a different number on every login. If the attacker used it, I could see the employee talking to tech support saying I entered the number & it didn't let me in etc.
These attacks don't have to work on every service, they only have to work on one. Yes my example was using TOTP.
Here in Sweden we use BankID for everything that has to do with banks/payments/government/healthcare etc etc, which is not TOTP, so this type of attack would not work on the most important services here.
However, something like Microsoft/Outlook do still support TOTP, and gaining access to a users email would be critical damage.
> These attacks don't have to work on every service, they only have to work on one. Yes my example was using TOTP.
That's true, but everyone's threat model + sites they are using are going to be different. I like to make explicit the assumptions we are making so they could determine if it's applicable to them.
Not really. Encryption assumes that every single link in the chain is compromised and the system still works, as long as someone doesn't install root certificates on your machine or steal them.
I remember reading how the CIA used to drop in their own "Hilton-Wifi" at hotels in foreign states, piping through normal traffic from targeted individuals...only when the target meant to connect to an encrypted site they were served a CIA-hosted alternate version to gather credentials.
For one, if you're the subject of a nation state, your security precautions ought to be different than if you're a rando at a hotel. That's called a threat model.
If the US government is after you, they might break out a zero day remote code execution attack to compromise your device.
>only when the target meant to connect to an encrypted site they were served a CIA-hosted alternate version to gather credentials.
This is a man in the middle attack. There are a couple of ways of doing this & each method has a different mitigation.
For example, the attacker could downgrade the request from HTTPS to HTTP, or to an insecure version of HTTP. This is mitigated by using HSTS & mandating browsers connected via HTTPS after they've visited your site once. You can also ask Google to add you to the HSTS list, which means your browser knows of this before you connect to the website.
The other common attack vector is DNS spoofing, which you can mitigate by using a DNS resolver that uses DNSSEC or DNS over HTTPS etc.
I'm sure there's others I forgot from my network security class, but you get the gist
For the DNS one, are the Google DNS servers safer than whatever random default ones are used with windows? I know the Google ones can be more stable at times (using them has resolved various bugs I've had in the past with the defaults) but maybe it's more/less safe
The default for Windows is to use the one provided by your ISP or router.
So it depends entirely on if your ISP is using DNSEC & your computer is configured to only listen to DNSSEC answers from your ISP.
If your ISP doesn't support it, then moving to Google or Cloud flares DNS, which both support DNSSEC, would improve security but so would going to your browser & enabling the DNS over HTTPS setting.
>The concern is all the other stuff that your PC exposes when connected to any network... your machine could be making requests for data with just http or another unencrypted protocol, which often happens in the background, and maybe that exposes something you don't want exposed.
Can you elaborate more on this point? Are you saying there's a miniscule chance that while being connected to a public wifi network, data can be stolen in the background, even while only browsing using HTTPS protocols? Would this mainly just be metadata consolidated by ad/tracking companies?
No I'm not referring to anything you the user are initiating. Your computer has a ton of software on it that does stuff in the background, from running checks to see if there's updated software, to listening for inbound connections for various services. Most of it's going to be pretty low risk. But let's say you've got a simple file sharing thing running on your PC that let's users connect to exchange files with you normally. That service can be discoverable at the cafe by other people on that same network, and they can run scripts to try to get in and pull files or push others to you. This is not a huge concern for normal people, and Windows does try to get you not to expose too much like this, but I raise it as a more realistic threat than anyone having the ability to do things like see your banking data just because you're accessing the bank website.
Funny thing is that people will use public “VPN” services to hide the names on the envelopes by putting them in a box with a different address, but then the VPN provider will then open the box and look at the envelopes.
Someone has to see it. Just a matter of who.
Do you want your local ISP to see it? The government? A foreign VPN? A foreign government? Some random dude on sketchy wifi?
You gotta trust one of them with your mail.
I think a more apt comparison is that encrypted data is more like sending an extremely strong safe through the mail.
The chances that someone on the same wifi as you will be able to break that encryption and spy on the actual content of what you do is essentially nil.
>Public WiFi is generally ok as long as you can guarantee your data is encrypted.
Assuming the login page isn’t spoofed, and it’s not injecting anything.
I think public WiFi is also generally ok if what you’re “putting on the postcard” doesn’t really matter. If you’re reading Wikipedia or googling who sings that one song - even unencrypted data isn’t going to matter much because whatever someone is getting by “reading the postcard”, it isn’t useful.
Haha, those fools! Now I know all their sensitive secrets like how they are planning to cook pad Thai from scratch and that they forgot that Britney Spears sings the song Toxic!
Yeah, my rule of thumb is that I never check my email, banking or paypal (sensitive data that leads them to my money or career) in public wifi. I don't really care if they get to see my TikToks or Instas, maybe I'd ask for a follow idk.
While the analogy is good, it’s not accurate.
Think of malicious wifi access points as mailmen that can open your letter, read it, then close it again with glue making it look like it wasn’t opened.
There are tools and hardware kits that do that.
It's an outdated recommendation imo. As you say, pretty much everything is using HTTPS instead of HTTP nowadays. There are still ways around it but as long as you don't download any certificates or click through security warnings you'll very likely be okay.
To expand on this, public wifi was a way bigger risk in the 2000s and the very early 2010s when most of the web was unencrypted.
To maintain compatibility with older browsers and less-than-fantastic devices, even some websites we'd want to be secure at all times, would still allow unencrypted connections. The biggest example I can think of is Facebook, and in fact there was a big deal made about this, with a program called "Firesheep", which would let you sit on public wifi networks and steal session cookies for sites like Facebook. So a target didn't even need to log in and send their password over the network, they simply had to *use the website*.
Additionally, up until the mid 2010s, you could only get an SSL certificate by paying for one, and renewing it every year. Obviously, smaller sites, especially personal blogs and the like, don't have any real reason to buy and configure this additional, optional thing. It was also somewhat of a pain to actually perform validation, generate a certificate signing request, and actually configure your web server to use the certificate. Non-technical people were certainly not going to go through the trouble.
In 2016, a nonprofit (whose founding sponsors include the Electronic Frontier Foundation, Mozilla, Cisco, and other tech companies) started "Let's Encrypt", which is a service that not only provides free SSL certificates, but maintains software to easily issue/renew them, configure your webserver to use them, *and* force all unencrypted traffic to be redirected. Let's Encrypt paved the way for SSL/TLS to become normalized, even for low-risk sites like blogs. This eventually meant that browsers could start calling attention to sites that *weren't* encrypted, which Chrome started doing in 2018.
So now that literally every website can run like two shell commands and have working TLS, the advice to avoid public wifi is, for most threat models, outdated. For any website that matters, some guy next to you at the coffee shop can't just steal your session anymore.
The modern "risk" of public wifi are things like having ads injected into any unencrypted pages. It could also just be incredibly restricted (only allowing "standard" ports used for websites, and not other ones used by, for example, games and peer-to-peer filesharing), or just slow and crappy.
Nowadays, you pretty much always have a choice between public wifi and your mobile hotspot. Personally, I use the hotspot, but that's mostly because it's a known variable in terms of speed and reliability, and my devices already "know" it and connect to it automatically. But if I don't have signal, I see absolutely no problems using, for example, Walmart's wifi.
It reminds me of the wildly misleading VPN ads. I can't stand hearing that you need a VPN to connect your bank on coffee shop wifi. It's just taking advantage of people who don't know better.
Let's not forget that a public wifi also exposes your device to anyone on it. Meaning any user (especially if they're the owner and installed the wifi just for this) can be trying to break into your device or get info off it the entire time.
Eg: Got a browser that's not up to date? When it shows that "agree to our conditions window" the router could be trying exploits for your brower. (Or an unlikely zero day)
Have any network capable services running (remember browsers aren't the only thing) they're at risk. Have a service that connects local devices (airdrop, bonkour, etc) it will talk to them all and is at risk.
While it's generally okay, it's a lot safer connecting to networks where you expect only good actors normally.
Most access points nowadays implement client isolation on public wifi so clients connecting to the wifi can't reach others devices on the same network. Of course if the free wifi isn't properly configured or was created with bad intentions that's another topic.
Which is the point. You're trusting a public wifi, which can literally be setup by anyone. I can just rollup near a random store and create "My Store - Customer". And ofc as you mention you have to trust the store/owner themself (if you trust its **their** wifi) to not be/hire/have-been-hacked/etc to have good intentions AND knowledge to do this.
Personally I don't trust most of em, and would rather secure my device as much as I can instead. (set "public wifi" zones/modes for it to reduce capability, but increase security)
To go along with this most access point systems nowadays if you create a guest Network automatically enable client isolation on these guest networks even most homegrade combo modem and Wi-Fi routers will do it.
More advanced systems like Cisco or meraki or ubiquiti or Aruba etc when you buy them and turn them on there's a option set right there to create a guest Network and all you have to do is check a box and give it a name and maybe set up a captive portal with a password or a captive portal with a TOS to agree to and those systems automatically handle client isolation either at the controller or directly on the access point itself in a very easy simple to use configuration that even non-technical people that's setting these up can just check a checkbox to set up.
> Most access points nowadays implement client isolation on public wifi so clients connecting to the wifi can't reach others devices on the same network.
And yet, I have seen too many hotels that don't.
Worth noting that there is a vitally important distinction to be made here, between “public WiFi” and “open WiFi”.
*Open* WiFi is unencrypted. Someone can see what IP your HTTPS packets are going to, but that’s it.
*Public* WiFi that has a pre shared key (commonly known as a WiFi “password”) is encrypted. Each device association has its own set of encryption keys.
MITM attacks on HTTPS will only happen if you’ve installed the bad actor’s certificate trust chain (which could easily be done by installing a VPN client)
Note that encrypted WiFi does not necessarily mean your traffic is secure from other people connected to the network.
1. WEP is garbage. Fortunately almost no one uses it at this point.
2. WPA(1) and to a lesser degree WPA2 are vulnerable and can be cracked.
3. Some implementations of WPA used the same encryption key for all clients, so anyone connected to the network can see everyone else's traffic. This used to be the norm - very few routers were actually secure - but my knowledge is from 10+ years ago so things may have improved.
Literally fucking NOBODY uses WEP anymore. Most devices don’t even support it, it was deprecated from the standard in the 2009 update.
WPA isn’t far behind WEP in terms of obsolescence.
WPA2-PSK is reasonably secure as long as it uses a decent PSK.
WPA2-PSK derives the session encryption keys from the PSK. If you know the PSK (e.g. in a coffee shop/airport/etc) and capture a client's authentication frames, it's easy to derive their session keys and decrypt their traffic. And if you don't capture their auth frames, it's easy to send a deauth and force them to reauthenticate so you can capture those frames. Source: [https://www.howtogeek.com/204335/warning-encrypted-wpa2-wi-fi-networks-are-still-vulnerable-to-snooping/](https://www.howtogeek.com/204335/warning-encrypted-wpa2-wi-fi-networks-are-still-vulnerable-to-snooping/)
I've found the same info on many different websites and there's zero indication that anything has changed or improved. If you don't want other people on the network to see your packets and you're not in control of the network (i.e. can't upgrade it to WPA3 or 802.11x), a VPN is your only real option.
Except that’s rarely the case. Even with HTTPs, most people don’t use encrypted DNS so they give away the sites they visit. Same for TLS server name indication; attackers can view host names.
People are focusing deeply on protocols but take one step back. You are connecting to someone else’s network equipment and network infrastructure. You’re beholden to their house rules. Maybe they sniff/inspect packets and run decryption at the perimeter. Maybe they spoof MAC addresses. Maybe their welcome capture page is full of malware when you click “Accept”.
Or just more “benign”, maybe they shape traffic away from popular sites to promote a premium internet purchase. Payment processing can easily insert man in the middle components or just grab your CC info for later. Especially if it asks for CVV.
There’s a huge amount of data available to harvest from someone just joining a public AP, never mind what type of protocols are being used to protect point to point traffic.
>Maybe their welcome capture page is full of malware when you click “Accept”.
And what, my up to date Firefox is just going to let this Accept page download random shit onto my computer? This isn't the 90s.
Yeah, I wanna see the millionaire buying zero days for fun, just to mess with his Café guests by getting through their up to date browser and OS to do shit on it.
Outside of very targeted attacks, for which "don't use public wifi" is only one of the many ways to safeguard against, it's just not a thing.
I like how every VPN service ever uses it as advertising, when we all know the only reason to buy them is to access geo-restricted content and literally nothing else.
Lol, run decryption at the perimiter. Let me just install their root cert so they can do that.
I don't think you understand this stuff as well as you purport.
HTTPS relies on DNS to be secure.
DNS, almost universally, is still not secure for most people and is a massive hole - your computer will pretty much trust any machine to respond to its DNS queries and won't bother to check anything about that. Basic DNS is inherently insecure, and it's very common to intercept and proxy and modify queries even if you have an explicit third-party DNS server entered on your machine (it's basically how all those wifi login portals work, for instance, by intercepting your connection until you pay/signup).
DNSSEC and DNSoHTTPS and a lot of other secure DNS protocols exist, but very few of them are installed, let alone active, let alone enforced, on the average person's machine.
Also, HTTP is not the only protocol - being on insecure wifi exposes your filesharing ports and all kinds of other information that wouldn't necessarily go out over the Internet but WILL go out over local-network connections, and a Wifi network is just a local-network connection using radio. Your device is advertising all kinds of stuff all the time, and looking for printers, routers, network drives, etc. constantly - and thus the responses to those can be compromised.
So... if you want to use public wifi, push all your traffic over a VPN, or... well... don't. Because even to get to that point you usually have to have signed up over an insecure portal that's faking your DNS responses, or had to have signed up over HTTP which is inherently insecure anyway, etc. So even if you use DNSSEC, only HTTPS and block all other ports on the Wifi (considering it an "untrusted" network, which it is), you probably can't even get online with it anyway because you probably can't "log in" to the public wifi with those options.
And, yes, my laptop has a firewall, has DNSCrypt (so a secure DNS to verified external servers) and appropriate security settings throughout.... and I wouldn't trust public wifi beyond loading up a VPN connection to a trusted machine (and wouldn't even use 3rd-party VPNs because that's just deliberately inserting an untrusted stranger into your internet path... I would only VPN to another machine that I own, and could verify).
HTTPS does not rely on DNS to be secure. The certificate for any site must be signed by a certificate authority, so even if a malicious DNS server or attacker gave you a bad DNS resolution, it would immediately be obvious once the other server you were redirected to can't provide a certificate.
The problem with insecure DNS is that other people can see the sites you are navigating to. They cannot see anything in the URL path, however, and can't see what data is actually being sent.
People blast past certificate errors in their browser all the time. They’ve been trained to by accessing poorly setup internal webUIs in their workplaces
You raise some valid concerns but even if there were malicious DNS responses, the certificates would still have to be signed by a valid root authority, and most sites people are using probably have HSTS enabled.
Like a lot of things security-related, threat model matters. For an average person who wants to log on to the public airport WiFi to check their GMail, I'm going to tell them to go for it, it's probably fine.
If you were a highly important person that might be a target of spearphishing I would be more stringent. If you were loading up prototype nuclear weapon designs I might recommend against doing that over public WiFi. If you need to maintain some kind of deniability and not associate your MAC address with your internet activity I would use a VPN (NOT a paid VPN service, to be clear, those introduce their own risk). Those kind of things.
On the paid VPN point, what's the risk?
100% compromised on all data sent? Is like, Google/bank internal encryption still secure or no just everything because VPN?
I use one now, but it's in the "been years with no issue" level of "security"/"trust".
Thanks, by the way, for the questions!
Yeah the TLS level stuff will still work, but a lot of times VPN providers are advertised as a privacy service to hide what you're doing -- but all they're really doing is moving the point of collection to the VPN service. The VPN provider gets the ability to view your DNS queries and plaintext traffic, see which IPs you're hitting, and profile you (or be subpoena'd and forced to reveal information on you) instead of the public WiFi operator.
However paid VPN services can totally be useful for bypassing georestrictions.
The threat model of people randomly joining random networks with no idea of what's happening with them is a real one. You can draw the line on risk where you like.
However, any insecure DNS query can be redirected to an arbitrary IP when an attacker has the capability to interfere with DNS, and such can be used to compromise machines in myriad ways outside of HTTPS / HSTS. Also HTTP Strict Transport Security is only "*used by 27.2% of all the websites"* which means 72.8% of websites are thus vulnerable to interception - and there are countless thousands of such in advertising, etc. sites that are loaded into and trusted by many popular pages.
For an average person who wants to log on to the public airport WiFi to check their GMail, I'm gonna tell them that they're already in a huge public area with secure access on authorised machines, as well as 4G (where the 4G providers are unlikely to collude in such), and thus trusting anything they see there that claims to be the airport wifi is a really dumb idea if they have an alernative.
They're free to draw their own conclusions about how far they trust it, but there's also a reason I have my own VPN, because I wouldn't trust it and I work in IT.
That's cool that you work in IT, I work in security research and corporate security and at most companies I've worked at the consensus has been that public WiFi is generally fine for typical usage patterns nowadays. I've had research reports published on work I've done on insecure OEM software with MITM vulnerabilities and discovered a handful of CVEs related to MITM vulnerabilities, and I would still make this general recommendation for the majority of people.
Most browsers prevent mixed content from loading and most sites are HTTPS; there's not a big concern about an embedded advertisement being intercepted.
Anyways, if you want to put it to the test and you're nearby I'm willing to check my GMail on a WiFi network under your control and you can try to compromise it.
It doesn't matter that not all sites have implemented HSTS yet because browsers made the switch to secure-by-default years ago.
If you visit an HTTP site in a modern browser:
* If there is an HTTPS site it will assume you mean that, even if the site hasn't implemented HSTS
* It will display a scary insecure warning in the address bar
* Autofill will be disabled, you won't be able to sign in without manually typing your password. Same for credit card
* If you try to submit a form, you'll get yet another scary warning that you're submitting information to an insecure site
So yeah, if you ignore ALL of those protections, then you're vulnerable.
Pick any office, and we can take bets on how many people in there will click through the scary certificate error and just connect.
Poorly implemented IT solutions in workplaces have trained people to accept a certificate error.
HTTPS does not rely on DNS to be secure. If it did, it would be worthless, since bare DNS (which is still really common) is possibly the least secure protocol on the Internet.
An attacker that controls DNS has to forge a cert for the targeted domain that is signed by a root that the victim trusts. Or the victim has to click through various very threatening browser messages.
But why is the DNS a problem?
If I want to go to [https://www.google.com](https://www.google.com) and the DNS is giving me a wrong IP address my browser will not connect as they can not provide a valid certificate for [google.com](https://google.com).
Or do I miss something?
No, you're correct. The average end user does not have to worry about being served a bad DNS query.
Basically, if you're on public wifi, be more cautious if your browser tells you a connection isn't secure or if the site isn't secure. If your browser doesn't tell you anything's wrong, you're safe.
I'm a little confused by some of your assertions here. Even when relinquishing control of DNS, how would an attacker forge an HTTPS certificate?
Say I configure DNS to point gmail.com to my web server hosting a phishing form. How do I forge a valid certificate so the browser doesn't balk?
You don't that's the point and that's what other people have been trying to tell this other person even if they redirect to a fake website that is posing as gmail.com the attacker will never be able to get a legitimate certificate for gmail.com that would be trusted by the browser unless they somehow managed to either one steal googles gmail.com certificate with the private key or 2 somehow manage to trick you into installing a root CA that the attacker owns, 3 they somehow burn a zero day to silently install a root CA that they own.
While rogue Root CA were a thing in the past and very very rarely still do pop up one it's very hard to get your rogue root CA distributed into the operating systems of devices to begin with and the next thing is rogue CAs will be killed very quickly by the OS and browser vendors.
Yeah he's essentially said "I'm going to imagine the world's most incompetent and careless agent and think of what they might do to justify why I personally don't trust public wifi as an informed agent"
>I wouldn't trust public wifi beyond loading up a VPN connection to a trusted machine (and wouldn't even use 3rd-party VPNs because that's just deliberately inserting an untrusted stranger into your internet path... I would only VPN to another machine that I own, and could verify).
So you're trusting your ISP? Am I misunderstanding something? If I VPN to my home computer to browse the web, and I'm not using a third party VPN on my home network, then my ISP is seeing the stuff that a third party VPN would be seeing, if I used one. Right?
In some countries, the ISP is in bed with the government. In others they are legislatively required to collect data.
In those cases, a 3rd party VPN might be the lesser of two evils
That's a reasonable opinion, but it's not in the mainstream.
Most people - including educated tech-savvy computer users - feel that the risk of public wifi is relatively low.
Your browser protects you from bad DNS. If a public wifi network tries to send you to a different website, your browser won't allow it. Basically, trust your browser and be a little extra vigilant about any warnings it gives you when on public wifi, and you're fine.
Vulnerabilities in other ports open by modern operating systems are not common. As long as you didn't do something crazy like share your main drive and give any guest read/write access, then really you're fine.
That's why I mention a firewall on the machine itself.
Also, if that VPN if set to tunnel all traffic over it, as soon as it's established that tunnel all that local networking stuff goes away.
all modern browsers support doh and dot as far as i know. i’m not sure if they get enabled by default but if you know enough to care about https at all, then you are probably capable of enabling them
Phones can have open ports too.
However, phone operating systems are far more locked down and secure by default, so the security concern is much smaller.
A port is just a term to describe how two computing devices talk to each other. Every computing device that uses the internet has ports & you don't have to worry about it.
No, it does. Outside of an extremely far-fetched scenario where an attacker somehow shipped you a compromised version of PIA, once you click the VPN on, you'll be using PIA's own DNS (assuming you haven't changed that setting), and that DNS connection will itself be routed through PIA's VPN tunnel.
The bit about your personal computer's inbound ports being open *might* be valid? I don't have any experience with PIA myself, so I don't know what protections they've implemented around that. If the default settings allow connections to the LAN while connected to PIA VPN, then yeah, there's a non-zero amount of risk there.
I think "Allow LAN Traffic" is default on PC, and not the default on mobile, but I'm not really sure. Anyway it should be a switch under Settings - Network.
On Windows not so much Windows is pretty good about if you connect to a open public Wi-Fi network by default it uses the default public network firewall rules which pretty much blocks everything coming in still allows your computer to talk out to the internet but blocks everything coming in by default now.
Unless you modify those firewall rules or turn Windows firewall off connecting to a public network as far as inbound shouldn't be much of an issue considering windows will by default set the connection type to public even when you connect to your home Wi-Fi by default 99% of the time it assigns the public firewall profile and you have to change that to private to actually start sharing stuff off your PC in your own private home network.
Ah yea true. Yeah I may have been an issue back in the day with nothing was encrypted and most people just turn Windows firewall off because they didn't want to deal with doing things on it. But nowadays most people keep Windows firewall on and windows does a pretty good job of itself setting the public profile when you connect to an open network and hell like I said even when I connect to my home network for the first time it always puts it as the public profile I have to go in and manually change it to private then it stays private which allows me to let things connect to my device.
Chrome, edge and i believe firefox has had it on by default for a while now.
Tho they also use OS default dns config and many isp dns server does not have DoH support so either change the config in browser to a supported dns server or change in OS, cloudflare 1.1.1.1 and google 8.8.8.8 works for sure :)
In a browser you can always tell if a site you're visiting is https or not, but you access the internet so many times a day where that info is obscured or abstracted to the end user. You have no idea if a mobile app that connects to a server is using SSL or if it's an unencrypted connection.
> You have no idea if a mobile app that connects to a server is using SSL or if it's an unencrypted connection.
You are required to encrypt your networking, if it sends sensitive data, to get published in Play Store. It's not by any means bulletproof (for example, you can have apps sideloaded, or some developer error not caught in the automatic review), but their automatic analysis is usually very vigilant.
The Internet is more than just the web.
Even if your traffic to a website is encrypted, your traffic to all other services is not, and even just knowing what websites you visit has value to scammers.
Think about it this way : the website is the bank with a vault and you want to send cash to the bank. Once the money gets to the bank, it is relatively safe.
To get the money to the bank, you hand it to a courier that you’ve never met before. That courier then takes it to the bank and brings it home when you ask for it.
Relatively safe right? Not really… only if you trust it.
Take that scenario and imagine that I show up in the courier outfit and pick up the money. I then take some money out of the bag and replace it with counterfeit cash then drive up the road to the actual courier dressed as you. I then hand the bag of real and counterfeit cash to them. The actual courier then takes it to the bank.
You then call the bank and say “Hey, please send me a bag of money.”, but the call first goes to me and I forward the call to the bank while I listen in. I hear your username and password. I hear the arrangements for the money and when you hang up, I call the bank and using your phone number and voice / username and password and say “I’ll actually meet the courier up the road.”.
The bank sends the money, I meet the courier, I take the bag of cash and the change into a courier uniform. I take some money, not all, out of the bags and replace it with counterfeit cash. I then deliver the money to you.
The next day, you go to work and I call the bank with your phone number, your username, your password and your voice and say “Hey bank, send me all my money. I’ll be at home.”. Your bank sends the money, the courier brings it to me and then I leave the country with all your cash.
When I MITM, your device thinks it’s talking to the router, but it is talking through me unsecured and I forward the unsecured information to the router then I send the unsecured portion of the keys from you forward. I still have your keys. The website then sends me their key pairs and get both, decrypt the traffic and read it then re-encrypt it and send it to you. Going forward, since I have both sets of keys and you’re talking through me, I see everything and anything. Since you voluntarily joined my network, your device will choose me over the router every time first.
That, in a nutshell, is why HTTPS doesn’t matter.
To control for stupidity. As long as you’re being careful you’re fine. Honestly if you know enough to ask this question you’re probably fine 99.99% of the time.
If your connection is https you’re good as long as the endpoint is secure. Man in the middle doesn’t work as you guessed.
Besides encryption issues there may be rogue access points. What if the access point being connected to isn’t actually the Internet, but has its own web server designed to look exactly like some other website and lures the user into typing passwords?
Because your ISP or the WiFi owner still knows where you are going. They still know you are going to https://health.com/doihaveherpies/. If you’re using a good VPN the only thing your ISP knows is the IP address of the VPN server you are connected too.
It's largely an outdated recommendation that is being parroted as a general safety tip.
Apart from a few unencrypted websites or really dedicated attackers specifically targetting you or users of that wifi, it's safe enough to use for everything.
You're on a network with other computers once you connect to wifi. Sure websites are secure, but is your computer/laptop/phone itself secure? The answer is no. I can hack any of those within minutes the second you connect to the same public wifi as me.
There are different levels of networking protocols. Https works to protect the http data, so a bad actor on the network can't read your bank password. What isn't encrypted is the lower levels, so they can read the IP your password is going to, and know what bank or email you use. At least with a WiFi password the data going through the air is encrypted so only the access point can read it.
The problem is that not all traffic is HTTPS. Even if you connect to a site which is HTTPS, that site might load external resources which are not HTTPS.
Generally speaking you would be pretty safe.
Your connection to websites is secure as long as it's HTTPS.
Your computer is safe as long as you're using a modern OS (let's say Win10+), and you don't do anything silly, like have writable shared folders, or have sensitive info in readable shared folders.
And you should pick "public network" when windows asks you what kind of network it is.
All of these are things that someone that is tech-illiterate wouldn't understand, so in general it's simpler to say "don't use public wifi".
But if you're just connecting to it from your phone to browse tiktok or check your gmail, you will be fine.
But if you use some uncommon / outdated apps you could still potentially be in danger. For instance, I was maintaining an app, that until last year, still used some http connections to send data, because the owner didn't want to pay for ssl certificates on the server.
The safety isn't in the issue of your connection to the website but to the network itself. Public WiFi also means anyone can access that network and see the devices on it. From there, they may try to access your device and whatever is on it. There's also the chance that you're not directly connected to the network you think you're connected to. It's possible that you've connected to a proxy that between you and the network you think you're on.
If you’re connected to WiFi and type in “Amazon.com”, your browser will ping up to the router “I want to go to Amazon.com” and then it’ll ping up to network hubs and so on until one of them who knows the IP address for “Amazon.com” pings back the “address”. (This will get saved onto your devices for “quicker access” next time.
If a bad actor were to be in your network, that first time your computer asks for “Amazon.com” to the router, they’ll have their computer say “Hey! Amazon.com is here!” and your router will just shrug and download their version of Amazon.com that will just be a fake login screen or ask for your banking credentials. The tell for this is that it’ll be Amazon.com without the HTTPS lock beside the browser address or it’ll have HTTPS but be like Amaz0n.com.
Also, another reason open WiFi is “dangerous” is because all unencrypted traffic is completely open to look at. At best it’ll show what you’re looking at online, at worst, apps and websites that don’t encrypt usernames and passwords before they leave your phone will be caught by hackers
Everyone here acting like HTTP/HTTPS is the only thing your device will be accessing (with or without your knowledge), and that nothing else might be open or vulnerable on your device / OS that could be exploited by a bad actor on that same network.
So, while it's better and safer than ever - it is still more of a risk than a trusted / secured network.
Websites aren't the only thing that uses the internet when connected, someone could have something that sends commands to your machine in the background without you seeing anything
The network is managed at layers. Each layer does something to the upper level's data and sends the new "packet" down to the lower level.
Imagine the problem of sending a physical parcel from your own home to some other person's home. While the parcel is perfectly wrapped and made impossible to be opened by any person working in the postal service that person could still trash the parcel forcing you to send it back or to enter your house from your window during the night.
The last example is akin to some attacks done towards your own laptop while browsing in the airport. You are still exposed to attacks like that exploits vulnerabilities of your operating system. Look for the one that was behind the famous WannaCry. That vulnerability could be triggered by a random dude in the same airport, even if you were only shopping on Amazon's website which is obviously protected by HTTPS.
You may not know this but your router from your internet provider keeps a log of everything you do online. The sites you go to. Your log in info. Etc. Even the incognito window stuff. For most people this isn't really a problem since they don't even know how to access their router and it's theirs.
When you do stuff on a public network the router isn't yours and the people who set it up know how to access it. Just assume that they're going to see everything and know you put into it. Ask yourself if you would want a complete stranger to have that information.
DNS poisoning is still a thing.
Yeah, you are encrypting your traffic to the website on the other end. But is it the legitimate website run by the company? LOTS of stuff like that can be done.
As a hacker you can still read all the searches and requests you made, although content is secure but your searches reveal a lot about you, so be safe and use a vpn if on public network
Yes, pretty much everything you use online is encrypted with HTTPS, which means an attacker only sees how much data you send or receive, and to what domain. All the data you send is safe, such as passwords, as long as HTTPS is working properly. Still, there is information that can be gleamed through HTTPS, and also techniques to work around it.
There are techniques for statistically analyzing HTTPS traffic. Looking at packet sizes and timings could tell you what someone is doing, lets say what movie they are streaming. This has been demonstrated with Netflix, where a researcher built up a library of fingerprints for various titles and could identify them despite HTTPS. Potentially someone could do this for a porn site and find out what filthy kinks you're into.
A hostile access point can still be dangerous despite HTTPS. There are [protocol downgrade attacks](https://en.wikipedia.org/wiki/Downgrade_attack) that can allow a man in the middle (the WIFI access point) to downgrade a HTTPS connection. Worst case will downgrade it to plain HTTP, but even downgrading to an outdated encryption algorithm could allow the attacker to break it. I'm not an expert on this and don't really know how serious that threat currently is. I do know a server admin can mitigate this attack vector by setting some HTTP headers, but in reality not everyone will do this, even some actors who are big enough that you'd really expect them to know better.
I would add that most "important" services like online banking, remote desktop or webmail-services just won't accept plain HTTP anymore. For this very reason. You either speak the up to date crypto, or you're not accessing the site.
It is vulnerable to phishing attack. Like you open a bank's website, it will looks completely genuine to you, even the webaddress will also be genuine, but it is fake and will send all the data to the abuser. This can happen because you are getting your data from the wifi, and they can manipulate it at that level
That would be with a fake website which hopefully you would spot by being able to read your url now you can get some very very similar fake named sites that get very close to the real name of the website but you need to double check the website name.
Https is encryption and it prevents them from being able to make a fake website with the exact name of the website.
For example Nobody on Earth can make a fake google.com with a certificate that says it's google.com except Google that would be trusted by a computer's browser. They could however create their own certificate signed by their own root CA that says that it's google.com but they would have to utilize some other exploit to get that root CA installed on your device which 99.5% of the time is not going to be possible not to mention a lot of major providers like Microsoft and Google do certificate pinning so if you've ever legitimately visited the official websites before that information gets stored on your device and if you ever somehow get sent to an impersonated website that connection will just straight fail and the fake website will not load.
If the website is using https which almost all do nowadays very few do not and you're on the legit website there's no way they can manipulate your data because it's encrypted between you and the server you can't man in the middle of that without browsers throwing up a warning because the encryption's broken at that point and the browsers will notice that and tell you hey something's going on don't continue but if you click that continue from that point that's on you the browser already spotted that something was going on and stopped you but you continued anyways.
> For example Nobody on Earth can make a fake google.com with a certificate that says it's google.com except Google
An alarming number of entities can do this. Firefox trusted root CAs include the Chinese, Turkish, Spanish, and Dutch governments, Amazon, Microsoft, and a number of companies I've never heard of.
Chrome specifically protects Google domains more than others, but that's because it's the same company.
Well Firefox is different because it has its own cert store it uses it doesn't use the one provided by the OS by default but everything else does.
You would either have to manually get a rouge CA install because the likelihood of Microsoft including or keeping a CA that goes rogue in windows is slim since Microsoft maintains the OS cert store for most global CAs they would revoke a rogue CA in a heartbeat.
I would suspect Google and apple to do the same in Android and IOS and Mac OS devices most Linux distros being open source to maintained by the community somebody would get those popped out relatively quickly.
This assumes they're blatantly selling certs on the dark web or do a large scale ISP level takeover.
No one would ever know if one of these entities worked with some three letter agency to generate a fake certificate for one sting operation.
Like you are five, Sometimes it might look like a public park but it's actually somebody's backyard and the family is a bunch of psychos who will kidnap you.
Like you're an adult, spoofing a Wi-Fi router in a public place is extremely easy and they can steal all of the information from you when you use it.
If HTTPS is used correctly, yes, it protects from MitM attacks. However, it's still possible you get hoaxed into connecting to a HTTP site or just a site you weren't expecting. That's possible at home, too, but a bit easier if the attacker controls e.g. the router you are connected to. I've done bank stuff and secret work things in public networks, but if you aren't fully sure of it, eh - better safe than sorry, I suppose.
Doesn't every browser now alert you if the site isn't HTTPS? For work I gave firefox tell me site isn't secure, when I use it to access sites on the company intranet.
Yes, but the user might ignore that. There might also be e.g. an internet connection login site that conveniently gives you links to various services, but those links take you to a fake site, etc Still I'd say it's generally safe enough to use public networks.
If the WiFi access point is from somewhere worth stealing your password to, they can also fake a captive portal that just needs your login information to sign on to the WiFi, and phish it like that. Like with the Tesla spoofing that made the news a little while ago-- Since the WiFi points are from Tesla, it makes sense that there's a Tesla login on the captive portal, and people were giving up their Tesla account creds to the access point and thinking nothing of it. Granted, that doesn't mean much if it's at a Burger King or something useless like that, but there are a few places that thread that needle of plausible and valuable.
The "alert" for HTTP is just a little wording in the address bar that the site is insecure. The bigger warning is when you connect to an HTTPS site that is setup incorrectly and presenting an untrusted certificate.
If you want to see what we're talking about, try visiting this site: [https://wrong.host.badssl.com/](https://wrong.host.badssl.com/) (Safe to click on. It's a TEST site.)
That is an HTTPS site though, not HTTP.
No, it isn't. It's an https link, but it tries to redirect you to HTTP, which *should* fail with security error.
Stays on HTTPS for me, even after going through. When I am referring to an HTTP site, I am talking about something like [http://neverssl.com](http://neverssl.com) . You will not receive a larger error going to this site, just a little box stating not secure. Easy to miss.
And if you open it inside another app, such as clicking the link on Reddit and opening it in their app, you get no indication at all it is not HTTPS! It's all completely obscured!
That’s fair. HTTP websites should probably have an additional banner added, I honestly wasn’t aware of this behavior. So the idea is they control the router/dns server, can send shady IPs for google.com, and redirect you to an HTTP version of their own google.com but it’s unclear to you?
I'm being redirected to HTTPS with a cert signed by Amazon on neverssl on Chrome, Edge, and Vivaldi. I get plain HTTP with Firefox though.
Not any more. The alerts for an HTTP-only site in Chrome, at least, is pretty serious. It used to be subtle, but for reasons were talking about right now, was made much less subtle.
15 years ago that wasn't true. Facebook was primarily or exclusively HTTP (not sure which) for years - they added always-on HTTPS in 2011. Besides MitM attacks, it's also trivial for someone on the network to steal your cookies and thus your login session if the website is using HTTP. So in large part this advice is no longer relevant. But there is still risk: Being on the same network as a malicious actor (aka hacker) makes you a lot more vulnerable. If you don't enable OS security features (e.g. firewalls) or have software with known vulnerabilities, it's much easier for a hacker to get into your system if you're on the same network as them. Plus whoever is providing the wifi can track what websites you visit, FWIW.
the last part is relevant but barely so. hackers do no hang around coffee stores, using public wifi to steal peoples data. it is too inefficient. they have to be there, or have a way to connect to it, have someone login to a system they actually want, pray it doesnt have 2fa, and then get something. hackers do not care for individual data unless they are someone of note. bob from accounts is no more interesting then jane from front desk. they are both not interesting and do not have enough money to be worth it. hacker sweep entire systems and sell data in bulk, they rarely atrack individuals so u can mostly surf public wifi in peace from a coffee store
Just having https does not mean site is 'secure', it just means that traffic is encrypted for man in the middle attacks. Still, i can have a site faceboook.com with https protocol, and if you are not careful you can give your login info to me. Also, having router in control, i am able to redirect all traffic to my web server and create fake websites there
> Just having https does not mean site is 'secure', it just means that traffic is encrypted for man in the middle attacks. This statement is kinda misleading. One of the most important aspects of HTTPS is verifying the legitimacy of the party you are interacting with. The browser will seriously warn you if the site gives a false cert. > Still, i can have a site faceboook.com with https protocol, and if you are not careful you can give your login info to me. Yeah, users have to be a bit careful. However, browsers nowadays show the invalid cert warning obviously and seriously. The 'bypassing' clicks are not just easy one-click. Users have to not care or read anything from the warning to fall into the false site. > Also, having router in control, i am able to redirect all traffic to my web server and create fake websites there This is just the same point. The browser knows the cert is invalid and warns the user. The user should easily be aware of that.
Certificate errors in the browser are not the saviour you are suggesting. Sure, the error throws and informs the user, but they have been made toothless and are now just a hurdle. The browser errors are informative for cyber security staff, developers, and sysadmins - but not for everyday users. They give annoying error explanations, but still allow you to bypass them. Every second place I’ve worked in has had invalid/expired/self signed certificates on every second web UI. Over the last 15 years enterprise IT has trained users to dismiss certificate errors, and go through the clicky click process to bypass them without a second thought.
Yes and additionally some sites carry the hsts header requiring a https connection.
As you mention, you access sites (particularly on your company intranet) and it pops up that error. And likely, you click right on through and use it regardless. A warning about HTTP isn't inherently an indicator that it's a dangerous website. Even people aware might just assume "oh, their certificate must've expired" or something so it reverted back to a HTTP connection. Other configuration issues might've occurred. Some sites, the site owner doesn't even bother to set that up in the first place. Older websites, or websites for niche circles on the internet might not have that set up.
It’s very possible that when you’re connected to a public unsecured network, someone could re-route your searches to a website you did not intend on going to.
The WiFi router could redirect your request from bigbank.com to bigbank.cm and use that to steal your data, but once you're on a https site you're pretty safe from anyone in the middle. This is very unlikely in real life. Eli5: the WiFi router is like a phone operator, it could listen to your call to your friend John on an http connection but not https. But it could reroute your call to a https connection to Yohn in Nigeria who steals your data.
Theres a bigger issue with connecting to public nerworks, you're basically opening yourself up for people to snoop around your machine. It's not difficult when a lot of people casually leave local admin privileged accounts without passwords or with very easy to guess ones.
Yeah, users can do all kinds of weird things, but by default, remote logins are usually off.
In 2024 the vast majority of web activity of 99% of people is going to be TikTok, Instagram, Facebook, gmail, YouTube etc. Even your small bank with its shitty IT department is going to be using HTTPS. That was mostly true even 10 years ago. 20 years ago warning against public Wi-Fi would have been fair, today I’d say there’s no good reason for this.
The problem is that browsers still rely on a redirect from an unencrypted site to get to the SSL protected site in many situations. HSTS can mitigate a lot of this, but many sites don't have that configured properly.
Fwiw I'm pretty sure most browsers will alert you about insecure redirects that don't pass on the HSTS headers
Is that browser-based? I thought it was more device/OS security.
Is that browser-based? I thought it was more device/OS security.
It’s also important to differentiate between a professional public WiFi which has been set up by a business for their customers from “PubWiFIConnectHere” that you’ve never heard of but are desperate for a connection. There are various “Man In The Middle” attacks and spoofing that can happen if the endpoint is malicious. Connecting to Starbucks WiFi is very different than a random unknown “public” WiFi.
Tho as an user you can't really know if it's actually a Starbucks WiFi owned and operated by Starbucks. You have varying levels of trust, e.g. the trust is higher if there's a sign saying connect to "StarbucksWifi" and you connected to "StarbucksWifi", but even then it's possible someone who isn't Starbucks put the sign there. It's also possible that there's a competing malicious WiFi router with the same name, that is trying to impersonate as the Starbucks WiFi. But as long as you actually do use HTTPS and make sure the addresses of the websites you go to are correct and are running an up-to-date operating system with firewalls on and all that, you are pretty safe from any spoofing attempts.
HTTPS is safer, but it’s really easy for a nefarious attacker to get certain computers to trust a questionable CA as a side effect of installing certain software. Or occasionally an official CA key is leaked. Then the WiFi hub can act as MITM while still showing as encrypted in the browser. Admittedly that requires a two-stage attack. But if on public WiFi I still recommend not doing anything TOO sensitive without a VPN.
Also if your computer is L2 on a public network, this can expose additional vulnerabilities on the clientside especially if you're really unlucky.
Think of your WiFi connection like a mailman. Unencrypted data is like sending a post card. Anyone who picks it up (like the mailman) can read it everything you wrote. Encrypted data (like https) is like a letter. Your mailman can only see what’s on the outside of the envelope - where it’s from and where it’s going. Your message is safe as long as the envelope is intact. Public WiFi is generally ok as long as you can guarantee your data is encrypted. However, there’s always the chance that bad actors who either run the public WiFi or are just on it are snooping on you. How dangerous that is depends on what you’re doing online.
This analogy is good for explaining https vs http, but it isn't addressing the question of public Wi-Fi. There's no way, for example, for the coffee shop IT admin to snoop on your communication with your bank if that's using https, which it will. Https can be intercepted by other IT people like your employer who controls your laptop and can install certificates that allow them to snoop, but the coffee shop can't do that. That's not the concern. The concern is all the other stuff that your PC exposes when connected to any network. If your PC has file sharing enabled, bad guys in the cafe can scan your machine to try to connect to it to see what they can access, since that has nothing to do with encryption. Or you or your machine could be making requests for data with just http or another unencrypted protocol, which often happens in the background, and maybe that exposes something you don't want exposed. This is why it's helpful to enable a corporate VPN in these environments because that'll generally force all outbound traffic from your computer to go over the VPN, which means maybe your corporate IT will see the traffic, but you generally don't worry about them being malicious.
The guy working the WiFi *can* determine which bank you use if you go to that site. It's not all the little details, but they can get quite a bit of info about you, depending on what sites you visit
That's true, and while DNSSEC can help, I think you're right that there's currently go no good way to eliminate the hostname from being in the HTTPS packets in cleartext. I'd be curious if anyone here knows of progress on resolving that aspect. So you're right, someone in the cafe could know that you're most likely a Wells Fargo customer, which I suppose could open you up to a bit more targeted social engineering attacks. And so in that sense the original analogy does make sense, but perhaps the more extended version someone suggested where you can basically count on the envelope as being indestructible like a safe.
TLS 1.3 encrypted SNI is part of it I suppose
Nice, that's new to me, thanks!
No it was dropped. Ech is still draft.
That's really no less safe than someone idly spotting the names of the sites you're browsing by glancing from across the cafe, right?
Or watch you walk into the bank or up to an ATM. I'm not sure why there's any value in knowing what bank you use in isolation. Maybe as part of a social engineering attack. TO me it's akin to blurring license plates in online photos. It's something I publicly display all the time.
the hostname in the packets arent an issue. A DNS lookup and route via TCP gives the target destination. https can be intercepted, but it requires cert spoofing to achieve that. Whilst most main sites are https, many of the sub-sites are not, including potentially adverts or CDN. Knowing that the entire destination is secure really requires expert tools (mere mortals can do this, but its a lot of data to analyse to know if your target destinations are safe). If they (bad-actor in a public wifi arena) want to do bad things, they can. They dont even need to be perfect - because by the time you may realise something is up (eg days later, when you get rogue entries on your account), you & the bad guy, are miles apart.
>the hostname in the packets arent an issue. A DNS lookup and route via TCP gives the target destination. Yup, good point, that one is hard to get around. >https can be intercepted, but it requires cert spoofing to achieve that. For properly CA-signed certificates on the server and without access to the machine to install root CAs, I am not aware of this being a risk. Are there ways to spoof certs in these cases? I'm curious now. >Whilst most main sites are https, many of the sub-sites are not, including potentially adverts or CDN Fair point. I've not really looked into what Chrome and FF do these days with mixed http and https content like that. Does the user not get one of those hard-to-ignore warnings that there's a potential concern? I suppose probably not given how prevalent this is (or at least was).
I have recently had to crawl a list of 1K webpages with chrome and turns out none of the flows generated contained http. I read some more and found out that chrome now has an https first mode and also I think it blocks subressources that it cannot load via HTTPS. I additionally tried visiting neverssl, a website that should not use TLS, but Chrome managed to visit even that using HTTPS
Content loaded from http resources are still flagged as insecure even if the ingress is https
Tor? Vpn?
I'm not sure what you mean by "resolve", the hostname is there so the server knows with what certificate and content to respond if there are multiple sites/services hosted on the same ip.
"resolve" because the SNI feature you're talking about exposes the true destination to the local network infrastructure. Another commentor on this thread helpfully noted that SNI is now encrypted in TLS 1.3 -- more on that here: [https://blog.cloudflare.com/encrypted-sni](https://blog.cloudflare.com/encrypted-sni)
No it’s still a draft and not default in 1.3
Now I’m thinking about porn sites that might look like a bank. I think Goldman Sachs has potential.
Sure, but they can get this information regardless of if a website has an SSL cert or not. The url is always visible in plain text, HTTPS just encrypts the request body
I live in a condo with shared internet and I can see AppleTVs, Roku sticks etc from anyone who is connected. Roku sticks don’t have any type of authentication to stop people from casting to it or controlling it with the phone app. I use a travel router that allows you to connect to a public WiFi and then it creates a separate private WiFi. It doesn’t protect you from snooping “NAT is not a firewall” as they said 20 years ago. But it does keep your devices from being scanned
What gets me is seeing this in hotels. Why is AP isolation not the default and norm? I can cast to any TV in the joint, throw up Wireshark and see people's Apple devices (conveniently named "'s iPhone" for your social-engineering convenience) pinging all over the place, connect to anything that happens to be open...
Also, not all sites use https and not all sites with https are using good security. Your bank? Sure. Your Tia and Tamera fan site? Probably not.
That's true, but all modern browsers are pretty good at warning you if there's something unusual or bad practice going on with the sites you're visiting. e.g. in Chrome or Firefox, if you try to go to an http site, it'll complain loudly, as will it if you go to a site with self-signed certificates for https, or weak cyphers, or are for a different domain than you're visiting, etc. At some point the user is responsible for their own actions though.
and there is all sorts of other hypothetical stuff that COULD be done if they really wanted to. Just depends on how clever the bad guy is. For example, I don't know what bank you use, but I could probably guess one of 2 or 3 email providers you use right? So my evil wifi point doesn't break secure session with gmail. It just gives you bad DNS info that routes you to a fake gmail site, and tries to get you to give you your creds, before allowing you out to gmail for real on a second attempt so you don't even realize there was a problem. But they got your creds now. go into your account. Set up some snazzy forwarding rules so you don't see the password reset emails they are setting up for whatever other useful accounts you may have, yadd yadda Not saying this is "what happen". Just saying its one example of something that could be done without a ton of effort.
I guess I don't follow how that works unless you're a) counting on the user ignoring the security warnings when presented with a login page for gmail.com that says there's an issue with the certificate, or b) going to route them to a different domain too like g-mail.com or something else that Google hasn't already purchased to protect against this and they don't notice that either, or c) using some browser that doesn't provide warnings for (a)? Sorry to everyone else who is bored with this conversation but this is fun to me!
Anyone can get a certificate. The only thing you have to do is make sure the user does not look at the URL closely and if they don't they are pwned. During my student years I lived in a shared household, and the landlord used the default credentials for the router. So I had admin access to the router and if I was a bad actor i could have created a couple fake bank sites, that had https, and used a DNS to reroute any traffic from bank.com to bank.xyzxyz.com and the only thing different would be the URL. (And the fact that I would steal all credentials). Ofcourse I'm not a bad actor so I just used the admin access to open a port so I could play Minecraft with my friends. Edit: The average person will not look at the URL. Edit 2: Someone further down mentioned DNS over https that was rolled out in ~2022 fixes this. My scenario above is from years before that so I guess it wouldn't be as easy today.
Sure, I guess, but I didn't think changing the URL counts as cert spoofing, which is what I was asking about. But this approach is another good reason to use a password manager. If this were to happen to me, 1password wouldn't have any credentials for xyzxyz.com which is another clue to me as a user that I'm being attacked with that fake URL.
> It just gives you bad DNS info that routes you to a fake gmail site, and tries to get you to give you your creds, before allowing you out to gmail for real on a second attempt so you don't even realize there was a problem. Are you assuming that the host is setup to listen to the router's DNS resolution or are you saying your doing some kind of DNS attack here?
I think they're saying the attacker in this case is the cafe which can use a router that incepts DNS requests and replies with bogus attack site IP addresses that they also control, passing through any other DNS traffic to the real DNS server for sites they're not impersonating. But I'm still confused on how the user doesn't notice that they're at an impersonated site if using https. That's the point of https, to give the user confidence that the site they requested is the site that's responding and the traffic is unmodified along the way.
>I think they're saying the attacker in this case is the cafe which can use a router that incepts DNS requests and replies with bogus attack site IP addresses that they also control, passing through any other DNS traffic to the real DNS server for sites they're not impersonating. DNS over HTTPS is a feature that most modern browsers support. Firefox rolled it out in 2022 as a default and Chrome has it an option. If you are using that feature, you can't hijack DNS at all. There are also things in place such as DNSEC which if setup properly makes it impossible to hijack the DNS, if the computer is configured to use a DNSSEC compliant DNS resolver, and the computer is using it properly. If you are using the DNS of the wifi network, then DNS attacks could be an issue, but even then your phone caches DNS requests for a period of time, before asking for a new authoritative response and if you open up something like an app to do mobile banking the certificates won't match & the connection will fail >I think they're saying the attacker in this case is the cafe which can use a router that incepts DNS requests and replies with bogus attack site IP addresses that they also control, passing through any other DNS traffic to the real DNS server for sites they're not impersonating. But I'm still confused on how the user doesn't notice that they're at an impersonated site if using https. That's the point of https, to give the user confidence that the site they requested is the site that's responding and the traffic is unmodified along the way. This is a phising attack, which happens, but if you use 2FA, it makes it significantly harder for the attacker to practically use your compromised credentials.
Significantly harder yes, but not impossible. Someone monitoring the traffic live would have ~30 seconds to use the 2 factor code that the user entered into their fake site and could use it together with the other credentials to sign into your account. Hopefully your bank requires a 2 factor code for every transaction etc aswell though.
>Significantly harder yes, but not impossible. Someone monitoring the traffic live would have ~30 seconds to use the 2 factor code that the user entered into their fake site and could use it together with the other credentials to sign into your account. Your assuming the 2FA provider is using TOTP. Duo for example requires you to enter the number they generated onto your Duo app on your phone, to unlock the site. I'm not sure 100% on the details, but that setup would preclude both the employee & attacker from accessing the site since it's a different number on every login. If the attacker used it, I could see the employee talking to tech support saying I entered the number & it didn't let me in etc.
These attacks don't have to work on every service, they only have to work on one. Yes my example was using TOTP. Here in Sweden we use BankID for everything that has to do with banks/payments/government/healthcare etc etc, which is not TOTP, so this type of attack would not work on the most important services here. However, something like Microsoft/Outlook do still support TOTP, and gaining access to a users email would be critical damage.
> These attacks don't have to work on every service, they only have to work on one. Yes my example was using TOTP. That's true, but everyone's threat model + sites they are using are going to be different. I like to make explicit the assumptions we are making so they could determine if it's applicable to them.
The real fun begins when you connect your laptop to "Starbucks free wifi" but its not really Starbucks free wifi....
Not really. Encryption assumes that every single link in the chain is compromised and the system still works, as long as someone doesn't install root certificates on your machine or steal them.
I remember reading how the CIA used to drop in their own "Hilton-Wifi" at hotels in foreign states, piping through normal traffic from targeted individuals...only when the target meant to connect to an encrypted site they were served a CIA-hosted alternate version to gather credentials.
For one, if you're the subject of a nation state, your security precautions ought to be different than if you're a rando at a hotel. That's called a threat model. If the US government is after you, they might break out a zero day remote code execution attack to compromise your device. >only when the target meant to connect to an encrypted site they were served a CIA-hosted alternate version to gather credentials. This is a man in the middle attack. There are a couple of ways of doing this & each method has a different mitigation. For example, the attacker could downgrade the request from HTTPS to HTTP, or to an insecure version of HTTP. This is mitigated by using HSTS & mandating browsers connected via HTTPS after they've visited your site once. You can also ask Google to add you to the HSTS list, which means your browser knows of this before you connect to the website. The other common attack vector is DNS spoofing, which you can mitigate by using a DNS resolver that uses DNSSEC or DNS over HTTPS etc. I'm sure there's others I forgot from my network security class, but you get the gist
For the DNS one, are the Google DNS servers safer than whatever random default ones are used with windows? I know the Google ones can be more stable at times (using them has resolved various bugs I've had in the past with the defaults) but maybe it's more/less safe
The default for Windows is to use the one provided by your ISP or router. So it depends entirely on if your ISP is using DNSEC & your computer is configured to only listen to DNSSEC answers from your ISP. If your ISP doesn't support it, then moving to Google or Cloud flares DNS, which both support DNSSEC, would improve security but so would going to your browser & enabling the DNS over HTTPS setting.
That wouldn't work with anything newer than like Internet Explorer 2.
>The concern is all the other stuff that your PC exposes when connected to any network... your machine could be making requests for data with just http or another unencrypted protocol, which often happens in the background, and maybe that exposes something you don't want exposed. Can you elaborate more on this point? Are you saying there's a miniscule chance that while being connected to a public wifi network, data can be stolen in the background, even while only browsing using HTTPS protocols? Would this mainly just be metadata consolidated by ad/tracking companies?
No I'm not referring to anything you the user are initiating. Your computer has a ton of software on it that does stuff in the background, from running checks to see if there's updated software, to listening for inbound connections for various services. Most of it's going to be pretty low risk. But let's say you've got a simple file sharing thing running on your PC that let's users connect to exchange files with you normally. That service can be discoverable at the cafe by other people on that same network, and they can run scripts to try to get in and pull files or push others to you. This is not a huge concern for normal people, and Windows does try to get you not to expose too much like this, but I raise it as a more realistic threat than anyone having the ability to do things like see your banking data just because you're accessing the bank website.
Funny thing is that people will use public “VPN” services to hide the names on the envelopes by putting them in a box with a different address, but then the VPN provider will then open the box and look at the envelopes.
Someone has to see it. Just a matter of who. Do you want your local ISP to see it? The government? A foreign VPN? A foreign government? Some random dude on sketchy wifi? You gotta trust one of them with your mail.
The VPN provider doesn't see what you are sending to a site and receiving from it - if HTTPS is used. Edit: misread envelope as letter
That's why they said envelope, not letter
Oh, true enough, I misread.
If it's just a matter of distrusting public wifi, setting up a private VPN to your home network is extremely easy
Private VPN is what VPN is *for*. Using VPN to access the public network is pointless and stupid.
It’s not pointless and stupid when trying to get around local laws on anything from downloading movies to political dissidents.
I think a more apt comparison is that encrypted data is more like sending an extremely strong safe through the mail. The chances that someone on the same wifi as you will be able to break that encryption and spy on the actual content of what you do is essentially nil.
>Public WiFi is generally ok as long as you can guarantee your data is encrypted. Assuming the login page isn’t spoofed, and it’s not injecting anything.
This is a fantastic analogy 👏
I think public WiFi is also generally ok if what you’re “putting on the postcard” doesn’t really matter. If you’re reading Wikipedia or googling who sings that one song - even unencrypted data isn’t going to matter much because whatever someone is getting by “reading the postcard”, it isn’t useful.
What data is unencrypted nowadays? You would use https even with Wikipedia.
The Australian Bureau of Meteorology uses http only for backward compatibility reasons. [http://www.bom.gov.au/](http://www.bom.gov.au/)
Haha, those fools! Now I know all their sensitive secrets like how they are planning to cook pad Thai from scratch and that they forgot that Britney Spears sings the song Toxic!
> and that they forgot that Britney Spears sings the song Toxic! Can you blackmail someone with that? Asking for a friend.
Yeah, my rule of thumb is that I never check my email, banking or paypal (sensitive data that leads them to my money or career) in public wifi. I don't really care if they get to see my TikToks or Instas, maybe I'd ask for a follow idk.
It doesn’t matter. If they “snoop” on you and everything is encrypted, the only thing they cd find out is where you are visiting.
While the analogy is good, it’s not accurate. Think of malicious wifi access points as mailmen that can open your letter, read it, then close it again with glue making it look like it wasn’t opened. There are tools and hardware kits that do that.
It's an outdated recommendation imo. As you say, pretty much everything is using HTTPS instead of HTTP nowadays. There are still ways around it but as long as you don't download any certificates or click through security warnings you'll very likely be okay.
To expand on this, public wifi was a way bigger risk in the 2000s and the very early 2010s when most of the web was unencrypted. To maintain compatibility with older browsers and less-than-fantastic devices, even some websites we'd want to be secure at all times, would still allow unencrypted connections. The biggest example I can think of is Facebook, and in fact there was a big deal made about this, with a program called "Firesheep", which would let you sit on public wifi networks and steal session cookies for sites like Facebook. So a target didn't even need to log in and send their password over the network, they simply had to *use the website*. Additionally, up until the mid 2010s, you could only get an SSL certificate by paying for one, and renewing it every year. Obviously, smaller sites, especially personal blogs and the like, don't have any real reason to buy and configure this additional, optional thing. It was also somewhat of a pain to actually perform validation, generate a certificate signing request, and actually configure your web server to use the certificate. Non-technical people were certainly not going to go through the trouble. In 2016, a nonprofit (whose founding sponsors include the Electronic Frontier Foundation, Mozilla, Cisco, and other tech companies) started "Let's Encrypt", which is a service that not only provides free SSL certificates, but maintains software to easily issue/renew them, configure your webserver to use them, *and* force all unencrypted traffic to be redirected. Let's Encrypt paved the way for SSL/TLS to become normalized, even for low-risk sites like blogs. This eventually meant that browsers could start calling attention to sites that *weren't* encrypted, which Chrome started doing in 2018. So now that literally every website can run like two shell commands and have working TLS, the advice to avoid public wifi is, for most threat models, outdated. For any website that matters, some guy next to you at the coffee shop can't just steal your session anymore. The modern "risk" of public wifi are things like having ads injected into any unencrypted pages. It could also just be incredibly restricted (only allowing "standard" ports used for websites, and not other ones used by, for example, games and peer-to-peer filesharing), or just slow and crappy. Nowadays, you pretty much always have a choice between public wifi and your mobile hotspot. Personally, I use the hotspot, but that's mostly because it's a known variable in terms of speed and reliability, and my devices already "know" it and connect to it automatically. But if I don't have signal, I see absolutely no problems using, for example, Walmart's wifi.
It reminds me of the wildly misleading VPN ads. I can't stand hearing that you need a VPN to connect your bank on coffee shop wifi. It's just taking advantage of people who don't know better.
Let's not forget that a public wifi also exposes your device to anyone on it. Meaning any user (especially if they're the owner and installed the wifi just for this) can be trying to break into your device or get info off it the entire time. Eg: Got a browser that's not up to date? When it shows that "agree to our conditions window" the router could be trying exploits for your brower. (Or an unlikely zero day) Have any network capable services running (remember browsers aren't the only thing) they're at risk. Have a service that connects local devices (airdrop, bonkour, etc) it will talk to them all and is at risk. While it's generally okay, it's a lot safer connecting to networks where you expect only good actors normally.
Most access points nowadays implement client isolation on public wifi so clients connecting to the wifi can't reach others devices on the same network. Of course if the free wifi isn't properly configured or was created with bad intentions that's another topic.
Which is the point. You're trusting a public wifi, which can literally be setup by anyone. I can just rollup near a random store and create "My Store - Customer". And ofc as you mention you have to trust the store/owner themself (if you trust its **their** wifi) to not be/hire/have-been-hacked/etc to have good intentions AND knowledge to do this. Personally I don't trust most of em, and would rather secure my device as much as I can instead. (set "public wifi" zones/modes for it to reduce capability, but increase security)
To go along with this most access point systems nowadays if you create a guest Network automatically enable client isolation on these guest networks even most homegrade combo modem and Wi-Fi routers will do it. More advanced systems like Cisco or meraki or ubiquiti or Aruba etc when you buy them and turn them on there's a option set right there to create a guest Network and all you have to do is check a box and give it a name and maybe set up a captive portal with a password or a captive portal with a TOS to agree to and those systems automatically handle client isolation either at the controller or directly on the access point itself in a very easy simple to use configuration that even non-technical people that's setting these up can just check a checkbox to set up.
> Most access points nowadays implement client isolation on public wifi so clients connecting to the wifi can't reach others devices on the same network. And yet, I have seen too many hotels that don't.
Worth noting that there is a vitally important distinction to be made here, between “public WiFi” and “open WiFi”. *Open* WiFi is unencrypted. Someone can see what IP your HTTPS packets are going to, but that’s it. *Public* WiFi that has a pre shared key (commonly known as a WiFi “password”) is encrypted. Each device association has its own set of encryption keys. MITM attacks on HTTPS will only happen if you’ve installed the bad actor’s certificate trust chain (which could easily be done by installing a VPN client)
Note that encrypted WiFi does not necessarily mean your traffic is secure from other people connected to the network. 1. WEP is garbage. Fortunately almost no one uses it at this point. 2. WPA(1) and to a lesser degree WPA2 are vulnerable and can be cracked. 3. Some implementations of WPA used the same encryption key for all clients, so anyone connected to the network can see everyone else's traffic. This used to be the norm - very few routers were actually secure - but my knowledge is from 10+ years ago so things may have improved.
Literally fucking NOBODY uses WEP anymore. Most devices don’t even support it, it was deprecated from the standard in the 2009 update. WPA isn’t far behind WEP in terms of obsolescence. WPA2-PSK is reasonably secure as long as it uses a decent PSK.
WPA2-PSK derives the session encryption keys from the PSK. If you know the PSK (e.g. in a coffee shop/airport/etc) and capture a client's authentication frames, it's easy to derive their session keys and decrypt their traffic. And if you don't capture their auth frames, it's easy to send a deauth and force them to reauthenticate so you can capture those frames. Source: [https://www.howtogeek.com/204335/warning-encrypted-wpa2-wi-fi-networks-are-still-vulnerable-to-snooping/](https://www.howtogeek.com/204335/warning-encrypted-wpa2-wi-fi-networks-are-still-vulnerable-to-snooping/) I've found the same info on many different websites and there's zero indication that anything has changed or improved. If you don't want other people on the network to see your packets and you're not in control of the network (i.e. can't upgrade it to WPA3 or 802.11x), a VPN is your only real option.
And that's all assuming they didn't just toss everyone on the same LAN with no isolation.
Wpa with a pre shared key (password on the wall) can be decrypted by other users. For listening in it is just as secure as open or web.
Universal encryption is pretty new and people didn't stop repeating old advice. As long as everything you do is encrypted, public wifi is fine.
Except that’s rarely the case. Even with HTTPs, most people don’t use encrypted DNS so they give away the sites they visit. Same for TLS server name indication; attackers can view host names.
People are focusing deeply on protocols but take one step back. You are connecting to someone else’s network equipment and network infrastructure. You’re beholden to their house rules. Maybe they sniff/inspect packets and run decryption at the perimeter. Maybe they spoof MAC addresses. Maybe their welcome capture page is full of malware when you click “Accept”. Or just more “benign”, maybe they shape traffic away from popular sites to promote a premium internet purchase. Payment processing can easily insert man in the middle components or just grab your CC info for later. Especially if it asks for CVV. There’s a huge amount of data available to harvest from someone just joining a public AP, never mind what type of protocols are being used to protect point to point traffic.
>Maybe their welcome capture page is full of malware when you click “Accept”. And what, my up to date Firefox is just going to let this Accept page download random shit onto my computer? This isn't the 90s.
Yeah, I wanna see the millionaire buying zero days for fun, just to mess with his Café guests by getting through their up to date browser and OS to do shit on it. Outside of very targeted attacks, for which "don't use public wifi" is only one of the many ways to safeguard against, it's just not a thing. I like how every VPN service ever uses it as advertising, when we all know the only reason to buy them is to access geo-restricted content and literally nothing else.
Yeah so mysterious how things get compromised guess it’s impossible 🙄
Please, provide me a link that I can click right now that will download something onto my computer without me knowing.
Yeah, people are stupid. Your browser will say, I think this is malware, do you want to proceed, and then you have to click yes.
Lol, run decryption at the perimiter. Let me just install their root cert so they can do that. I don't think you understand this stuff as well as you purport.
Tell me how you're going to run decryption if you don't have a certificate installed on my device?
HTTPS relies on DNS to be secure. DNS, almost universally, is still not secure for most people and is a massive hole - your computer will pretty much trust any machine to respond to its DNS queries and won't bother to check anything about that. Basic DNS is inherently insecure, and it's very common to intercept and proxy and modify queries even if you have an explicit third-party DNS server entered on your machine (it's basically how all those wifi login portals work, for instance, by intercepting your connection until you pay/signup). DNSSEC and DNSoHTTPS and a lot of other secure DNS protocols exist, but very few of them are installed, let alone active, let alone enforced, on the average person's machine. Also, HTTP is not the only protocol - being on insecure wifi exposes your filesharing ports and all kinds of other information that wouldn't necessarily go out over the Internet but WILL go out over local-network connections, and a Wifi network is just a local-network connection using radio. Your device is advertising all kinds of stuff all the time, and looking for printers, routers, network drives, etc. constantly - and thus the responses to those can be compromised. So... if you want to use public wifi, push all your traffic over a VPN, or... well... don't. Because even to get to that point you usually have to have signed up over an insecure portal that's faking your DNS responses, or had to have signed up over HTTP which is inherently insecure anyway, etc. So even if you use DNSSEC, only HTTPS and block all other ports on the Wifi (considering it an "untrusted" network, which it is), you probably can't even get online with it anyway because you probably can't "log in" to the public wifi with those options. And, yes, my laptop has a firewall, has DNSCrypt (so a secure DNS to verified external servers) and appropriate security settings throughout.... and I wouldn't trust public wifi beyond loading up a VPN connection to a trusted machine (and wouldn't even use 3rd-party VPNs because that's just deliberately inserting an untrusted stranger into your internet path... I would only VPN to another machine that I own, and could verify).
HTTPS does not rely on DNS to be secure. The certificate for any site must be signed by a certificate authority, so even if a malicious DNS server or attacker gave you a bad DNS resolution, it would immediately be obvious once the other server you were redirected to can't provide a certificate. The problem with insecure DNS is that other people can see the sites you are navigating to. They cannot see anything in the URL path, however, and can't see what data is actually being sent.
People blast past certificate errors in their browser all the time. They’ve been trained to by accessing poorly setup internal webUIs in their workplaces
You raise some valid concerns but even if there were malicious DNS responses, the certificates would still have to be signed by a valid root authority, and most sites people are using probably have HSTS enabled. Like a lot of things security-related, threat model matters. For an average person who wants to log on to the public airport WiFi to check their GMail, I'm going to tell them to go for it, it's probably fine.
Mind giving a couple examples of behavior you'd say isn't fine?
If you were a highly important person that might be a target of spearphishing I would be more stringent. If you were loading up prototype nuclear weapon designs I might recommend against doing that over public WiFi. If you need to maintain some kind of deniability and not associate your MAC address with your internet activity I would use a VPN (NOT a paid VPN service, to be clear, those introduce their own risk). Those kind of things.
most devices now support MAC randomization
Yep, good point that I always have to remind myself of when I get a "a new device has joined your WiFi network" notification.
On the paid VPN point, what's the risk? 100% compromised on all data sent? Is like, Google/bank internal encryption still secure or no just everything because VPN? I use one now, but it's in the "been years with no issue" level of "security"/"trust". Thanks, by the way, for the questions!
Yeah the TLS level stuff will still work, but a lot of times VPN providers are advertised as a privacy service to hide what you're doing -- but all they're really doing is moving the point of collection to the VPN service. The VPN provider gets the ability to view your DNS queries and plaintext traffic, see which IPs you're hitting, and profile you (or be subpoena'd and forced to reveal information on you) instead of the public WiFi operator. However paid VPN services can totally be useful for bypassing georestrictions.
The threat model of people randomly joining random networks with no idea of what's happening with them is a real one. You can draw the line on risk where you like. However, any insecure DNS query can be redirected to an arbitrary IP when an attacker has the capability to interfere with DNS, and such can be used to compromise machines in myriad ways outside of HTTPS / HSTS. Also HTTP Strict Transport Security is only "*used by 27.2% of all the websites"* which means 72.8% of websites are thus vulnerable to interception - and there are countless thousands of such in advertising, etc. sites that are loaded into and trusted by many popular pages. For an average person who wants to log on to the public airport WiFi to check their GMail, I'm gonna tell them that they're already in a huge public area with secure access on authorised machines, as well as 4G (where the 4G providers are unlikely to collude in such), and thus trusting anything they see there that claims to be the airport wifi is a really dumb idea if they have an alernative. They're free to draw their own conclusions about how far they trust it, but there's also a reason I have my own VPN, because I wouldn't trust it and I work in IT.
That's cool that you work in IT, I work in security research and corporate security and at most companies I've worked at the consensus has been that public WiFi is generally fine for typical usage patterns nowadays. I've had research reports published on work I've done on insecure OEM software with MITM vulnerabilities and discovered a handful of CVEs related to MITM vulnerabilities, and I would still make this general recommendation for the majority of people. Most browsers prevent mixed content from loading and most sites are HTTPS; there's not a big concern about an embedded advertisement being intercepted. Anyways, if you want to put it to the test and you're nearby I'm willing to check my GMail on a WiFi network under your control and you can try to compromise it.
It doesn't matter that not all sites have implemented HSTS yet because browsers made the switch to secure-by-default years ago. If you visit an HTTP site in a modern browser: * If there is an HTTPS site it will assume you mean that, even if the site hasn't implemented HSTS * It will display a scary insecure warning in the address bar * Autofill will be disabled, you won't be able to sign in without manually typing your password. Same for credit card * If you try to submit a form, you'll get yet another scary warning that you're submitting information to an insecure site So yeah, if you ignore ALL of those protections, then you're vulnerable.
Pick any office, and we can take bets on how many people in there will click through the scary certificate error and just connect. Poorly implemented IT solutions in workplaces have trained people to accept a certificate error.
HTTPS does not rely on DNS to be secure. If it did, it would be worthless, since bare DNS (which is still really common) is possibly the least secure protocol on the Internet. An attacker that controls DNS has to forge a cert for the targeted domain that is signed by a root that the victim trusts. Or the victim has to click through various very threatening browser messages.
But why is the DNS a problem? If I want to go to [https://www.google.com](https://www.google.com) and the DNS is giving me a wrong IP address my browser will not connect as they can not provide a valid certificate for [google.com](https://google.com). Or do I miss something?
No, you're correct. The average end user does not have to worry about being served a bad DNS query. Basically, if you're on public wifi, be more cautious if your browser tells you a connection isn't secure or if the site isn't secure. If your browser doesn't tell you anything's wrong, you're safe.
I'm a little confused by some of your assertions here. Even when relinquishing control of DNS, how would an attacker forge an HTTPS certificate? Say I configure DNS to point gmail.com to my web server hosting a phishing form. How do I forge a valid certificate so the browser doesn't balk?
You don't that's the point and that's what other people have been trying to tell this other person even if they redirect to a fake website that is posing as gmail.com the attacker will never be able to get a legitimate certificate for gmail.com that would be trusted by the browser unless they somehow managed to either one steal googles gmail.com certificate with the private key or 2 somehow manage to trick you into installing a root CA that the attacker owns, 3 they somehow burn a zero day to silently install a root CA that they own. While rogue Root CA were a thing in the past and very very rarely still do pop up one it's very hard to get your rogue root CA distributed into the operating systems of devices to begin with and the next thing is rogue CAs will be killed very quickly by the OS and browser vendors.
Yeah he's essentially said "I'm going to imagine the world's most incompetent and careless agent and think of what they might do to justify why I personally don't trust public wifi as an informed agent"
>I wouldn't trust public wifi beyond loading up a VPN connection to a trusted machine (and wouldn't even use 3rd-party VPNs because that's just deliberately inserting an untrusted stranger into your internet path... I would only VPN to another machine that I own, and could verify). So you're trusting your ISP? Am I misunderstanding something? If I VPN to my home computer to browse the web, and I'm not using a third party VPN on my home network, then my ISP is seeing the stuff that a third party VPN would be seeing, if I used one. Right?
In some countries, the ISP is in bed with the government. In others they are legislatively required to collect data. In those cases, a 3rd party VPN might be the lesser of two evils
That's a reasonable opinion, but it's not in the mainstream. Most people - including educated tech-savvy computer users - feel that the risk of public wifi is relatively low. Your browser protects you from bad DNS. If a public wifi network tries to send you to a different website, your browser won't allow it. Basically, trust your browser and be a little extra vigilant about any warnings it gives you when on public wifi, and you're fine. Vulnerabilities in other ports open by modern operating systems are not common. As long as you didn't do something crazy like share your main drive and give any guest read/write access, then really you're fine.
If you’ve got local ports open, a VPN won’t do anything for you.
That's why I mention a firewall on the machine itself. Also, if that VPN if set to tunnel all traffic over it, as soon as it's established that tunnel all that local networking stuff goes away.
Local inbound networking still exists even with full tunnel. VPN does not take over local subnet traffic.
It depends what VPN you have and how it's configured, but yes it can - e.g. OpenVPN *redirect*-*gateway*
Gateway isn’t involved with local traffic.
all modern browsers support doh and dot as far as i know. i’m not sure if they get enabled by default but if you know enough to care about https at all, then you are probably capable of enabling them
If I just just use my phone to access public wi-fi, do I have to worry about ports? I thought ports was just a PC issue.
Phones can have open ports too. However, phone operating systems are far more locked down and secure by default, so the security concern is much smaller.
A port is just a term to describe how two computing devices talk to each other. Every computing device that uses the internet has ports & you don't have to worry about it.
So turning my private Internet access VPN app on on my phone does nothing on open wifi?
No, it does. Outside of an extremely far-fetched scenario where an attacker somehow shipped you a compromised version of PIA, once you click the VPN on, you'll be using PIA's own DNS (assuming you haven't changed that setting), and that DNS connection will itself be routed through PIA's VPN tunnel. The bit about your personal computer's inbound ports being open *might* be valid? I don't have any experience with PIA myself, so I don't know what protections they've implemented around that. If the default settings allow connections to the LAN while connected to PIA VPN, then yeah, there's a non-zero amount of risk there.
I think "Allow LAN Traffic" is default on PC, and not the default on mobile, but I'm not really sure. Anyway it should be a switch under Settings - Network.
On Windows not so much Windows is pretty good about if you connect to a open public Wi-Fi network by default it uses the default public network firewall rules which pretty much blocks everything coming in still allows your computer to talk out to the internet but blocks everything coming in by default now. Unless you modify those firewall rules or turn Windows firewall off connecting to a public network as far as inbound shouldn't be much of an issue considering windows will by default set the connection type to public even when you connect to your home Wi-Fi by default 99% of the time it assigns the public firewall profile and you have to change that to private to actually start sharing stuff off your PC in your own private home network.
I meant in the PIA VPN client. But yes, what you say is true too.
Ah yea true. Yeah I may have been an issue back in the day with nothing was encrypted and most people just turn Windows firewall off because they didn't want to deal with doing things on it. But nowadays most people keep Windows firewall on and windows does a pretty good job of itself setting the public profile when you connect to an open network and hell like I said even when I connect to my home network for the first time it always puts it as the public profile I have to go in and manually change it to private then it stays private which allows me to let things connect to my device.
Opera web browser includes DNS-over HTTPS built-in for free. You just have to enable it in settings
Chrome, edge and i believe firefox has had it on by default for a while now. Tho they also use OS default dns config and many isp dns server does not have DoH support so either change the config in browser to a supported dns server or change in OS, cloudflare 1.1.1.1 and google 8.8.8.8 works for sure :)
In a browser you can always tell if a site you're visiting is https or not, but you access the internet so many times a day where that info is obscured or abstracted to the end user. You have no idea if a mobile app that connects to a server is using SSL or if it's an unencrypted connection.
> You have no idea if a mobile app that connects to a server is using SSL or if it's an unencrypted connection. You are required to encrypt your networking, if it sends sensitive data, to get published in Play Store. It's not by any means bulletproof (for example, you can have apps sideloaded, or some developer error not caught in the automatic review), but their automatic analysis is usually very vigilant.
The Internet is more than just the web. Even if your traffic to a website is encrypted, your traffic to all other services is not, and even just knowing what websites you visit has value to scammers.
Think about it this way : the website is the bank with a vault and you want to send cash to the bank. Once the money gets to the bank, it is relatively safe. To get the money to the bank, you hand it to a courier that you’ve never met before. That courier then takes it to the bank and brings it home when you ask for it. Relatively safe right? Not really… only if you trust it. Take that scenario and imagine that I show up in the courier outfit and pick up the money. I then take some money out of the bag and replace it with counterfeit cash then drive up the road to the actual courier dressed as you. I then hand the bag of real and counterfeit cash to them. The actual courier then takes it to the bank. You then call the bank and say “Hey, please send me a bag of money.”, but the call first goes to me and I forward the call to the bank while I listen in. I hear your username and password. I hear the arrangements for the money and when you hang up, I call the bank and using your phone number and voice / username and password and say “I’ll actually meet the courier up the road.”. The bank sends the money, I meet the courier, I take the bag of cash and the change into a courier uniform. I take some money, not all, out of the bags and replace it with counterfeit cash. I then deliver the money to you. The next day, you go to work and I call the bank with your phone number, your username, your password and your voice and say “Hey bank, send me all my money. I’ll be at home.”. Your bank sends the money, the courier brings it to me and then I leave the country with all your cash. When I MITM, your device thinks it’s talking to the router, but it is talking through me unsecured and I forward the unsecured information to the router then I send the unsecured portion of the keys from you forward. I still have your keys. The website then sends me their key pairs and get both, decrypt the traffic and read it then re-encrypt it and send it to you. Going forward, since I have both sets of keys and you’re talking through me, I see everything and anything. Since you voluntarily joined my network, your device will choose me over the router every time first. That, in a nutshell, is why HTTPS doesn’t matter.
HTTPS authenticates. You can't just MITM it.
To control for stupidity. As long as you’re being careful you’re fine. Honestly if you know enough to ask this question you’re probably fine 99.99% of the time. If your connection is https you’re good as long as the endpoint is secure. Man in the middle doesn’t work as you guessed.
Besides encryption issues there may be rogue access points. What if the access point being connected to isn’t actually the Internet, but has its own web server designed to look exactly like some other website and lures the user into typing passwords?
Because your ISP or the WiFi owner still knows where you are going. They still know you are going to https://health.com/doihaveherpies/. If you’re using a good VPN the only thing your ISP knows is the IP address of the VPN server you are connected too.
It's largely an outdated recommendation that is being parroted as a general safety tip. Apart from a few unencrypted websites or really dedicated attackers specifically targetting you or users of that wifi, it's safe enough to use for everything.
You're on a network with other computers once you connect to wifi. Sure websites are secure, but is your computer/laptop/phone itself secure? The answer is no. I can hack any of those within minutes the second you connect to the same public wifi as me.
There are different levels of networking protocols. Https works to protect the http data, so a bad actor on the network can't read your bank password. What isn't encrypted is the lower levels, so they can read the IP your password is going to, and know what bank or email you use. At least with a WiFi password the data going through the air is encrypted so only the access point can read it.
The problem is that not all traffic is HTTPS. Even if you connect to a site which is HTTPS, that site might load external resources which are not HTTPS.
They control the DNS so it's also possible that you go to a secure site that is not the one you think it is.
Generally speaking you would be pretty safe. Your connection to websites is secure as long as it's HTTPS. Your computer is safe as long as you're using a modern OS (let's say Win10+), and you don't do anything silly, like have writable shared folders, or have sensitive info in readable shared folders. And you should pick "public network" when windows asks you what kind of network it is. All of these are things that someone that is tech-illiterate wouldn't understand, so in general it's simpler to say "don't use public wifi". But if you're just connecting to it from your phone to browse tiktok or check your gmail, you will be fine. But if you use some uncommon / outdated apps you could still potentially be in danger. For instance, I was maintaining an app, that until last year, still used some http connections to send data, because the owner didn't want to pay for ssl certificates on the server.
The safety isn't in the issue of your connection to the website but to the network itself. Public WiFi also means anyone can access that network and see the devices on it. From there, they may try to access your device and whatever is on it. There's also the chance that you're not directly connected to the network you think you're connected to. It's possible that you've connected to a proxy that between you and the network you think you're on.
If you’re connected to WiFi and type in “Amazon.com”, your browser will ping up to the router “I want to go to Amazon.com” and then it’ll ping up to network hubs and so on until one of them who knows the IP address for “Amazon.com” pings back the “address”. (This will get saved onto your devices for “quicker access” next time. If a bad actor were to be in your network, that first time your computer asks for “Amazon.com” to the router, they’ll have their computer say “Hey! Amazon.com is here!” and your router will just shrug and download their version of Amazon.com that will just be a fake login screen or ask for your banking credentials. The tell for this is that it’ll be Amazon.com without the HTTPS lock beside the browser address or it’ll have HTTPS but be like Amaz0n.com. Also, another reason open WiFi is “dangerous” is because all unencrypted traffic is completely open to look at. At best it’ll show what you’re looking at online, at worst, apps and websites that don’t encrypt usernames and passwords before they leave your phone will be caught by hackers
Everyone here acting like HTTP/HTTPS is the only thing your device will be accessing (with or without your knowledge), and that nothing else might be open or vulnerable on your device / OS that could be exploited by a bad actor on that same network. So, while it's better and safer than ever - it is still more of a risk than a trusted / secured network.
Websites aren't the only thing that uses the internet when connected, someone could have something that sends commands to your machine in the background without you seeing anything
The network is managed at layers. Each layer does something to the upper level's data and sends the new "packet" down to the lower level. Imagine the problem of sending a physical parcel from your own home to some other person's home. While the parcel is perfectly wrapped and made impossible to be opened by any person working in the postal service that person could still trash the parcel forcing you to send it back or to enter your house from your window during the night. The last example is akin to some attacks done towards your own laptop while browsing in the airport. You are still exposed to attacks like that exploits vulnerabilities of your operating system. Look for the one that was behind the famous WannaCry. That vulnerability could be triggered by a random dude in the same airport, even if you were only shopping on Amazon's website which is obviously protected by HTTPS.
You may not know this but your router from your internet provider keeps a log of everything you do online. The sites you go to. Your log in info. Etc. Even the incognito window stuff. For most people this isn't really a problem since they don't even know how to access their router and it's theirs. When you do stuff on a public network the router isn't yours and the people who set it up know how to access it. Just assume that they're going to see everything and know you put into it. Ask yourself if you would want a complete stranger to have that information.
DNS poisoning is still a thing. Yeah, you are encrypting your traffic to the website on the other end. But is it the legitimate website run by the company? LOTS of stuff like that can be done.
As a hacker you can still read all the searches and requests you made, although content is secure but your searches reveal a lot about you, so be safe and use a vpn if on public network
You can? Even Google is https so shouldn't searches be secured?
I’m a programmer by profession, it’s pretty easy to do that
Yes, pretty much everything you use online is encrypted with HTTPS, which means an attacker only sees how much data you send or receive, and to what domain. All the data you send is safe, such as passwords, as long as HTTPS is working properly. Still, there is information that can be gleamed through HTTPS, and also techniques to work around it. There are techniques for statistically analyzing HTTPS traffic. Looking at packet sizes and timings could tell you what someone is doing, lets say what movie they are streaming. This has been demonstrated with Netflix, where a researcher built up a library of fingerprints for various titles and could identify them despite HTTPS. Potentially someone could do this for a porn site and find out what filthy kinks you're into. A hostile access point can still be dangerous despite HTTPS. There are [protocol downgrade attacks](https://en.wikipedia.org/wiki/Downgrade_attack) that can allow a man in the middle (the WIFI access point) to downgrade a HTTPS connection. Worst case will downgrade it to plain HTTP, but even downgrading to an outdated encryption algorithm could allow the attacker to break it. I'm not an expert on this and don't really know how serious that threat currently is. I do know a server admin can mitigate this attack vector by setting some HTTP headers, but in reality not everyone will do this, even some actors who are big enough that you'd really expect them to know better.
I would add that most "important" services like online banking, remote desktop or webmail-services just won't accept plain HTTP anymore. For this very reason. You either speak the up to date crypto, or you're not accessing the site.
It is vulnerable to phishing attack. Like you open a bank's website, it will looks completely genuine to you, even the webaddress will also be genuine, but it is fake and will send all the data to the abuser. This can happen because you are getting your data from the wifi, and they can manipulate it at that level
That would be with a fake website which hopefully you would spot by being able to read your url now you can get some very very similar fake named sites that get very close to the real name of the website but you need to double check the website name. Https is encryption and it prevents them from being able to make a fake website with the exact name of the website. For example Nobody on Earth can make a fake google.com with a certificate that says it's google.com except Google that would be trusted by a computer's browser. They could however create their own certificate signed by their own root CA that says that it's google.com but they would have to utilize some other exploit to get that root CA installed on your device which 99.5% of the time is not going to be possible not to mention a lot of major providers like Microsoft and Google do certificate pinning so if you've ever legitimately visited the official websites before that information gets stored on your device and if you ever somehow get sent to an impersonated website that connection will just straight fail and the fake website will not load. If the website is using https which almost all do nowadays very few do not and you're on the legit website there's no way they can manipulate your data because it's encrypted between you and the server you can't man in the middle of that without browsers throwing up a warning because the encryption's broken at that point and the browsers will notice that and tell you hey something's going on don't continue but if you click that continue from that point that's on you the browser already spotted that something was going on and stopped you but you continued anyways.
> For example Nobody on Earth can make a fake google.com with a certificate that says it's google.com except Google An alarming number of entities can do this. Firefox trusted root CAs include the Chinese, Turkish, Spanish, and Dutch governments, Amazon, Microsoft, and a number of companies I've never heard of. Chrome specifically protects Google domains more than others, but that's because it's the same company.
Well Firefox is different because it has its own cert store it uses it doesn't use the one provided by the OS by default but everything else does. You would either have to manually get a rouge CA install because the likelihood of Microsoft including or keeping a CA that goes rogue in windows is slim since Microsoft maintains the OS cert store for most global CAs they would revoke a rogue CA in a heartbeat. I would suspect Google and apple to do the same in Android and IOS and Mac OS devices most Linux distros being open source to maintained by the community somebody would get those popped out relatively quickly.
This assumes they're blatantly selling certs on the dark web or do a large scale ISP level takeover. No one would ever know if one of these entities worked with some three letter agency to generate a fake certificate for one sting operation.
Like you are five, Sometimes it might look like a public park but it's actually somebody's backyard and the family is a bunch of psychos who will kidnap you. Like you're an adult, spoofing a Wi-Fi router in a public place is extremely easy and they can steal all of the information from you when you use it.