141

In my opinion, arguments we have been using for years to say that public Wi-Fi access points are insecure are no longer valid, and so are the recommended remedies (e.g. use VPN).

Nowadays, most sites use HTTPS and set HSTS headers, so the odds that someone can eavesdrop someone else's connection is very low, to the point of expecting a zero-day vulnerability in TLS.

So, what other threats may someone face nowadays on a public network?

Peter Mortensen
  • 877
  • 5
  • 10
The Illusive Man
  • 10,487
  • 16
  • 56
  • 88
  • 17
    I don't know that I'd call it a threat as much as a vulnerability. Even if "most" sites use HTTPS and set HSTS, "most" is not "all". – baldPrussian Dec 04 '17 at 15:45
  • 1
    @yzT I can not think of any argument of the last 10 years that has been used by mainstream Security guys that is no longer valid. Yes HTTPS is being used. but that does not remove all risks, nor does HTST headers (that is not fully supported by all browsers). – LvB Dec 04 '17 at 16:32
  • 84
    *"most sites use HTTPS and set HSTS headers"* - this is a claim without proof. According to builtwith.com [only 12% of top 10k sites use HSTS](https://trends.builtwith.com/docinfo/HSTS). – Steffen Ullrich Dec 04 '17 at 16:52
  • 12
    not supported by all browsers? https://caniuse.com/#feat=stricttransportsecurity who cares about netscape? – dandavis Dec 04 '17 at 22:07
  • 34
    A public WiFi stops being a threat the moment plugging a hackers network cable into your laptop stops being a threat. – PlasmaHH Dec 05 '17 at 08:12
  • 3
    @dandavis, all andriod pre 4.4 (still common on second hand markets and on some parts of the worls) IE pre 11 (so win 7 among others) . 2 groups in active use. – LvB Dec 06 '17 at 00:35
  • 2
    Wifi Access points which you do not manage are insecure, this is still valid. (What you make out of it is a totally different question.) – eckes Dec 06 '17 at 05:53
  • @PlasmaHH That is a good comment, though I would just note that, in some ways, public WiFi can be less secure than having a cable directly connecting you to hackers. You can ignore traffic on that cable, and you can block data from being sent on that cable, but you cannot stop anyone from accessing your wireless network broadcasts nor can you stop them from providing you with input. – Aaron Dec 06 '17 at 17:10
  • Are you suggesting that users constrain themselves purely to sites they've already visited when on public WiFi? – jpmc26 Dec 06 '17 at 19:30
  • This position, as stated, equates to saying "All network traffic is safe now because one protocol for anonymous publication has been backhacked to be slightly harder to manipulate traffic on." Which is, of course, a ridiculous idea. The internet is much broader than the web and all traffic can be scary (and HTTPS and HSTS are incomplete solutions from a serious security perspective -- and that's being generous). Networks will never be secure (behind NAT, VPN, whatever), only your system can be further ahead or behind the cracker horizon. Public wifi just exposes you *more*. – zxq9 Dec 08 '17 at 08:28
  • Hackers can spoof HTTPS if they have control over the Wi-Fi hotspot. This is how cache poisoning works. Where JS files are replaced in the browser's cache with the hacker's own JS files. – Reactgular Dec 09 '17 at 01:44
  • @Aaron How do you "ignore traffic on that cable"? – curiousguy Dec 09 '17 at 01:46
  • @zxq9 Not sure what you mean: "Networks will never be secure" – curiousguy Dec 09 '17 at 01:50
  • @jpmc26 Jumping to a HTTPS URL you received from a safe channel, to a Web of other HTTPS URL should be safe – curiousguy Dec 09 '17 at 01:51
  • @curiousguy My point is entirely about sites from which the user did not recieve an HTTPS URL from a safe channel, so your response is not a rebuttal. – jpmc26 Dec 09 '17 at 02:28
  • @curiousguy Any network that is connected to the internet will never be secure. A completely isolated network *may* be (but usually is not). There is always *some* way to get in, though the threat profile facing most users does not include determined attackers making use of tempest or sneakernet type bridges. As a general statement, "networks will never be secure" is accurate. Assuming malicious bits cannot hit a system because the "network is secured" is flawed thinking -- demonstrated amply throughout history. – zxq9 Dec 09 '17 at 04:49
  • @curiousguy By disregarding all data from it. If I had an extra network port directly connected to a known malicious host, if it was in a Unix-like environment, especially in an open-source operating system, there would likely be multiple ways: deny write access to that device's file for all users, or block by firewall, or edit OS to completely disregard that device, or all of the above and anything else you could think of. In that situation, someone would move a mountain to make it happen. None of this diminishes PlasmaHH's point though; I was just pickin' nits. – Aaron Dec 11 '17 at 15:38
  • @curiousguy Then again, despite my previous comment, this question is from the point of view of some random person who is competent enough to be concerned about valid security issues (ie: more competent than your average user) but probably less than IT professional competency, who is just connecting to some random wifi network. In your defense, such a random person may have a difficult time doing what I suggested. – Aaron Dec 11 '17 at 15:41
  • **HTTPS is not security solution** anymore. TLS interception proxies are commonplace: universities, companies, schools, offices, ISPs, coffee shops, etc. HTTPS can't be considered _secure_ when it's routinely penetrated without your knowledge or consent. – Mac Feb 19 '19 at 15:16

12 Answers12

196

Public WiFi is still insecure, and it will always be if not used together with something like a VPN.

  • Many websites use HTTPS, but not nearly all. In fact, more than 30 percent don't.
  • Only around 5 percent of websites use HSTS. And it's still trust on first use. If the max age is short, that first use can be quite often. Let's face it, even if you are a security pro chances are that you would fall for SSL strip anyway. I know I would.
  • Just because you use HTTPS doesn't mean you do it right. There's still lot of mixed content out there. Many clients still support old versions with known vulnerabilitites, so an attack doesn't have to be a zero day to be successful.
  • Even if you use HTTPS, you leak a lot of of information anyway, such as the domain you visit, all your DNS traffic, etc.
  • A computer or phone uses the internet for more than just browsing:
    • All it takes is one app that has bad (or no) crypto for its update function and you are owned.
    • All those apps you gave permission to access all sorts of personal data... They are phoning home constantly and you probably have no idea what data they are sending and what if any crypto they use.
    • Dancrumb has more examples in his great answer.
  • Defense in depth.

Obviously a VPN isn't a silver bullet that solves all your security issues. But a good VPN does solve the ones specifically related to surfing on public coffee shop WiFi.

Anders
  • 64,406
  • 24
  • 178
  • 215
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/131594/discussion-on-answer-by-anders-is-public-wi-fi-a-threat-nowadays). – Rory Alsop Nov 19 '21 at 17:07
119

I'm a little surprised that nobody has pointed out that there's more to the internet than HTTP.

Even if your claims about HTTP(S) and HSTS were correct (and other answers discuss that), you're forgetting POP, SMTP, IMAP, FTP, DNS, etc. None of these protocols are inherently secure.

Dancrumb
  • 2,626
  • 3
  • 13
  • 15
  • 15
    Your point is very valid, and the following doesn't really change that, but POP, SMTP, IMAP, and FTP all have TLS built-in now either tunnelled (POPS, IMAPS, etc) or built into the protocol (STARTTLS etc), and DNS has DNSSEC which won't hide your communication but can protect it from tampering. A VPN is still an appropriate solution to the public wifi problem. – thomasrutter Dec 06 '17 at 02:58
  • 10
    A DNS MITM attack can be especially nasty in a public wifi setting. You can redirect entire sets of people to fake sites (or send all traffic through a proxy) – Dan Esparza Dec 06 '17 at 15:31
  • @fjw Do major OSes now do DNSSEC validation out of the box? That would be a major win, but I can’t imagine that this actually happens, given how flaky it still is on my linux. Aside from that, I wouldn’t trust mail clients to not fall for STARTTLS stripping, really. – Jonas Schäfer Dec 08 '17 at 07:45
  • 2
    Although don't most people read their email via a web client nowadays? – Shadur Dec 09 '17 at 12:27
  • @Shadur Not if a PGP mail user doesn't want to disclose his private key to the operator of the webmail silo. – Damian Yerrick Dec 09 '17 at 16:14
  • @Shadur apparently not: https://emailclientmarketshare.com/ – Dancrumb Dec 09 '17 at 16:38
  • 2
    Depending on the OS and various background programs (drivers etc.) your computer could make itself massively vulnerable without your knowing the moment you connect to any access point. Once upon a time our work laptops (RSA key protected secure net connection etc. etc.) MSN Messenger would happily work perfectly before you'd even begun the secure network login process because its protocol wasn't captured/filtered/etc. by the supposedly very secure connection. – John U Dec 11 '17 at 15:38
24

Another difficulty of public wifi access is that you are on the same local network as other unknown actors. Any misconfiguration of your local network permissions can lead to an intrusion into your device. Maybe at home, you have configured shared data on your local network. Now, everybody on the same wifi access point may have access to those shared data. Most often, this protection is assured by a firewall (whether at the office or at home), and you consider the local network more secure than the naked internet. But this time, you may be on the same local network as an attacker.

entrop-x
  • 1,017
  • 6
  • 9
  • The problem with this view is that WiFi is so generally insecure, on a regular basis, that it's probably good to assume that anybody with more than minimal motivation has access to your home WiFi network. That changes the question to, "what's the attacker's cost trade-off for going after random users on single laptops on public WiFi vs. going after home networks." – cjs Dec 09 '17 at 17:31
  • @Curt: a well-configured home Wifi is normally quite safe. Of course, if you are talking about zero-days there may be ways, but then I don't see why you single out wifi. Zero-days in cabled routers also give you access, and at least, you can use them from across the globe. With a public wifi, they are already on the network. You need a zero-day in a router or a home wifi, to achieve the same. – entrop-x Dec 09 '17 at 18:52
  • I'm not talking about Zero-days. Assuming that WiFi networks are generally well configured terrible from the start: good security takes into account the users and their skills; most home WiFi networks are not set up by network engineers. Further, even a well configured WiFi net has regularly had vulnerablities, including, many times, problems in the WiFi protocols themselves. (The latest, just two months ago, is KRAK.) There's no room here to get into further analysis, but I stand by my statement that it's good to work from the assumption that attackers have access to your WiFi network. – cjs Dec 11 '17 at 00:50
  • (By the way, I would also suggest you assume that attackers have easy access to your wired network unless you've taken special precautions in that area. Perhaps that helps with background on what I'm getting at here.) – cjs Dec 11 '17 at 00:52
11

I would argue that any time you connect to a publicly accessible network you're putting yourself at risk, VPNs are great, but do nothing to firewall your machine against the threats on the local network if you, the user, screw up and open say: your private folder for sharing to anyone else.

One strategy I employed and played with in the past when on a public network is the old-fashioned honeypot, share a folder with a file, and watch for access too that file, immediately disconnect when it gets accessed and you know you didn't access it.

Gartral
  • 189
  • 4
  • 9
    I'm not sure what's gained by the procedure in your last paragraph.... – GnP Dec 05 '17 at 09:53
  • 8
    @GnP Basically he's assuming an attacker on the network will go for the easy stuff first (a public shared folder) and when he (Gartral) sees the file has been accessed, he disconnects from that WiFi, knowing there is an attacker on it. – BenjiWiebe Dec 05 '17 at 14:59
  • 5
    I think that's a big assumption that the first thing an attacker is going to do is snoop around using SMB/CIFS, and even if it is, that they would go and request whatever files they see on the network share. – thomasrutter Dec 06 '17 at 03:01
  • 3
    You sure, that attacker won't start with exploiting another 0-day bug in SMB/CIFS? – user1643723 Dec 06 '17 at 10:02
  • 2
    I _did_ say "employed" I no longer use this technique, it was meant as a starting ground for to think about threat analysis and start research on his own for intrusion detection and mitigation. @user1643723, any time you set up a honey pot you're essentially inviting the attacker to dig their claws into your system with a big neon sign that says "Look! Shiny Data! Come'n get it!" – Gartral Dec 08 '17 at 13:56
9

Some of the concern has to do with MiTM attacks and the tendency for laptops to be configured to blindly connect to open networks based on SSID after the initial connect. Nothing stops an unknown party from firing up an access point with the same SSID as is used at other locations. Thus, while some of your traffic may be protected, a fair amount won't be, and the attacker will have a path over which they can attempt to compromise your laptop.

bobstro
  • 211
  • 1
  • 2
  • In practice "an unknown party firing up an access point" could be a relatively expensive exploit / risky crime to profit from. We should note that MiTM attacks have nevertheless proliferated, at least in some areas: because W-Fi access points without security updates (e.g. that are old or do not auto-update) are a massive weak point. https://arstechnica.com/information-technology/2019/07/website-driveby-attacks-on-routers-are-alive-and-well-heres-what-to-do/ – sourcejedi Jul 12 '19 at 17:16
7

About using public Wifi services, Tor and VPN still can leak information.

Besides Tor and VPN security implications, you still have to get at least DHCP services from the public Wifi.

Depending on the wifi settings, the offering service still may open a (limited) browser window directly in your device even when using VPN if using captive network technologies, and your device will be exposed, and talking outside the VPN to a certain degree until you authenticate in the captive network portal.

IMO this is the bigger elephant in the room nowadays that people do not think about - I wrote a proof of concept in FreeBSD that opens a skull pic in the client, before you go the VPN route, my workmates were not that amused.

I would advise that depending on the device, besides Tor or/and VPN, you need at least, to have the latest OS updates done, and a finely tuned firewall running on your device too.

So actually, no, HTTPS and related technologies are only a (small) part of the equation in a security setting and only offer you a false sense of security when used per se.

Rui F Ribeiro
  • 1,736
  • 8
  • 15
  • 2
    Most of this answer, up until the last sentence or so, focus on the limits of using a VPN while the question is really about the limits of using HTTPS. While everything you say sounds correct, I am not sure it is relevant to the quesiton. – Anders Dec 05 '17 at 14:49
  • @Anders Fair enough. However, the question asks for other threats besides using HTTPS – Rui F Ribeiro Dec 05 '17 at 15:33
6

This is exactly a scenario where semi-"opportunistic" encryption (like the mixed plaintext/encrypted HTTP/HTTPS ecosystem) can fail you - at the very least you have to rely on your browser not unexpectedly opening some resource embedded in a webpage via an unsecured protocol (even if a man in the middle downgrades it for you), and also on dodgy certificates not being accepted. For every page, and for everything every page loads.

A VPN, as mentioned, can still tunnel all kinds of malicious traffic to a vulnerable endpoint - and back.

In the absence of truly problematic malware like keyloggers and illicit remote control software, the safest setup would be controlling a trusted remote computer via something like remote desktop or ssh (with or without X11 forwarding), causing all relevant traffic to be via one encrypted channel. Establishing this channel would still need extra diligence (eg verifying certificate footprints manually) to avoid any remaining risk of MITM attacks (which could gain an attacker login credentials in the worst case).

rackandboneman
  • 975
  • 4
  • 9
1

As Norton, a security company, says:

What are the risks?

The problem with public Wi-Fi is that there are a tremendous number of risks that go along with these networks. While business owners may believe they’re providing a valuable service to their customers, chances are the security on these networks is lax or nonexistent.

Man in the Middle attacks

One of the most common threats on these networks is called a Man in the Middle (MitM) attack. Essentially, a MitM attack is a form of eavesdropping. When a computer makes a connection to the Internet, data is sent from point A (computer) to point B (service/website), and vulnerabilities can allow an attacker to get in between these transmissions and “read” them. So what you thought was private no longer is.

Unencrypted networks

Encryption means that the messages that are sent between your computer and the wireless router are in the form of a “secret code,” so that they cannot be read by anyone who doesn’t have the key to decipher the code. Most routers are shipped from the factory with encryption turned off by default, and it must be turned on when the network is set up. If an IT professional sets up the network, then chances are good that encryption has been enabled. However, there is no surefire way to tell if this has happened.

Malware distribution

Thanks to software vulnerabilities, there are also ways that attackers can slip malware onto your computer without you even knowing. A software vulnerability is a security hole or weakness found in an operating system or software program. Hackers can exploit this weakness by writing code to target a specific vulnerability, and then inject the malware onto your device.

Snooping and sniffing

Wi-Fi snooping and sniffing is what it sounds like. Cybercriminals can buy special software kits and even devices to help assist them with eavesdropping on Wi-Fi signals. This technique can allow the attackers to access everything that you are doing online — from viewing whole webpages you have visited (including any information you may have filled out while visiting that webpage) to being able to capture your login credentials, and even being able to hijack your accounts.

Malicious hotspots

These “rogue access points” trick victims into connecting to what they think is a legitimate network because the name sounds reputable. Say you’re staying at the Goodnyght Inn and want to connect to the hotel’s Wi-Fi. You may think you’re selecting the correct one when you click on “GoodNyte Inn,” but you haven’t. Instead, you’ve just connected to a rogue hotspot set up by cybercriminals who can now view your sensitive information.

When everyone know those risks, the minimal thing that there is to do is reduce the risks.

About this, you can read some articles:

Community
  • 1
Emanuel Pirovano
  • 23
  • 5
  • While the quote from Norton is interesting, it does not directly focus on the question. The question is if HTTPS and HSTS does not address these concerns. The quote doesn't really mention that. – Anders Dec 05 '17 at 11:43
  • That isn't the focus but the first question of this post haven't the focus on that protocol, right ? – Emanuel Pirovano Dec 05 '17 at 11:45
  • 1
    The question could be rephrased as "What problems are there with public wifi that HTTPS doesn't solve?" I get the feeling that you are answering the question "What problems are there with public wifi?" – Anders Dec 05 '17 at 13:42
  • So this question is a duplicated of : https://security.stackexchange.com/questions/1525/is-visiting-https-websites-on-a-public-hotspot-secure – Emanuel Pirovano Dec 05 '17 at 14:02
  • Personally, I would say closely related, but not duplicate. "Using public wifi" is an activity that involves much more than "visiting HTTPS websites on public wifi". If you disagree, you can flag the question as a duplicate. – Anders Dec 05 '17 at 14:44
  • 1
    I am agree, i was only asking for understand the point. Thanks – Emanuel Pirovano Dec 05 '17 at 14:45
1

I am not 100% sure what your concern is.

Public WiFi hotspots are not trustworthy, that's right. But the internet is not trustworthy. The sites you visit are not trustworthy. The sites you use to search the web are particularly not trustworthy.

Someone on a public WiFi hotspot might be able to eavesdrop on your connections. Someone will, without any doubt eavesdrop on all your communications. This routinely happens within the provider's infrastructure, at the CIX, at country borders, and at trans-ocean (and sometimes trans-continental) cables. Your trustworthy provider may very well be allowed, and required by the law (they are here!) to record and store detailled statistics about every connection you made, all DNS queries, whatever, and share that information with some moderately trustworthy and some definitively not trustworthy parties, among them organizations from hostile countries.
All the major industry states (not just the USA) have eavesdropping organizations with ten to hundred thousands of people in each, doing nothing but eavesdropping your communications and making profiles about you depending on who you communicate with, when you communicate, what DNS names you resolve, and so on.

Is this a problem for you? Well, if it is, don't use the internet, really.

Someone on a public WiFi hotspot might try to exploit your computer. Well guess what, someone might do that via your home internet connection as well. It's not as easy as being on the same local network for sure, but nowhere near impossible.
My venerable old Windows 7 already considered trusting hotspots being not such a great idea and considers all hosts untrusted in that setting (unless you explicitly tell it something different). That doesn't happen for no reason. But given reasonable settings, being on a completely hostile local network would nevertheless still be reasonably safe. None of the services that were exploited during the last couple of years are even running on my computer (irrespective of the firewall dropping traffic anyway). Just, don't run shit you don't need. The fewer network-accessible services, the fewer exploits (more RAM available and faster booting as free bonus).

There's not really that many reasons to use a public WiFi hotspot anyway (I don't recall ever having used one). One reason might be that you are on the road and need to do something really important online very urgently. OK, I admit, in this context, public WiFi may cause a bad feeling in your stomach, but how often does that happen anyway. Also, your bank hopefuly uses https: and you can trivially verify whether they do, before your enter your account information.

