The user portal is such a convenient way to setup vpn's for client access, but I assume with convenience a security trade off may occur.
This thread was automatically locked due to age.
The user portal is such a convenient way to setup vpn's for client access, but I assume with convenience a security trade off may occur.
To elaborate on the technology aspects of your question:
HTML5 VPN and SSL VPN rely on the same technology, which was developed for web-based encryption: SSL/TLS. SSL was the original implementation developed by Netscape. They turned the concept over to the IETF Standards group, which revised the specification and called it TLS. The sequence of releases, from new to old, is SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3.
When a client and server connect, they negotiate the best available configuration, based on what they are able and willing to use. At this time, nobody should be using anything older than TLS 1.0, but there is a tremendous push to get everyone using TLS 1.2 or the very new TLS 1.3
IPSEC VPN uses a different technology framework than TLS. I don't know how to compare the two, so I will defer to Bob Alfson's assessment that IPSEC has some theorietical advantages.
Both TLS and IPSEC involves multiple interchangeable components. The protocol, such as TLS, controls how to say "Hello". An asynchronous encryption method is used to bootstrap a connection. But asynchronous encryption is high overhead, so it is only used temporarily to negotiate a synchronous encryption method. An authentication method is also negotiated, because it least one end, possibly both, need to verify that they are talking to the intended communication partner. A checksum method is needed for both ends to know if a packet has been manipulated in transit. Finally a Perfect Forwarding Secrecy method is used to ensure that a bad guy cannot decrypt the whole conversation by cracking the contents of one packet. Each of these components are plugged together to make a communication session. In recent years, white-hat researchers and faster processors have found problems with many of the components, so an optimal encryption session depends on having support, at both ends of the connection, for the newest components.
Encryption is designed to keep the bad guys from eavesdropping on your traffic. This is a good thing, but I actually think the likelihood of this happening is pretty low.
An easier approach is for the bad guys to guess their way into your systems with password guessing attacks. That is why two-factor authentication becomes critical. If your users are at fixed locations, site-to-site VPN becomes a way of solving this problem, because the remote IP is the only location from which password-guessing attacks can be attempted. I have also used IP-based restrictions with WAF to provide equivalent protection to my internet-facing websites, without creating a site-to-site VPN. For users that are not at fixed locations, One-Time-Passwords (free) and DUO Security (free for 10 users, monthly fee otherwise) is another alternative. PCI DSS (credit card) regulations call for 2-factor security on all remote access. Even if you are exempt from PCI DSS, which is unlikely, two-factor authentication is a practical necessity. We operate a honeytrap which is catching password-guessing attacks on a nearly daily basis.
To elaborate on the technology aspects of your question:
HTML5 VPN and SSL VPN rely on the same technology, which was developed for web-based encryption: SSL/TLS. SSL was the original implementation developed by Netscape. They turned the concept over to the IETF Standards group, which revised the specification and called it TLS. The sequence of releases, from new to old, is SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3.
When a client and server connect, they negotiate the best available configuration, based on what they are able and willing to use. At this time, nobody should be using anything older than TLS 1.0, but there is a tremendous push to get everyone using TLS 1.2 or the very new TLS 1.3
IPSEC VPN uses a different technology framework than TLS. I don't know how to compare the two, so I will defer to Bob Alfson's assessment that IPSEC has some theorietical advantages.
Both TLS and IPSEC involves multiple interchangeable components. The protocol, such as TLS, controls how to say "Hello". An asynchronous encryption method is used to bootstrap a connection. But asynchronous encryption is high overhead, so it is only used temporarily to negotiate a synchronous encryption method. An authentication method is also negotiated, because it least one end, possibly both, need to verify that they are talking to the intended communication partner. A checksum method is needed for both ends to know if a packet has been manipulated in transit. Finally a Perfect Forwarding Secrecy method is used to ensure that a bad guy cannot decrypt the whole conversation by cracking the contents of one packet. Each of these components are plugged together to make a communication session. In recent years, white-hat researchers and faster processors have found problems with many of the components, so an optimal encryption session depends on having support, at both ends of the connection, for the newest components.
Encryption is designed to keep the bad guys from eavesdropping on your traffic. This is a good thing, but I actually think the likelihood of this happening is pretty low.
An easier approach is for the bad guys to guess their way into your systems with password guessing attacks. That is why two-factor authentication becomes critical. If your users are at fixed locations, site-to-site VPN becomes a way of solving this problem, because the remote IP is the only location from which password-guessing attacks can be attempted. I have also used IP-based restrictions with WAF to provide equivalent protection to my internet-facing websites, without creating a site-to-site VPN. For users that are not at fixed locations, One-Time-Passwords (free) and DUO Security (free for 10 users, monthly fee otherwise) is another alternative. PCI DSS (credit card) regulations call for 2-factor security on all remote access. Even if you are exempt from PCI DSS, which is unlikely, two-factor authentication is a practical necessity. We operate a honeytrap which is catching password-guessing attacks on a nearly daily basis.
