13

I am trying to make my outgoing and incoming traffic look as legitimate as close to SSL traffic as possible. Is there a way to DPI my own traffic to ensure it looks like SSL traffic and not OpenVPN traffic? And based on my config setup does all traffic use port 443 which is the SSL port?

My configuration is as follows:

STUNNEL on laptop:

[openvpn]
# Set sTunnel to be in client mode (defaults to server)
client = yes  
# Port to locally connect to
accept = 127.0.0.1:1194  
# Remote server for sTunnel to connect to
connect = REMOTE_SERVER_IP:443

OPENVPN CONFIG ON laptop:

client
dev tun
proto tcp
remote 127.0.0.1 1194
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun

STUNNEL CONFIG ON SERVER:

sslVersion = all
options = NO_SSLv2
;chroot = /var/lib/stunnel4/
; PID is created inside the chroot jail
pid = /stunnel4.pid
; Debugging stuff (may useful for troubleshooting)
 debug = 7
 output = /var/log/stunnel4/stunnel4.log
setuid = root
setgid = root
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
compression = zlib
[openvpn]
accept = REMOTE_SERVER_IP:443
connect = REMOTE_SERVER_IP:11440
cert=/etc/stunnel/server.pem
key=/etc/stunnel/server.key

OPENVPN CONFIG on server:

local REMOTE_SERVER_IP
port 11440
proto tcp
  • Trying to learn new aspects with VPNs and understanding network protocols along with analysis ect... – Jason Mar 15 '15 at 3:18
  • 2
    You can answer the 2nd question with wireshark running on your laptop and probably learn a lot more on the way – Alec Istomin Mar 15 '15 at 5:59
  • Not that you should probablye disable TLS compression (because of CRIME) and restrict the number of TLS protocols and cryptosuites avaiable in order to avoid simple attacks on your TLS tunnel (server side and client side) if your really want to use this in the real world. – ysdx Apr 9 '15 at 9:14
  • you can user other ports for SSL/TLS. i even do it over SCTP and IPv6. – Skaperen Apr 9 '15 at 9:44
22

OpenVPN over TLS

Your VPN is using TCP as a transport protocol. The stunnel instance is used to encapsulate the content of the TCP stream in TLS/TCP. You get this protocol stack:

[IP     ]<------------------------>[IP     ]
[OpenVPN]<------------------------>[OpenVPN]
            [TLS   ]<~~~~~>[TLS]
[TCP    ]<->[TCP   ]<----->[TCP]<->[TCP    ]
[IP     ]<->[IP    ]<----->[IP ]<->[IP     ]
[       ]   [      ]       [   ]   [       ]
 Server      stunnel      stunnel  Client

Between the stunnel instances you have this protocol stack on the wire:

[IP      ]
[OpenVPN ]
[TLS     ]
[TCP(443)]
[IP      ]
[...     ]

As the TLS encrypts its payload, an attacker can only see:

[???     ]
[TLS     ]
[TCP(443)]
[IP      ]
[...     ]

So yes, it is plain TLS traffic (it could be HTTP/TLS, SMTP/TLS, POP/TLS or anything else for someone looking at the traffic but it looks a lot like HTTP/TLS as the TCP port 443 is used). You can check this by using wireshark: record the traffic between the stunnel instances. In the wireshark UI (right button on a packet of the stream), you can ask wireshark to interpret the traffic as TLS: it will recognise it as TLS traffic (you will see the different TLS messages but not the payload of the TLS session).

You might want to use SNI in the client in order to look like what a modern browser would do. You might want to use ALPN as well but stunnel currently does not handle that.

OpenVPN with builtin TLS

In comparison, if you are using OpenVPN, you will have something like this:

[IP      ]
[OpenVPN ]
[TCP     ]
[IP      ]
[...     ]

Which looks like this:

[???     ]
[OpenVPN ]
[TCP     ]
[IP      ]
[...     ]

The builtin TLS layer does not encapsulate the (IP, Ethernet) packets but is only used for setting up the session and authenticating:

[TLS     ]
[OpenVPN ]
[TCP     ]
[IP      ]
[...     ]

In this case, your traffic does not look like a plain TLS traffic but is obviously OpenVPN. If you interpret this traffic as OpenVPN in wireshark, you will recognise the OpenVPN messages and inside of them the TLS messages (but not the payload).

Warning

