How server names are determined

The Internet works with numeric addresses. 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.

In a content filter network extension, where Little Snitch intercepts network traffic, the name is not known in the first place, only the numeric address. 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.

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

Information from the NE framework

If the connecting app uses a high level framework from Apple, the name is routed down to our network extension and Little Snitch can use it. That’s the easy case. However, if legacy functions were used, macOS may or may not be able to provide a name to our network extension. If no name is provided, we use other techniques.

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 web sites on the same Internet address and still they need to serve different content for each site.

In order to solve this problem, many protocols (such as HTTP 1.1 and newer) 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 or the SNI header is encrypted, 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 and in Network Monitor. 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.