32

I've noticed that there is a third-party webservice we utilize programmatically at my job to transmit somewhat sensitive information and I was surprised to see that the endpoint was only using http, rather than https. Upon further investigation it appears that a whilelist is being employed by this webservice, meaning that theoretically only our server that actually utilizes this service should have access.

I'm wondering whether the use of a whitelist is sufficient as a protection against sniffing/MitM attacks? Being a security conscious member of our team, I'm obviously in support of using https anywhere that potentially sensitive data is transmitted, but I'm not sure if that would be overkill or unnecessary when combined with a controlled whitelist.

Obviously a malicious insider on the same network segment as our server may be able to observe this communication in the clear. But for the sake of argument I'd like to assume this situation is unlikely.

beatsbears
  • 475
  • 4
  • 8
  • 39
    "Obviously a malicious insider on the same network segment as our server may be able to observe this communication in the clear. But for the sake of argument I'd like to assume this situation is unlikely. " Never assume that. The insider threat is one of the greatest. – willc Apr 14 '16 at 14:10
  • Good point. You know what they say about assuming ;) – beatsbears Apr 14 '16 at 14:20
  • 4
    "but I'm not sure if that would be overkill" The only overkill with https is trying to avoid it. Arguing against it is likely literally more costly than just using it (because time is money). – jpmc26 Apr 14 '16 at 22:03
  • If its sensitive enough to whitelist then encapsulate it in SSL or SSH. – user2320464 Apr 15 '16 at 02:39
  • 5
    At this point, there's really no reason NOT to use HTTPS everywhere. [Let's Encrypt](https://letsencrypt.org/) just went out of their beta phase, so getting a HTTPS certificate has now become very easy, and free. – Alex Apr 15 '16 at 05:41
  • 1
    White listing is useful to prevent distributed volumetric attack (DoS), because it's cheap to enforce. But it shouldn't be used to replace strong encryption. If you're transferring sensitive information without additional encryption above this third party service, you're right to whistle blow on this. – Lie Ryan Apr 16 '16 at 02:04
  • 1
    Whitelisting and encryption are so completely different that you may as well ask, "Can, or should, whitelisting replace coffee?" – David Richerby Apr 16 '16 at 07:57
  • Replace, no. Augment, absolutely. – Shadur Apr 16 '16 at 10:57

4 Answers4

63

The sniffing problem is about "confidentiality", which whitelisting does not cover, as the traffic can be intercepted and read.

The MitM problem is about "authenticity", which whitelisting does not cover either, as an intercepted packet can be modified without evidence of tampering. I assume the whitelisting uses IP addresses, which can be arbitrarily forced into TCP/IP packets.

psmears
  • 900
  • 7
  • 9
M'vy
  • 13,033
  • 3
  • 47
  • 69
  • 7
    Thanks for this. I assumed it wasn't right to use http, but I didn't want to come off as the alarmist without being armed with some facts. – beatsbears Apr 14 '16 at 14:30
13

If the data is unencrypted, anyone sniffing the packets between your server and their server can see it. A whitelist only lets their server verify that the source of the data. It doesn't assure that no one sniffed it during transfer, or that it wasn't intercepted and manipulated at any point during the process.

In short, encrypt the data, keep the whitelist in place, and set up checksum verification to ensure that what was sent is the same as what was received.

willc
  • 652
  • 3
  • 9
  • 11
    "A whitelist only lets their server verify that the source of the data" Depending on how the whitelist is enforced, it probably doesn't even do that. Whitelisting by MAC? MAC addresses are trivial to spoof. Whitelisting by IP? IPs can also be spoofed. Unless the messages are somehow authenticated cryptographically (e.g. a digital signature with a nonce) the whitelist isn't really doing much to verify the source of the data at all. – Ajedi32 Apr 14 '16 at 15:13
4

When talking about security (in general), it is important to think about what problems you are attempting to solve, and what tools you are using to solve them. These have to align.

If the problem you are attempting to solve is general attacks from the internet, then whitelisting may be a useful tool - to overcome whitelisting, you have to be somewhere on the network between the source and the target, or you have to compromise (possibly only partially) some part of the network between the source and the target (this may be, but is not limited to man-in-the-middle attacks).

Encryption (depending on the specific protocol) solves a different problem, generally traffic sniffing. Combined with this, it may work as authentication (via a shared key for symmetric crypto, public key crypto {possibly backed by certificates} as used by TLS), though this is not necessarily the case - if I connect to my bank via TLS, the TLS protocol gives me a way to authenticate them (by their certificate), but they cannot authenticate me in the same way - authentication is done via webforms or other methods. Client-certificates are also possible, and could be issued to me, which means we both authenticate each other via TLS, I would not need to log in at all. Or, there may be no authentication at all, if the webserver is using a self-signed certificate.

I, personally, would never trust whitelisting on it's own, and when used in combination with TLS, it is of very limited use - each side has (hopefully!) already authenticated the other side, and the location of a proven genuine user is of very limited use. Weak passwords can benefit from ip-address whitelisting, but really you should fix the problem, which is weak passwords.

AMADANON Inc.
  • 1,481
  • 9
  • 9
0

Whitelisting is technically narrowing the possible threats to you to the ones that actually target you specifically. By denying large amount of more general threats through whitelisting you can let your encryption work on full power against a much smaller chunk of threats that can go through whitelisting.

Michael M
  • 1