Can or should whitelisting replace encryption?

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.


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.


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.