Although people nowadays perceive that they must be online and reachable all day (be honest, when did you last turn off your cellphone?) that is actually not true. You can very well do your banking from home, and you do not really need to be online 24/7 when on the road. Usually, at least.
No, being at Starbucks doesn't mean you have to twitter about it and post a photo of your coffee on Facebook. Who cares anyway? But if you think this is absolutely necessary, and public WiFi is too scary, well, then use your smartphone's LTE connection (which is marginally safer). It's not like you have to use public WiFi.

Another reason to use a public WiFi would be that you are planning to do something illegal where you wouldn't want your identity be too easily pinpointed. Sure, you wouldn't want to do hefty illegal stuff (selling weapons, drugs, snuff movies? terrorism?) from home. But hey, in that case, what's the problem with the hotspot not being trustworthy? I mean, seriously? A teenager sniffing on your traffic at the hotspot is the least of your problems in that context.

Damon
  • 5,001
  • 1
  • 19
  • 26
  • Good point stating "the internet is not trustworthy." But to be clear, just because your bank may use `https:` doesn't make the connection any more secure, not with the proliferation of **TLS interception proxies** we have, and the mindset that it's okay to penetrate secure connections arbitrarily. – Mac Feb 19 '19 at 15:02
  • @Mac: That's true, but TLS interception happens via malware that you _choose_ to install on your computer (and for which you usually even pay money). The root certificates installed on most corporate computers are a similar thing, this is deliberate. Basically you're saying that you are OK with Kaspersky/Avast/Norton (or another) reading your traffic, just as you are OK with their malware making your computer unusable. That has nothing to do with Wifi, or the internet as such, though. It's a personal choice that you can make or not make. TLS as such is, for the common user, pretty secure. – Damon Feb 19 '19 at 15:54
  • Point taken, but I was referring to HTTPS Interception that occurs via _hardware appliances_ such as the Blue Coat proxy by Symantec. – Mac Nov 20 '19 at 14:02
  • 1
    @Mac: Well yes, being a root CA, Symantec can, like most governments, too, see pretty much everything. That is, sadly, part of "the internet is not trustworthy" because all trust that we have is truly just _some random instance_ saying that they are trustworthy, and everybody building on that. I wouldn't know a much better system to tackle the problems of key distribution, though. What PGP came up with in the 90s wasn't practical, and spy-vs-spy exchanging envelopes in a dark alley is even less practical. You'll just have to hope that Symantec won't steal from your bank account. – Damon Nov 21 '19 at 10:36
  • Blue Coat is basically the same as "install custom root certificate" as done on corporate laptops or with antivirus, only you don't need to do that any more because the adversary is already a CA (or buying that service from that CA) and thus capable of generating any fitting certificate they like. So yeah, that's bad luck. Still, using `https://` makes it reasonably safe against _normal_ criminals. Plus, government steals your money anyway (cold expropriation), even if you never log into your bank. So there's nothing to fear about. – Damon Nov 21 '19 at 10:40
