The new attack against websites using SSL encryption presented at Black Hat this week shows some interesting possibilities. To recap, this is the most important part of what SSLstrip does:


SSLstrip manages to fool the user into believing he has an encrypted connection with the intended website through several clever slights on hand. First, the tool uses a proxy on the local area network that contains a valid SSL certificate, causing the browser to display an “https” in the address bar.

Second, it uses homographic techniques to create a long URL that includes a series of fake slash marks in the address. 

While the second part is very clever, it’s not a completely new issue. However, reading this made me think of some interesting ways to use a similar technique to attack SSL VPN’s.


The basics

While SSL VPN’s are easy to configure and use, there are some security downsides as well. Since no VPN software is pre-installed on the client computer, access is initiated via a webbrowser. That means tools like SSLstrip can potentially be used against them. This is how Sonicwall describes their SSL VPN solution:

In its purest form, SSL VPN remote access is strictly browser based. This is true, for example, for proxied Web applications. In other cases, a “virtual” client is automatically pushed through the Web browser in the form of tiny Java applets or ActiveX controls 

This is where it gets interesting, and where ease-of-use defeats some basic security precautions. From their FAQ

Can I access the SSL-VPN appliance using HTTP?
No, it requires HTTPS. HTTP connections are immediately redirected to HTTPS. You may wish to open both ports 80 and 443, as many people forget to type “https://” and instead type “http://”. If you block port 80, they will not be redirected.

Simple attack: insecure configuration

Most of these and similar appliances from other vendors come with a self-signed certificate by default. So users are taught to:

  • Connect using an insecure protocol (http instead of https)
  • Accept a non-trusted certificate, ignoring the warnings given by their browser


This means that you don’t need any special tricks to execute a man-in-the-middle attack against anyone using these solutions; with a bit of luck the user will connect over http instead of https, and even if an SSL connection is tried you can present them with a self-signed certificate. Using two-factor authentication won’t help you; the authentication will simply be passed to the VPN appliance. 

Advanced attacks: don’t trust anyone else’s computer!

The ease of use that SSL VPN’s offer is great; but it’s also a danger. Since you don’t need any additional software, it’s very tempting to use any PC available to log on to the corporate network. But even if your company uses a real, signed, trusted SSL certificate, blocks http access and tells you not to continue when receiving certificate warnings. you might not be safe. 

If an attacker is able to insert a rogue certificate authority into the web browser that is used, it’s trivial to use a proxy to execute the perfect man-in-the middle attack: 


  • Intercept connections from the client, encrypting it with a certificate signed by the rogue CA. 
  • The users browser will trust this and won’t issue a warning, and the attacker can now decrypt all traffic
  • The attacker re-encrypts the traffic and forwards it to the VPN appliance


It might sound far-fetched, but there are several large vendors that offer this exact technique as a feature in their firewall products! And the attacker might have more resources than you think; would you trust a PC in an internet cafe in China? Who knows how many extra Certificate Authorities are trusted by the browser you would be using! 


Never trust an application using SSL blindly; whether it’s a VPN or any other application that requires a high level of security. Especially not when using a computer that’s not yours. 

If you do need to use webbased applications in a secure manner, make sure to check the certificate; don’t just trust your browser to check it for you, but actually look at the certificate and which CA signed it. For extra safety, use the Perspectives plugin. This will detect most man-in-the-middle attacks that use forged certificates.