SSL can be used to create site-to-site and access VPNs, but it is mostly used in SSL (pseudo) VPNs to grant a secure access to services (such as web service, e-mail) through TCP/UDP-based tunneling. The main advantage for SSL (pseudo)VPNs is that they have a good chance of working on any network scenario, without any problems in traversing NATs, firewalls or routers, and SSL services can also be accessed by web browsers through HTTPS.
Comparison to alternative solutions
Comparison to IPsec
Advantages SSL is more convenient than IPsec in terms of:
• usage: IPsec has too many options to be configured and administered, while SSL just requires to compile the application along a library implementing SSL;
• security: it works at application layer ⇒ an attack to SSL just involves the application and not the whole operating system;
• maturity: it has been used for a lot of years over a lot of versions ⇒ few bugs in code;
• compatibility with NAT traversal:
– no authentication of IP header because SSL is on top of the transport layer;
– no encryption of ports as with IPsec ESP.
SSL is critical with DoS attacks: packets always need to be processed up to transport layer, while in IPsec they are dropped already at network layer.
Comparison to PPTP
SSL overcomes some PPTP issues:
- poor interoperability with non-Microsoft platforms;
- some network administrators may configure their routers to block GRE, on which PPTP is based, due to the fact that they do not like source routing feature.
SSL (pseudo)VPN flavors
Web proxying: The web server does not support HTTPS ⇒ a ‘VPN gateway’,2 at the edge of the corporate network, downloads web pages from the web server through HTTP, and ships them to the user, outside the corporate network, through HTTPS.
Port forwarding: The client runs an application supporting an application protocol (such as FTP, SMTP, POP3), hence a port forwarder installed on the client converts packets, sent to a specific port, from the application protocol into HTTPS packets sending them from another port, and vice versa.
Application translation: The web server is an application server (e.g. mail server) supporting an application protocol (such as FTP, SMTP, POP3), therefore the ‘VPN gateway’ converts HTTPS into the application protocol and vice versa through a port forwarding mechanism implemented inside the ‘VPN gateway’.
SSL’ed protocols: Some application protocols can natively integrate SSL into themselves (e.g. SMTP-over-SSL, POP-over-SSL) ⇒ client and web server can directly communicate in a secure way without the need for translation by a ‘VPN gateway’.
Application proxying: The client uses a SSL’ed protocol, but the web server does not support it ⇒ a ‘VPN gateway’ is still required with port forwarding mechanism.
Network extension: Both the client and the web server do not support SSL ⇒ two ‘VPN gateways’ are required, one at the user side and the other one at the web server side, so the SSL tunnel is created between the two ‘VPN gateways’.