0

Nowadays, most sites use HTTPS and set HSTS headers, so the odds that someone can eavesdrop someone else's connection is very low

This assumption is scary bad. It does not matter how many sites set HSTS headers if HTTPS itself cannot be depended upon to provide endpoint to endpoint security. And it can't. Sadly.

Have you heard of a TLS Interception Proxy? They are commonplace. Deployed in schools, universities and libraries and used by employers and coffee shops alike, these hardware proxies (such as WebTitan Gateway or Cisco ironPort WSA) render HTTPS null and void, because during the "secure" connection they introduce a dynamic certificate pretending to be the destination website's official certificate. My browser doesn't know the difference, and if I didn't know better then I'd trust each HTTPS connection on its face.

Initially, HTTPS was designed to prevent MiTM attacks. Today, the TLS Proxy IS the MiTM attack! Whether you're reading your email or checking your bank account balance, you should be under no illusions that HTTPS is actually doing what you expect it to do, that is, secure your connection from eavesdropping. And unless you're connecting through your home WIFI & router, or unless you're using a decent VPN, get used to the fact your connection is probably being decrypted and re-encrypted on-the-fly, without your knowledge or consent.

There's little need to consider the "other threats" suggested by the OP until bona fide encrypted connections are the norm. Currently, they're not, and HTTPS is a farce. (To prevent eavesdropping, use a reliable VPN run by a company that won't store or release records. Use TOR to make the connection even better.)

Why do I assert that HTTPS/HSTS is not really a web browser's security blanket? Because 3 years prior to OP asking the question, it was already exploited and defeated. And just 2 years prior, it was subverted. Further, certain popular implementations of SSL were proven broken as far back as 1998. Even certificate authorities (CAs) are not to be trusted. A brief timeline:

  • 1998 - Daniel Bleichenbacher describes a successful attack on PKCS #1 v1.5, the (then) RSA Encryption Standard (at CRYPTO 98); an assault thought to require a million attack messages to exploit
  • 2009 - Moxie Marlinspike creates SSLStrip to attack HTTPS (demo at Black Hat DC 2009)
  • 2012 - IETF gives us RFC 6797, which implements HSTS, designed to thwart SSL stripping
  • 2012 - Graham Steel publishes a paper (at CRYPTO 2012) demonstrating Bleichenbacher's padding oracle attack needs less than 15,000 messages—not one million as originally supposed
  • 2014 - Leonardo Nve creates SSLStrip+ to avoid HSTS (demo at Black Hat Asia 2014)
  • 2015 - Sam Greenhalgh demonstates HSTS Super Cookies, showing how the HSTS security mechanism is easily subverted to be an invasion of privacy
  • 2015 - Google realizes Symantec and its subsidiaries have fraudulently issued over 30,000 security certificates without proper audits or disclosures
  • 2016 - Google institutes a published blacklist of untrustworthy certificate authorities, dubbed Submariner
  • 2017 - Ars Technica reported that major sites such as Facebook and PayPal tested positive for Bleichenbacher's critical, 19-year-old vulnerability permitting attackers to decrypt encrypted data and to sign communications using the sites' own secret encryption key
  • 2018 - Google updates Chrome to version 70, in order to deprecate trust in the Symantec CA (including Symantec-owned brands like Thawte, VeriSign, Equifax, GeoTrust & RapidSSL); and Mozilla follows suit
  • 2018 - Adi Shamir publishes a paper detailing that modern implementations of PKCS #1 v1.5 are just as insecure against padding oracle attacks; affecting protocols & services like AWS, WolfSSL and the latest version of TLS 1.3 released in August 2018

Currently, to battle issues like "transitive trust," subCAs and the shenanigans of CAs who issue them, e.g. GeoTrust, etc., we have the DANE protocol, designed to "secure" the security certificate—the irony is not to be missed here—via DNSSEC by allowing domain admins to create a TLSA DNS record.

If DANE were widely implemented, I might be more inclined to agree with the OP's low threat assessment, but using DANE means a site needs to DNSSEC-sign their zone, and as of 2016, only about 0.5% of zones in .com are signed.

As an alternative to the poorly adopted DANE, there are CAA records, designed to do the same thing, but the latter mechanism isn't any more entrenched than the former.

It's the end of 2017, and the odds are extremely good someone can eavesdrop your HTTPS/HSTS protected connection.

UPDATE DEC 2018: Whether it's insecure protocols, poorly implemented secure protocols outside the user's purview, secure technology awaiting mainstream adoption, fraudulent authorities issuing unverified certificates, or good old-fashioned hardware-assisted eavesdropping, it's the end of 2018 and I still maintain the odds are extremely good your HTTPS connection is not protecting you.

Community
  • 1
Mac
  • 153
  • 5
  • 4
    The certificate introduced by an interception proxy is rarely signed by a globally trusted certificate authority. If it were, that CA is doing something wrong, and should be untrusted. Should HPKP or any other key/certificate pinning method be used along with HSTS, the proxy wouldn't work anyway. – timuzhti Dec 06 '17 at 04:45
  • For the anonymous down voters, I'm simply refuting the OP's basis of claim that the use of HTTPS & HSTS make eavesdropping a "very low" possibility. – Mac Dec 08 '17 at 16:49
  • Wait **what?** Odds are *extremely* good? If you can't trust the CAs installed on your machine, please uninstall them, and do key pinning yourself for those nessary. Have a *non*anonymous downvote. – timuzhti Dec 11 '17 at 15:26
-3

Your argument would be valid if all wireless users were aware of the security implications associated with web browsing and public hence untrusted wifi networks. WiFi is no threat as much as social engineering is no threat either.

In a nutshell, WiFi&HTTPS do not carry vulnerabilitites but that doesn't mean they do not pose a threat.

jonna_983
  • 84
  • 6
  • 1
    you appear to have not understood the question - the problem posed is not about wifi itself, but about malicious users sharing the network with others - and the question is about the threat - you say there could be but do not talk about them – schroeder Dec 05 '17 at 11:02
  • also wifi and https carry vulnerabilities – schroeder Dec 05 '17 at 11:02
  • I beg to differ. OP claims that the protocols are safe hence public WiFi is safe. The protocols are safe indeed (no unpatched vulnerabilitites for 802.11 or HTTPS atm - even KRACK is almost taken care of) so all problems originate from users who unwittingly or carelessly disregard security errors or messages which devs have very carefully placed within browsers or OS's. – jonna_983 Dec 05 '17 at 13:10
  • 3
    @jonna_983 krack is nowhere near "taken care of". Many phone or router manifacturers simply don't release updates, many people don't update, many people use old OSes. Krack will probably only be near "taken care of" in a decade or so. – ave Dec 06 '17 at 09:03
  • @Avery, I believe that your reply falls within my point. Users have been advised on the security implications of using unpatched (per KRACK) devices yet they still choose to use inseure means. Anyway, my overall point is that users receive all sorts of security notifications while browsing which they refuse to consider. – jonna_983 Dec 06 '17 at 11:17
  • @jonna_983 1) you're assuming that users are tech savvy enough to understand and patch all devices 2) you're ignoring my point of "some if not most devices don't get security patches, especially routers". 3) I've never seen such a notification. I do keep my system updated, but still, I've seen none, even on devices of people that don't update their systems. – ave Dec 06 '17 at 13:46
  • @jonna_983 There's nothing preventing someone from abusing UTF-8 (punycode support) to redirect to an [identical-looking website](https://www.xudongz.com/blog/2017/idn-phishing/) that does have its own certificate. That Apple website from the PoC is has a valid signature, but it sure as hell isn't Apple's! Compare https://www.аррӏе.com with https://www.apple.com and tell me if you can tell the difference from the URLs. – forest Dec 10 '17 at 11:00
  • @forest Thanks, I was completely oblivious to this. I may be missing smth but it seems weird that Root CA's do not prevent this type of attack as it seems trivial to do. – jonna_983 Dec 11 '17 at 12:53
  • How could they possibly prevent this kind of attack? It'd be easier for browsers to mitigate this by displaying the punycode (i.e. https://www.аррӏе.com vs https://www.xn--80ak6aa92e.com, despite the two being identical) for browsers with a language that does not require unicode. – forest Dec 11 '17 at 13:22
  • @forest OK, here goes. Someone tries to issue a punycode domain name: If decode(punycode) != a known domain name for which a valid certificate exists then register the domain. – jonna_983 Dec 11 '17 at 14:55
  • They don't decode to the same domain, they merely _look_ the same. There are quite a few characters like that. It might be possible to keep a table of identical-looking characters, and flag domains that would look otherwise identical, but that's not the job of the CAs. Having a CA police something like that is asking for trouble. Plus if anything, it'd be the job of a nameserver, not a CA. – forest Dec 12 '17 at 01:14
