Is it possible to determine the difference between a VPN on port 443 compared to standard SSL traffic?
In order to access SSL websites you need port 443 open but if you setup a VPN Service on port 443 you can dial out of the firewall.
Add a comment
|
3 Answers
Yes. Even if you run a VPN on port 443, HTTPS (which uses port 443) and VPNs have enough differences within the protocols that can be distinguished from the outside that a firewall or device that does deep packet inspection would be able to immediately classify both.
If your firewall does not block a VPN connection on port 443, it is likely that the firewall is only doing port filtering, or does not have protocol signatures for VPN connections yet.
-
You're assuming that the firewall is capable of deep packet inspection, and that the client is willing to trust its certificate.– BrunoSep 23, 2013 at 12:57
-
@Bruno: I covered the case where the firewall does not do DPI in the second paragraph of my answer. Also, "client is willing to trust its certificate"? Doesn't that apply to MITM, and not determining the protocol type?– NasrusOct 7, 2013 at 15:31
-
Sure, but to determine the protocol type (e.g HTTPS or VPN over SSL/TLS), you need to look within the SSL/TLS channel, hence you need a "MITM proxy/firewall", hence the client needs to accept this MITM by accepting its certificate.– BrunoOct 7, 2013 at 16:05
-
Most VPN protocols, such as IPSec and OpenVPN without tunneling through SSL, have differences in the protocols that can be determined from an onlooker doing proper DPI without needing to do an MITM. Even if tunneled through SSL, a router doing DPI with the appropriate rulesets can detect "unnatural" SSL connections, such as those that have the client provide a certificate to prove its identity, or unusually long connection times with massive traffic flows.– NasrusOct 8, 2013 at 0:13
-
IPSec is over UDP, so couldn't be confused with HTTPS anyway. I'm not sure whether OpenVPN with SSL/TLS starts with other packets first; if it doesn't it would look like plain SSL/TLS (just like HTTPS). Client-certs can legitimately happen with an HTTPS connection (although they wouldn't work with a MITM proxy anyway), and they can be "hidden" (in a renegotiated handshake). The only "reliable" way to detect non-HTTPS SSL/TLS traffic on TCP port 443 really is the long connection time...– BrunoOct 8, 2013 at 0:20
It is possible to differentiate between "VPN traffic" and "standard SSL traffic", for an appropriate notion of "standard", of course. I suppose that by "standard", you mean people using a Web browser to access HTTPS Web sites.
The point is that while SSL is quite good at hiding data contents, it leaks data length: from observing the SSL records, one can work out the length of the cleartext contents (possibly down to single byte accuracy). A Web browser will issue HTTP requests, whose length is usually of a few hundred bytes, resulting in a corresponding (and bigger) response; and there will be pauses. Generic IP traffic encapsulated in a SSL-based VPN should exhibit a distinct pattern (in particular, the TCP three-way handshakes should be quite conspicuous).
While such tests will never be 100% reliable, they can be quite effective. Unless the users are fully aware of the presence and operation of such a detection mechanism, and try to defeat it. This can turn into an long-winded, tiresome war of detection and stealth. If your users are really keen on setting up a VPN, then this might be for some quite legitimate reason; it may be worth rethinking about why you want to block VPN but still allow "standard HTTPS".
answered May 22, 2014 at 22:34
If you can configure your VPN to first connect via TCP port 443 and then secure the comms under SSL (actually use TLS) and only then utilize the VPN protocol... then finally you would prevent the firewall from being able to detect that it is VPN traffic instead of HTTP traffic.
Stated another way, plaintext VPN traffic over 443 will look like VPN traffic, matching whatever protocol in use. SSL VPN traffic over 443 will look like SSL traffic.
