4

It seems to me that an IP address white list relies on easily spoofed information, while a domain white list, if it forces TLS, at least, relies on the validity of the certificate systems.

I may be framing this question incorrectly, or comparing apples and oranges here, but I still think what I'm trying to get at has a specific answer.

This seems related to the following two questions I came across on this site:


Business units, customers, colleagues, etc. keep asking about IP addresses for security purposes when certified, TLS-enabled domains, sometimes even internally, are available already.

Maybe there's no difference, but I feel like something's wrong, here with the "please send us the IP ranges" approach.

I've seen this get in the way of everything from phone calls to continuous deployment to trying to use GitHub, so I want to know:

IP address filtering vs. TLS domain filtering: Is there an increase in security?

3

tl;dr: different things, both useful for different scenarios, IP whitelisting is not a bad sign

You are indeed comparing apples and oranges.

IP-based filtering happens at the network layer of the OSI model, whereas certificate validation happens on the transport (and/or application) layer.

Allowing access only to/from specific IP addresses reduces the possible attack vectors whereas certificate validation is ensuring the connection is indeed with the expected party.

IP address based filtering is rather a

I don't want to talk to people, except my friends

approach, whereas certificate validation is rather a

Let's see what you have to say and then decide if we talk

approach.

There are several reasons IP based filtering is used, here are some that I find important to mention:

  • It reduces the surface area of a network or machine massively

    If you let your system communicate with everyone, you must be sure that all communicating processes are following the rule.

    If you choose to use IP address based whitelisting, you at least can make sure that the communicating processes, as far as they establish connections, are expected to not try and break your system.

  • It is easy to maintain

    A system-wide setting is easier to update than, let's say, 20 web applications.

  • It is fast

    establishing a TLS session is relatively costly, discarding packets based on origin is not.

So if both technologies are used together, they are very useful - and being asked for IPs for a whitelist is no sign of bad security meassures. Often, quite the opposite is true.

There is another part of your question I'd like to address:

It seems to me that an IP address white list relies on easily spoofed information[.]

While it is true that you can spoof the originating IP address of a packet, this usually does not allow to establish connections.

A TCP handshake will fail and on UDP you are not getting the response - except if you are a man in the middle.

  • // , I definitely prefer system-wide settings, myself, but when dealing with literally thousands of hosts from OpenStack, Rackspace or auto-scaled systems (shudder), I feel like it starts to limit how far down the OSI model I can go with this stuff. Got any suggestions for how I can change the question to compare apples to apples, oranges to oranges? – Nathan Basanese Apr 12 '16 at 19:41
  • 1
    While that is true, there are ways to have dynamic instances be added to the whitelist. And sometimes, restricting to blocks might be a better idea - or in fact dropping the whitelist. That is a case-by-case decision though. – Tobi Nary Apr 12 '16 at 19:43
2

Even if you are only care about the kind of TLS where the certificate is required to match the hostname (like done in HTTPS, but there are use case of TLS which don't do this) then there are still differences in scope and ability of filtering by IP address vs. hostname from the TLS handshake.

  • Advantage of hostname based filtering:
    There might be several different names behind the same IP address and port. The client needs to address a specific name using Server Name Indication (SNI) in this case. By checking the hostname given in the ClientHello and in the certificate the server can do more precise filtering then just based on the IP address.
  • Disadvantage when using only hostname based filtering:
    If you only check if SNI and certificate contain the correct hostname your checks can easily be bypassed by using self generated certificates. Thus you must additionally check that the certificate got signed by a CA you trust.
  • Advantage of IP address based filtering:
    Checking for IP address is earlier and faster. It is done with the first SYN packet needed to establish the TCP connection. Checking at the hostname level can only be done once the intended hostname gets known, i.e. during the TLS handshake which is done after the TCP connection is established. Apart from that it is much harder because you need inspection at the TLS layer vs. only inspection at the network layer.

To get the best results you should actually do both: filter by IP address for a fast and early match and if this passes and the TCP connection got established check the TLS handshake for the expected hostname in case multiple names are used for the same IP address.

  • // , So you're saying one doesn't have to choose just one, but that if you can implement both, that's the way to go? – Nathan Basanese Apr 12 '16 at 23:37
  • 1
    @NathanBasanese: if you aim for having a filter which provides the most precise restriction and provides early blocking then you should do both. – Steffen Ullrich Apr 13 '16 at 4:29
  • // , I guess the way to handle dynamic, distributed cloud systems would be a Virtual IP and multicast. – Nathan Basanese Apr 13 '16 at 21:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.