HTTPS vs. VPN for communication between business partners?
A business partner has asked to set up a site-to-site VPN just so that a few servers can communicate with each other over HTTPS. I'm convinced this isn't necessary, or even desirable. To be fair it must be part of a wider policy, potentially even a legal requirement. However I'd like to convince them to simply offer an IP to us (and us only) and a port of their choosing for HTTPS.
Has anyone had a similar experience, or had to come up with a cast-iron argument against a VPN?
Allow me to expand a little - we have a web service that initiates a connection to the partner's corresponding service using an encrypted HTTP connection. The connection uses a client certificate to authenticate. The connection is firewalled so only our IPs can contact the service. So why is a VPN necessary?
Solution 1:
I would say that the VPN can be considered defense in depth. Look at all the recent attacks against SSL and HTTPS, which render the communication breakable. If you have a VPN between the sites which is not SSL based, then you are just adding another layer of defense.
Also, if they want to extend past HTTPS in the future (and they most likely will, everyone does), then the VPN can accommodate that.
I would second Alnitak's suggestion to do mutual auth with SSL, so that will require certificates on both sides.
Solution 2:
Well, layering HTTPS on top of a VPN does seem slightly excessive given that it's encrypting everything twice, but it's only slightly excessive.
Should you mutually agree to use HTTPS without the VPN, then do at least go for client-side certificates and not just passwords. This would be more secure than allowing just any machine from either site to connect, and would prevent someone who happens to figure out a password from accessing the system.
Solution 3:
IMO, a VPN is mandatory when you want to talk between two networks and HTTPS the 'optional one' (but might still be desirable, if only for 'defense in depth' argument).
Once you get the VPN running, it's easy to run whatever service you want on it, and all the security-related work is already done, including any NAT issue, and also hiding your ports from the outside.
Think about the future, what if you later want to add more services? would you piggyback on your HTTPS webservice? or use another port, and repeat all required safety validation? With a VPN in place, it's really simple to do.
Solution 4:
The VPN should/can be much more secure than HTTPS but there really shouldn't be an issue using both together unless you're on a really slow link. I'd just accept the complexity knowing you'll be watertight.