-5

A protocol like https can only be as secure as the medium it is transmitted on, will allow.

That means that even if everything you do uses HTTPS (it probably doesn't for most people), and even if nothing on your end is insecure (it probably is), then the attacker can target your connection to WiFi, your login, scan your device for open ports, and do a lot to get control of the communication or device, making https as effective as a lock on a door with an open door next to it.

Stilez
  • 1,664
  • 8
  • 13
  • 1
    I don't understand the point. If nothing on my end is insecure, then why is a port scan a threat? And what does "target your login" mean? – Anders Dec 05 '17 at 09:06
  • I think what you are meaning to say is that being on wifi itself poses security threats and that VPNs and HTTPs are secondary to those other local threats. But is covered by other answers. – schroeder Dec 05 '17 at 11:07
  • What exactly can the attacker do if only HTTPS is used? – timuzhti Dec 06 '17 at 05:02
  • Faking/poisoning DNS for one thing. Faking the captive port. Modifying headers to force a weaker form of encryption before https can be fully established. Uses that rely on metadata only, such as stalking (if you want to follow a person or check if they are in the room, you don't need to break https, although strictly this is a WiFi issue not an AP issue). DoS on their VPN or other secure access which may fall back to a less secure route. Unrestricted attempts to probe for vulnerabilities (the end device isn't behind a separate firewall). – Stilez Dec 06 '17 at 07:19