7

I am trying to identify https sites my computer is communicating with. I understand that when I enter a website like www.example.com, a DNS call is made, the IP address of the website is obtained, and then the remaining communications with that IP address are encrypted.

Given that IP address of the destination server is still visible, that can be translated into the actual website using a reverse DNS lookup.

I have set 'Resolve network (IP) addresses" etc. to true in Preferences. And then enter a display filter tcp.port == 443 && ip.dst_host == "example.com", but entering www.example.com in the browser doesn't produce any packets even though the websites does load on my browser.

What am I doing wrong in Wireshark?

Improve this question
3
  • What you actually probably want is to check the SNI field of the SSL negotiation: superuser.com/q/538130/11945
    – Josh
    Commented Nov 5 at 14:28
  • 2
    Note that "example.com" and "www.example.com" are separate domain names.
    – Paŭlo Ebermann
    Commented Nov 6 at 2:01
  • NOT ALL WEB CONNECTIONS ARE ENCRYPTED. If you specifically enter https://domainname it is, but if you only enter domainname browsers usually (still) default to unencrypted HTTP on port 80 not 443. Many servers (but not all) after you first connect with HTTP redirect to HTTPS, and some set HSTS so that subsequently entering domainname uses HTTPS; some servers also have HSTS 'preload' so that initially entering domainname DOES use HTTPS. You need to know how to read your browser's status bar to know which of these occurred.
    – dave_thompson_085
    Commented Nov 6 at 10:29

6 Answers 6

Reset to default
12

You are not doing anything wrong probably, but the reverse mapping doesn't have to match the forward mapping.

Best Buy uses the Akamai CDN service, so www.bestbuy.com for me points to 23.32.24.193, which resolves to a23-32-24-193.deploy.static.akamaitechnologies.com.. This may be shared with hundreds or thousands of other websites also using Akamai.

Improve this answer
1
  • You could add some more information how CDN (content delivery networks) operate. The OP maybe had the idea that the DNS query resolves to a single physical machine hosting the website, which is not true for most big websites.
    – Falco
    Commented Nov 8 at 9:44
7

I have set 'Resolve network (IP) addresses" etc. to true in Preferences. And then enter a display filter tcp.port == 443 && ip.dst_host == "bestbuy.com", but entering www.bestbuy.com in the browser doesn't produce any packets even though the websites does load on my browser.

  1. As @vidarlo says, forward and reverse lookups can be different (they usually are)

  2. A DNS name may have multiple IP addresses

  3. DNS data should be cached by your computer

  4. HTTP[s] data can be cached on your browser (depending on how the website is configured)

If your objective is to capture the data then have a look at what's available in Developer Tools in your browser or configure your DNS server lo log all requests or route your trafficvia a forward proxy which logs the requests.

Improve this answer
7

As mentioned by the other answers, DNS queries and reverse DNS lookup are not always helpful in finding out the actual sites that your computer connects to.

One other option is to look for the server name indication (SNI) in the TLS handshake. Wireshark helpfully puts this in the info column. You can use the filter tls.handshake.type == 1 too look for these handshake packets.

Note: this only works if you capture the start of the TLS connection. Connections that already exist when you start the capture won't show up. Also, I believe the SNI is only used by the destination server to serve the correct site, so malicious software (spyware etc.) could send a fake SNI to its home server to make it look less suspicious.

Example (recorded from a Docker container doing queries with curl to keep the capture cleaner):

Screen capture of Wireshark showing TLS handshake packets with SNI

Example when I visit bestbuy.com in a fresh browser:

Another screen caputre of Wireshark

Improve this answer
1
  • 2
    Strictly speaking, SNI doesn't even need to be used to serve the correct site, just the correct certificate. It's possible to make a connection using one hostname in SNI, but then send a different hostname in the Host header, which may work depending on how the server is configured (some CDNs, such as Azure Front Door, will honor the Host header and disregard the SNI, for example), and can be a surveillance evasion technique.
    – James_pic
    Commented Nov 6 at 11:05
5

The "Resolve network addresses" option uses DNS to query the PTR ("pointer") record for a given IP address. The data that is returned from DNS for a PTR record can be anything, and is frequently nothing at all.

If you do get a response, the data contained in PTR record is usually just informational. They frequently do not map to a real DNS entry.

As such, you'll likely not have a huge amount of success in using them to match conversations in wireshark to domain names.

Improve this answer
2

Touching on a side point...

a DNS call is made, the IP address of the website is obtained, and then the remaining communications with that IP address are encrypted.

No, not really. One server can serve many sites with different TLS certificates. To distinguish which "virtual host" you should be connected to, the initial request will include SNI (server name indication) which reveals the host name (e.g. www.example.com) in plain text. Only after that the encrypted connection will be established.

Improve this answer
0

HTTP3 is based on UDP, although it is still using the port 443. That might be a reason, why you don't see it.

Modern Javascript frameworks and browsers can hook the site visit events. In this case, you will see various URLs in the browser address, without packet sent out. Do a hard reload (ctrl-shift-r in firefox, probably same in chrome).

Your friend might be also SNI. Google for "server name indication". That makes the hostname visible in the first some hundred bytes of the TLS handshake. It is known hole in the TLS (HTTPS), and there are already at least plans to prevent it. But in most cases, at the beginning of a HTTPS connection, the first some hundred bytes still contains the server name. It technological reason is that the same IP might have multiple name-based virtualhosts with different encryption keys or TLS settings.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .