2

I always heard that entering passwords or any sensitive information while using a public wifi spot is safe only when visiting an HTTPS website, ensuring that the URI and certificate are valid.

Many wifi spots in my country (France) are badly administered and I hardly doubt that they are configured correctly. I would suppose that it won't be difficult to set up a rogue DHCP.

Imagine that a hacker using the machine 192.168.1.50 sets up a rogue DHCP which specifies that the DNS server is located at 192.168.1.50. When I query the new DNS server for the IP of mail.google.com, instead of giving the real IP such as 172.217.18.133 googlemail.l.google.com, it gives the wrong one, 192.168.1.50 googlemail.l.google.com.

Since the hacker now controls any communication between the victim and the outside world, he could now reuse the real certificate issued by GeoTrust Global CA for mail.google.com domain when I access the HTTP server at 192.168.1.50. Since the certificate is linked to the domain name, but the domain name matches, the browser shouldn't be able to figure out that something is wrong.

I imagine that I'm missing something; otherwise, many wifi hotspots would be hacked this way and HTTPS over wifi won't be considered safe any longer.

What's wrong in my reasoning?

Community
  • 1
Arseni Mourzenko
  • 4,644
  • 6
  • 20
  • 30
  • To avoid these type of DNS attacks, always configure your DNS settings manually . I recommend [`1.1.1.1`](https://1.1.1.1/) . Also please check for any new DNS entries in your [hosts](https://en.wikipedia.org/wiki/Hosts_(file)) file. – nocut Sep 01 '19 at 09:05

3 Answers3

8

Since the hacker now controls any communication between the victim and the outside world, he could now reuse the real certificate issued by GeoTrust Global CA for mail.google.com domain when I access the HTTP server at 192.168.1.50.

No he can't. To identify yourself with a certificate (which needs to be done to fake the server) you need to have access to the private key of the certificate, which is not available by the attacker. Thus HTTPS is safe against DNS spoofing.

For more details why this is the case see How does SSL/TLS work?.

Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • You could present a self-signed certificate though and hope the user clicks "continue" (which most probably will do... since they want to access the site). – mroman Jun 26 '18 at 13:35
5

Steffen is right in saying that the hacker cannot fake the remote server certificate over HTTPS and therefore cannot intercept the encrypted data exchange without the user getting invalid certificate alert warnings. However:

  1. This does not prevent SSL Stripping attacks.

  2. This does not prevent sessions fixation attacks over HTTP (the difficult bit is predicting the site the user will access via HTTPS.)

Both are preventable with HSTS (but the latter is a result of a fault in the implementation of the site too.)

A further question mark arises over the trust placed in the Certificate Authorities and particularly those which might be present in the systems store of root certs (such as those recently found in Dell and Lenovo supplied PCs). While this is not specific to the rogue AP scenario, there are locations where high concentrations of users will be connecting to a known website.

However do note that these all leverage a security failure elsewhere.

Arseni Mourzenko
  • 4,644
  • 6
  • 20
  • 30
symcbean
  • 18,278
  • 39
  • 73
1

The certificate can indeed be faked, nonetheless the browser will throw an error.

However let´s is suppose a rogue router/DNS or an attacker are listening in http/DNS to google.com and redirect you to a site with a slight typo.

You are talking with a friend, or chatting up the server, and you only notice too late after typing in the password, that it is a phishing site.

Or the http redirection simply installs malware or tries to explore browser vulnerabilities.

When browsing, you also do not only use HTTP sites, but you are also using a potentially hostile DNS service. The fact for instance that you have hardcoded 8.8.8.8 (Google) or other DNS servers wont help you much. As a matter of fact, in our corporate VPNs I do intercept DNS requests via firewall rules, and they are done with the corporate DNSes no matter what the client has setup by hand. A rogue router can do that to, and some more dubious ISPes are doing that already.

There can also be a potentially bad actor connected to the same AP that is conducting an ARP spoofing attack. Having an AP compromised is the least of your worries. Or you can be connecting to a fake AP. In fact, a couple of Windows malware had the interesting trait of creating a fake AP with the SSID of "Free Public Wifi" or something similar.

Bad stuff happens.

As such it is considered a standard security practice to use public wifi with a strong firewall, an up-to-date OS, and a VPN connection, that will provide with a trustworthy virtual connection to the outside, and with DNS services.

Additionally, in OS/X and iPhone, you can also install an on-demand VPN profile, that will guarantee no connection is ever established to the outside without first the VPN going up.

I will also link you to a related thread:

Is HTTPS able to prevent ARP poison attack in LAN?

Rui F Ribeiro
  • 1,736
  • 8
  • 15