Why HTTPS alone won’t keep you safe on public WiFi

Most websites now use HTTPS to encrypt your connection and add an additional layer of protection to your data. But if you are on public WiFi, using HTTPS without a VPN means that some of your data will still be vulnerable.

The Hypertext Transfer Protocol Secure, or HTTPS, encrypts the traffic between your device and a website, making it difficult for intruders to observe the information being shared. It also provides signatures, or HTTPS certificates, that allow you to verify that the site you are on is run by who it claims it to be. HTTPS has become a standard security feature for nearly all websites.

If HTTPS encrypts your connection with a site, then isn’t public WiFi safe? Unfortunately, HTTPS does not encrypt all your data, like DNS queries. If you are using public WiFi without a VPN, you are putting yourself at risk.

How HTTPS works

HTTPS uses the Transport Layer Security (TLS) protocol to secure the connection between a web browser and a website. A protocol is simply a set of rules and instructions that govern how computers communicate with each other.  The TLS protocol is the backbone of securing online connections. It’s what allows you to enter your login credentials, browse websites, or perform online banking without others seeing the contents.

TLS uses private-key cryptography. A key is simply a code for computers involved in message transmission, and a private key is one that is not open to the public. To ensure the integrity of their connection, your browser and the Internet server initiate a “handshake” by sharing a public key. Once the handshake is established, the server and browser negotiate private keys to encrypt your connection. Each connection generates its own, unique private key, and the connection is encrypted before a single byte of data is transmitted. Once the the encryption is in place, intruders cannot monitor or modify the communications between the web browser and website without being detected.

TLS also supplies digital certificates that authenticate the credentials of websites and let you know that the data is from a trusted source (or a site who claims to be one). A digital certificate is issued by a certification authority.

This system still has certain vulnerabilities, as we will discuss below, but it is considered secure. The first vulnerability that using public WiFi without a VPN exposes you to is the fact that TLS does not protect domain name system (DNS) queries (yet).

What is a DNS query?

The domain name system translates human-friendly URLs into numerical IP addresses that computers can understand. For example, to visit our site, you type in the URL www.protonvpn.com, but your computer sees it as [185.70.40.231]. To find this number, your web browser uses what is called a DNS resolver, which is usually supplied by your Internet service provider. Think of this resolver as a sidekick who scurries around translating the URL of the site you wish to visit into its IP address.

Your DNS request is not encrypted. An intruder can observe your DNS queries and your DNS resolver’s responses to them. This leads us to the first attack you could suffer if you use public WiFi without a VPN: DNS leaks.

DNS leak

If someone were to monitor your DNS queries, they would have a list of all the sites you visited along with your device’s IP address. Given the weak security of most public WiFi hotspots, it would be relatively simple for an intruder to gain access to the network and then log your DNS queries. Your data could still be at risk even if there is no intruder because the resolver on the public WiFi could harvest your data itself.

DNS spoofing

A DNS leak allows an intruder to monitor your activity, but if an attacker spoofs your DNS requests, they can redirect you to a malicious site they control. Also known as DNS poisoning, this happens when an attacker pretends to be your DNS resolver. The attacker then spoofs the IP address for a target website and replaces it with the IP address of a site under their control. The URL would be the same as the site you were intending to visit, but the site would be under the control of the attacker. Modern browsers will generally alert users that they are on a site without HTTPS, and this attack won’t work for HTTPS sites that have a certificate.

However, with a variation of DNS spoofing, an attacker could send you to a site with a slightly different URL from the one you were intending to visit. Think “protomvpn.com” instead of “protonvpn.com”. Moreover, this type of fake site can use HTTPS and have a valid certificate. Your browser would show a green lock next to address, making it harder to detect.

Punycode

