Determining server names

The Internet Protocol (IP) works with numeric addresses only. Since people prefer to use names, there is a service that translates names to numeric addresses, similar to a phone book. This service, the Domain Name System (DNS) is a distributed hierarchical database.

At kernel level, where Little Snitch intercepts network traffic, it sees only numeric Internet addresses, no names. In order to match rules, a name must be found for the address.

Although there is a “reverse phone book” (reverse lookup) for Internet addresses, it is of little use for our purpose. A name can resolve to multiple Internet addresses and multiple names can resolve to the same Internet address. The reverse lookup usually returns just one of the names for a computer and that’s rarely the same name as used to initiate the connection in the first place.

Little Snitch uses two strategies to find a server’s name when given its Internet address:

DNS sniffing

Little Snitch watches all processes when they resolve names to addresses and keeps track of which process knows what. If it encounters a connection attempt, it looks at the Internet address and which process is using it. Then it checks how the process came to know it, which name it used to obtain the address.

If the process can know only one name for the address, we are done, we have the name. If the process resolved multiple names with the same Internet address as result, we have to dig deeper.

Deep packet inspection

Little Snitch is not the only one who needs to know computer names. A content delivery network, for example, hosts many customers on the same Internet address and still they need to serve different content for each customer.

In order to solve this problem, many protocols (such as HTTP 1.1) send the server’s name as part of every request. If DNS sniffing did not provide a unique name, Little Snitch allows the process to connect, regardless of the current rule set and captures the first request sent. The request itself is not passed to the server yet. Little Snitch inspects the protocol headers. If it can find a server name, we are done. Little Snitch matches rules given to that name and either passes on the delayed request or discards it and closes the connection.

Little Snitch does not intercept encrypted communication (SSL/TLS). Looking at the (unencrypted) Server Name Indication (SNI) header is sufficient to obtain a server name.

If no unique server name is found

Little Snitch may still fail to determine a unique name. If the process looked up multiple names with the same result and uses a protocol which does not transfer the server name, we have a set of names, not a single name.

In this case, Little Snitch uses the Internet address for rule matching and presents this address to the user in connection alerts. It checks whether, by chance, all names are in the same domain (e.g. www.google.com, books.google.com and maps.google.com). If they are, it checks whether a rule for the domain matches and applies it. If not, it adds this information to the connection alert.

Incoming connections

If an incoming packet is a connectionless response to an outgoing request (e.g. UDP based protocols), Little Snitch counts it as received data for the outgoing request, treating the conversation like a connection.

For spontaneous incoming connections, Little Snitch cannot determine a remote computer name. All the information we have is its Internet address. Incoming connections are therefore always displayed with a numeric address only.