4

My question is about how an SSL VPN connection such as OpenVPN is protected against MITM/Spoofing attacks on a public Wifi.

For example, if somebody has a 'pineapple' or router setup as a honeypot gateway acting as a proxy does the act of authentication between the client and OpenVPN server protect it from spoofing or MITM. Does the initial authentication using TLS and the exchange of server public key (certificate) and comparison between that and the CA certificate already stored on the clients device identify whether the OpenVPN server is who it actually says it is?

If I have got that wrong can somebody explain the process and if it is correct is there any other point along the handshake that is susceptible to MITM attacks?

Thank you all

user843521
  • 61
  • 1
  • 4
  • That relates to HTTPS with which the handshake is authenticated by checking a public certificate which has been signed a trusted Certificate Authority. In the case of VPNs from my understanding they create their own CA and sign their own server and client certificates. Is the server signed certificate authenticated by comparison against the server CA certificate stored on the user's device to prove the server identity? – user843521 Nov 23 '14 at 16:18
  • @jameskgowan Yes, the CA certificate (or the public key itself) is stored on the client device. – Gilles 'SO- stop being evil' Nov 25 '14 at 13:07
  • [Here's a post](https://openvpn.net/archive/openvpn-users/2005-06/msg00018.html) from the author of OpenVPN on their mailing list which goes into a lot of detail about this question. – GDP2 Sep 05 '17 at 23:46

1 Answers1

5

In the case of OpenVPN the certificate is already known to the client, there is no exchange at that point, so MiTM is mitigated based on the idea that they would have to compromise the server cert in order to mislead the client into communicating with the middle device.

If the MiTM presented an alternate cert for communication, the client would reject it, likewise the best the middle attacker could do is present authentication for the client, which would result in a communication they couldn't read because they lack the private key material to decode the stream.

Compromise of something like OpenVPN is notoriously hard, provided the OpenVPN server is configured adequately. The security model of that product is based on layers of security, requiring an attacker to accomplish multiple attacks on unrelated code trees simultaneously. (I'm assuming best case scenario here using tls-auth is properly implemented etc)

The CVE list is small http://www.cvedetails.com/vulnerability-list/vendor_id-3278/Openvpn.html with most falling in the range of DoS as opposed to actual integrity leaks. To my knowledge, there hasn't been any compellingly successful MiTM attacks against the product.

There might be some alphabet organizations out there capable, but the average pineapple user isn't going to be able to do much here.

atyoung
  • 111
  • 3
  • That's an excellent response thank you. So how is the initial connection made between client and server? What items are exchanged? Also which certificate is used to encrypt the exchange of the symmetric key used to encrypt the tunnel? Am I correct in saying that it is practically impossible to decrypt the communication which carries the exchange of the symmetric key and that the symmetric key would be so large that it would be difficult to decrypt that? – user843521 Nov 23 '14 at 19:50
  • You are correct, because the exchange is dependent on having access to the servers private material, certainly a non-trivial task. That falls into the realm of game over scenario, where your provider is already compromised. – atyoung Nov 23 '14 at 19:55
  • Which key is used to initiate the encryption of the symmetric key? – user843521 Nov 23 '14 at 19:57
  • And if the certificates are used to provide adequate authentication what is the need for 2nd Factor Authentication such as standard username/password combination or OTP? – user843521 Nov 23 '14 at 20:05
  • It depends on the configuration honestly, OpenVPN can use either paradigm, most commonly in commercial VPN providers they use the public/private key model. Symmetric Key based openvpn is more frequently used with people setting up their own VPN to a home network. Above the fold google result on openvpn configuration. http://linuxconfig.org/vpn-virtual-private-network-and-openvpn – atyoung Nov 23 '14 at 20:06
  • Typically most use tls-auth to handle the authentication portions, this is based on certs, which encode the exchange of public keys between client and server. This is all predicated on having the cert package from the VPN provider, so in order to expose MiTM, one would have to have the servers private key material in order to grab the client cert. The client would be presenting it's cert to the server via the servers already present cert contained in the client package. – atyoung Nov 23 '14 at 20:12
  • So basically does the OpenVPN session begin at 'Point 4' of the TLS handshake protocol described in this Wikipedia page? http://en.wikipedia.org/wiki/Transport_Layer_Security – user843521 Nov 23 '14 at 20:36
  • Sorry my last comment must be incorrect as the OpenVPN setup indicates that only the client certificate, key and CA certificate files are needed on the clients end, therefore to get the server's public key it must have to request it at some point. I must be missing some fundamental steps of how the OpenVPN connection is setup. I believed the client connects back to the server specified in it's configuration file, the server responds and then issues it's public key which is certified as genuine by comparison between that and the CA certificate - is that correct? – user843521 Nov 23 '14 at 20:39
  • Most VPN providers give you the server public key with their bundle, so no exchange is necessary. That said if they are using a legitimate certificate authority like verisign or the like, then a certificate exchange could be trusted based on the hierarchical model, where the cert is validated based on signature. In either case, the clients certificate is exchanged in encoded format to the server based on the servers public material. – atyoung Nov 23 '14 at 20:45
  • I stress there is a large difference between minimum spec and what is actually done. Even in the cases where they haven't provided the certificate with their bundle, if they are using a proper CA, the signature wouldn't validate on the bogus cert in a MiTM attack, and the client would cease communication, so we would be back to having the servers key material. The client validates server cert before transmission of any useful data. – atyoung Nov 23 '14 at 20:57
  • Sorry I'm still a little confused. If the client only have it's own pair and the CA certificate how does it verify the certificate of the server? – user843521 Nov 23 '14 at 21:12
  • Ah! I believe the penny has dropped, the servers public key is signed using the CA private key. The public key is validated using the CA certificate. – user843521 Nov 23 '14 at 21:17
  • Yep you have it. – atyoung Nov 23 '14 at 21:18
  • So when the certificate arrives signed with the client, and the CA certificate is used to validate it - what is the result compared against to prove its validation? – user843521 Nov 23 '14 at 21:36
  • That really falls under general http://en.wikipedia.org/wiki/Certificate_authority We're delving very off topic and into the realm of how PKI works. – atyoung Nov 23 '14 at 21:38
  • The one thing I can't get my head around is why not just encrypt the server's public key with the CA private key and then decrypt with the CA certificate to prove authenticity – user843521 Nov 23 '14 at 21:59
  • No reason to, the key is public on purpose. There is no need to encode it because the only machine that can read whats encoded to the public key is the server with it's private key. This is not to mention the only keys that can decrypt are private keys, which the client does not have in the case of a CA. I suggest you read up on PKI. – atyoung Nov 23 '14 at 22:32