You should be aware that if a passive attacker will not be able to tell that your remote server is in fact an OpenVPN server, an active attacker will be able to find this out: simply by connecting to your server over TLS, he will be able to confirm that it is not a HTTP/TLS server. By trying to speak the OpenVPN protocol, he will be able to detect that your server is a OpenVPN/TLS server.

OpenVPN over TLS with client authentication

It you are worried about this you could enable TLS client authentication: an attacker will not be able to initiate a working TLS session and will not be able to guess which payload is encapsulated over TLS.

*Warning:** I'm not talking about the builtin TLS support in OpenVPN (see above for en explanation about why it won't help you).

Multiplexed OpenVPN/TLS and HTTP/TLS

Another solution is to serve both HTTP and OpenVPN over the TLS session. sslh can be used to automatically detect the payload of the protocol and dispatch either to a plain HTTP/TCP server or you OpenVPN/TCP server. The server will look like standard HTTP/TLS server but someone trying to speak OpenVPN/TLS with this server will be able to detect that it is in fact a OpenVPN/TLS server as well.

        either OpenVPN/TCP
          or HTTP/TCP       
[1].---------.     .------.HTTP/TCP.-------------.
-->| stunnel |---->| sslh |------->| HTTP server |
   '---------'     '------'|       '-------------'
                           |       .----------------.
                           '------>| OpenVPN server |
                        OpenVPN/TCP'----------------'

[1]= Either OpenVPN/TLS/TCP or HTTP/TLS/TCP

OpenVPN over HTTP CONNECT over TLS

Another solution is to use a standard HTTP/TLS server and use HTTP CONNECT/TLS to connect to the OpenVPN server: it will look like a standard HTTP server. You can even require authentication of client in order to authorise the HTTP CONNECT request (squid should be able to do this).

OpenVPN has an option to use a HTTP Proxy:

http-proxy proxy.example.com

You should be able to combine this with a stunnel instance connecting to a remote HTTPS PROXY:

http-proxy 127.0.0.1 8443
remote vpn.example.com

Which would implement this protocol stack:

[IP     ]<------------------------>[IP     ]
[OpenVPN]<------------------------>[OpenVPN]
            [HTTP  ]<------------->[HTTP   ]
            [TLS   ]<~~~~~>[TLS]
[TCP    ]<->[TCP   ]<----->[TCP]<->[TCP    ]
[IP     ]<->[IP    ]<----->[IP ]<->[IP     ]
[       ]   [      ]       [   ]   [       ]
 Server    HTTPS PROXY     stunnel   Client
  • Can you please elaborate on the HTTP CONNECT approach? Where can I find a guide to setting this up? – kontextify Apr 23 '18 at 21:38
  • kobtextify: added some details about a possible implementation of OpenVPN/HTTP_CONNECT/TLS. – ysdx Apr 24 '18 at 15:00
  • Thanks! How would the web server or Squid part look? – kontextify Apr 25 '18 at 10:58
  • I guess somthing like «acl VPN_SERVER dstdomain vpn.example.com » « acl VPN_PORT ports 1194 » « acl CONNECT method CONNECT» « http_access allow VPN_SERVER VPN_PORT CONNECT » « http_access deny all ». – ysdx Apr 25 '18 at 11:26
4

ysdx's answer is great, and describes very well how the traffic will look on the wire.

Left unmentioned, however, is that traffic analysis can go a long way toward identifying applications.

Let's assume that your OpenVPN connection looks just like an https connection on the wire, so an attacker cannot read the byte stream and know what kind of connection it is.

A typical https connection won't live too awfully long. Maybe your browser keeps a connection open to your mail server, I don't know. In general though, there will be lots of relatively short connections to a lot of diverse remote servers.

OTOH, the OpenVPN connection might live for hours or days, and will send a lot of data back and forth to the openvpn server.

You could mitigate the long-lived connection by periodically dropping and restarting the connection. This presumably has implications for your application traffic, but might be workable. The pattern of lots and lots of traffic going between you and the openvpn server, however, is going to be a lot harder to camouflage.

  • 2
    Yes. What's more, I guess it might be possible to look at the shape of the traffic (such as its "burstiness") and compare it to a standard HTTP/TLS, IMAP/TLS, POP/TLS, OpenVPN/TLS. You might try to classify a given TLS traffic with those profiles of traffic and have an idea of the type of traffic encapsulated in your TLS connection. – ysdx Apr 9 '15 at 19:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.