Unfortunately, with recent Punycode attacks, hackers have found a way to make two websites with the same URL and a valid HTTPS certificate. Punycode is a type of encoding used by web browsers to convert all the different unicode characters (like ß, 竹, or Ж) into the limited character set (A-Z, 0-9) supported by the international domain names system. As an example, if a Chinese website used the domain “竹.com”, in Punycode, that would be represented by “xn--2uz.com”.

Intruders discovered that if you reverse the process and enter Punycode characters as a domain, as long as all the characters are from a single foreign language character set and the punycode domain is an exact match as the targeted domain, then browsers will render it in the the targeted domain’s normal language. In the example used in The Hacker News article linked above, a researcher registered the domain “xn--80ak6aa92e.com” which appeared as “apple.com”. The researcher even created this fake apple site to demonstrate how hard it is to tell the sites apart using URL and HTTPS information alone.

As the researcher’s example demonstrates, a punycode site can implement HTTPS and receive a valid certificate, making it very hard for you to detect you are on a fake site. Only by examining the actual details on the HTTPS certificate can you differentiate between “xn--80ak6aa92e.com” and “apple.com”.

Fortunately, many browsers have already addressed this vulnerability and most would now show the address as xn--80ak6aa92e.com

TLS downgrade

However, attackers can also defeat HTTPS by attacking TLS itself. They do this by fooling your web browser into negotiating a connection via previous versions of TLS that have been rendered insecure. Thus, your browser will show the green lock indicating the connection is technically protected, but your protection is provided by a weaker protocol. Web browsers allow backward compatibility to sites that use these old protocols because, otherwise, these sites would be inaccessible.

There are several different TLS downgrade attacks, but they all focus on disrupting the handshake of the most recent version of TLS, TLS 1.3. TLS 1.3 does not offer an RSA key exchange, which is the vulnerability most downgrade attacks target. However, TLS 1.2 does, and it is still a relatively common protocol on the Internet. If you visit a website that uses TLS 1.3, an attacker can intercept your browser’s initial connection attempt and forward a spoofed request to the Internet server with the older TLS 1.2 protocol and a phony RSA key at the beginning of the TLS handshake. Once the connection is established using TLS 1.2, your browser will encrypt a shared secret with the phony RSA public key, then the server will receive and decrypt it. The attacker can target this shared secret and decrypt it, allowing them to see all your data, including passwords, or even actively take over your connection.

Use a VPN on public WiFi

These are just some of the vulnerabilities you face when using an unsecured public WiFi network. Even if you visit a legitimate site with properly enforced HTTPS, it could contain images or scripts from sites not protected by HTTPS. An attacker could then use these scripts and images to deliver malware onto your device.

A trustworthy VPN can protect you from all of these vulnerabilities. A VPN encrypts your traffic and routes it through a VPN server, meaning that your Internet service provider (or the owner of a malicious WiFi hotspot) cannot monitor your online activity. This additional encryption will protect your connection from a TLS downgrade attack.  

Thorough VPN services, like ProtonVPN, also run their own DNS servers, so that they can encrypt and process your DNS queries. ProtonVPN’s apps protect you from a DNS leak by forcing your browser to resolve DNS queries via our DNS servers. We even protect your DNS queries if you are disconnected. Our Kill Switch feature instantly blocks all network connections if you are disconnected from your VPN server, keeping your data from being exposed.  

ProtonVPN’s Free VPN plan offers everyone a free, simple way to protect their Internet connection against these attacks. With our free VPN service, you never have to use public WiFi without a VPN again.

Best Regards,
The ProtonVPN Team

You can follow us on social media to stay up to date on the latest ProtonVPN releases:

Twitter Facebook | Reddit

To get a free ProtonMail encrypted email account, visit: protonmail.com


The post Why HTTPS alone won’t keep you safe on public WiFi appeared first on ProtonVPN Blog.


*** This is a Security Bloggers Network syndicated blog from ProtonVPN Blog authored by Richie Koch. Read the original post at: https://protonvpn.com/blog/public-wifi-and-https/