17

I know that with SSL/TLS, man in the middle attacks are not possible. For example if Alice and Bob are trying to communicate and Trudy is trying to perform a man in the middle attack, then when Alice gets the public key from Bob (but really it is Trudy tricking Alice), the public key will not match with the certificate authorities and therefore not work.

I know with SSH, only the first connection to a server is possibly open to an active man in the middle attack. This is because during the first connection, the client records the server's public key in $HOME/ssh/known_hosts file. Every connection after that checks this file to make sure the public keys match.

But how does VPN encryption work with connection set-up? Are certificates used for passing the symmetric keys like in SSL/TLS? If not, does this not make VPNs vulnerable to active man in the middle attacks during key exchanges?

Steven K
  • 275
  • 1
  • 2
  • 6
  • 1
    Wow, you "know"! If only that were true, how much easier life would be! Sadly it is not true except in some theoretical sense. If only because for it to be true, BOTH the server and the client have to be equally secure and well configured. There are plenty of examples to the contrary including some very nasty TLS issues reported recently. – Julian Knight Jan 02 '15 at 23:59

2 Answers2

23

In order to protect from a man-in-the-middle attack, at least one of the endpoints of the communication needs to have some prior knowledge about the other endpoint. It's usually up to the client to verify that it's talking to the right server, because servers tend to allow potentially any client to connect to them. The general term for the kind of infrastructure that provides this prior knowledge is a public-key infrastructure.

In the case of HTTPS, the prior knowledge normally comes with the intermediate step of a certificate authority. A web browser contains a predefined list of CA with their public keys, and accepts a website as genuine if it can demonstrate that its public key has been signed by the private key a CA.

In the case of SSH, the prior knowledge normally comes from having contacted the server previously: the client records the server's public key and refuses to proceed if the server's public key is not the recorded one. (This also exists for HTTPS with certificate pinning.) On the first connection, it's up to the SSH user to verify the public key.

There is no standard followed by VPN software. You need to read the documentation of your VPN software. In enterprise deployments, it is common to either deploy the server certificate to employees' computers alongside the VPN software, or require the employee to make a first connection to the VPN from inside the company network where a MITM attack is not feared. The certificate is then stored in the VPN software configuration and the VPN client will refuse to connect if the server's public key changes.

If you're deploying a VPN service for your own use or for your organization's use, you should take care of provisioning the server certificate at installation time, before you go out in the wild. If a secure network is not available, you'll need to rely on some other communication channel to send the certificate. It could be an email, if that's how you identify users, but it would be best to rely on a pre-existing infrastructure such as GPG keys (send the certificate in a signed email) — which of course only shifts the problem to how to verify the GPG key.

If you're using a cloud-based VPN service, that service should provide you a way to verify their certificate (e.g. a web page served over HTTPS) and should document how to install the certificate or how to verify it on first use. Again, there isn't a single process that all VPN software follow.

Community
  • 1
Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • 1
    Great answer! This helped clear a lot! I would upvote if I had the rep. – Steven K Jan 06 '15 at 21:19
  • 1
    @Gilles - My understanding is that with proxies for example is that is that since they are intermediaries, they are essentially perform a man in the middle attack so even with PKI, it's still possible. – Motivated Feb 01 '19 at 17:31
  • 2
    @Motivated If the proxy just forwards encrypted traffic without being able to read the content or modify it undetected, it isn't really a proxy but more like a router. A lot of HTTP proxies do that for HTTPS. If the proxy is able to read the content (this is usually called a “middlebox” in TLS context), then it needs to have the private key for a certificate that the client trusts, i.e. the client needs to authorize the proxy to be a man-in-the-middle. – Gilles 'SO- stop being evil' Feb 01 '19 at 17:53
  • 1
    @Gilles - Yes that it's generally common that private keys are deployed in a corporate environment. Equally, it's found with the installation of software such as antivirus. Are VPNs open and subject to the same issue? – Motivated Feb 01 '19 at 18:00
  • 1
    @Motivated Typically such corporate environments block VPNs other than the corporate VPN, and the corporate VPN's endpoint is controlled by the company. There's a difference in the way VPNs are typically configured compared to web browsers: web browsers normally need to be able to access any website, so they have a large number of trusted root certificates, whereas VPN clients often don't use PKI, you just configure the server's public key or a certificate signed by a private CA. – Gilles 'SO- stop being evil' Feb 01 '19 at 18:05
  • @Gilles - What about public/consumer VPNs? – Motivated Feb 01 '19 at 18:31
4

VPNs will protect against many MiTM's if set up properly, but not all of them. A VPN will typically protect against most MiTM's between one's computer and the gateway of the VPN, but once the message/traffic has reaches its destination it is only semi-anonymized and not 'fully anonymous' meaning there will be one or (typically +) more than one attack that can infilitrate and modify traffic contents. In addition, PPTP, LT2P, and WPA2 all have known flaws that can make them vulnerable to both MiTM and other similar attacks. WPA2 specifically is vulnerable to dictionary attacks. For further reading related to what I wrote and to add data/context please see below:

https://help.riseup.net/en/vpn/security-issues

http://www.computerweekly.com/feature/White-Paper-The-Achilles-heel-of-VPNs-the-man-in-the-middle-attack

The first link is to the point and easy to read while the second link provides more details.

Jacob E Mack
  • 41
  • 3