Virtual Private Networks constitute a hot topic in networking because they provide low cost and secure communications between sites (site-to-site VPNs) whilst improving productivity by extending corporate networks to remote users (remote access VPNs). Naturally the VPN technology is widely deployed on all internet edge devices and most ASAs.

Cisco is very proud of its VPN solutions. It’s one of the few vendors that support such a wide range of VPN technologies with so many features and flexibility. Cisco Routers and Cisco ASA Firewalls are the two types of devices that are used most often to build Cisco Virtual Private Networks.  Cisco has been very strict about the way its routers and firewalls should be used and what technologies are available to them – routers will do the full range of Site-To-Site of VPNs: Traditional (Policy-based) IPsec VPNs, but also GRE IPsec VPNs, DMVPNs, GET VPNs, and have limited capabilities for the remote access VPNs: IPsec and SSL based. However, the ASA is very different so far it could do just traditional policy based L2L IPsec VPN but will have the full functionality for remote based VPNs. The message was very clear, for large organization and ISP use Routers for remote access VPN and static traditional Site-to-Site use the ASAs.

Things changed, Cisco very recently introduced a new feature with its 9.7.x code in the VPN module of the ASA – the VTI (Virtual Tunnel Interface). VTI were long available in Cisco Routers but never in Cisco Firewalls but similar technologies (Route-Based VPNs) were available in most competitors and the demand for that features finally took effect on Cisco and they introduced it.

Now before understanding why VTI are so important we will do a quick comparison between the traditional Site-to-Site IPsec VPN (Policy Based VPNs) and the VTI (Route-Based VPNs)

Policy Based VPNs

They rely on static (policy based) configuration of the encryption domain (usually by ACLs) and do not pass multicasts, not great for dynamic routing and voice/video and other multicast applications and requires re-configuration on both sides if the networks that traverse the VPN should change. The configuration is quite complex involving many steps that need to be same or mirrored (encryption domains/ACL config) and that is prone to mistakes.

However, the benefits are that this is a well matured configuration process and the IPsec VPN is a IETF standard which means all vendors must implement it according to the specifications of the standard, hence in theory it should always work between in multivendor scenarios. This is important because the two main uses of L2L (Site-to-Site) VPNs is connecting same company sites over internet thus replacing more expensive intranets or connecting one company to another company/partner/provider of services over Internet in a secure manner. In that second case, there is a big chance that both companies will use different vendors for VPN devices.

Route-Based VPNs

A route-based VPN configuration uses Layer3 routed tunnel interfaces (either GRE based or VTI based) as the endpoints of the VPN. Instead of selecting a static subset of traffic to pass through the VPN tunnel using an Access List, all traffic passing through the special Layer3 tunnel interface is placed into the VPN. Therefore, you need to configure routing accordingly. Either a dynamic routing protocol (such as EIGRP or OSPF) or static routing must be configured to divert VPN traffic through the special Layer3 tunnel interface. That makes the selection of interesting traffic dynamic and you have the flexibility to perform changes and introduce new traffic to the VPN without redoing the VPN configuration (only by changing the routing so new traffic gets routed to the interface). Another benefit is that this type of VPN can pass multicast traffic thus allowing dynamic routing protocols and enabling multicast applications to work.

There are some limitation and considerations that need to be taken in mind. First VTI is a proprietary to Cisco technology, despite other vendors having similar route-based VPN technology, there is no guarantee these will work between each other. Also, the tunnel interface itself does not provide inherited security, IPsec protection is an add-on and needs to be configured on top for encryption/security of traffic.

Summary and conclusions:

Introducing VTIs in ASAs is a big step forward in making the firewall an even more versatile network edge device. The VTI capability to provide security and encryption on multicast traffic and its flexibility for tunneling the traffic via dynamic routing with zero reconfiguration on the VPN, means that any small or middle-sized organization with ASA on network edge can now benefit very strongly from that functionality and would not need to purchase additional hardware thus maximizing its return on investment value.

References:

Release notes:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa97/release/notes/asarn97.html#ID-2172-00000128

Configuration:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa97/configuration/vpn/asa-97-vpn-config/vpn-vti.html

The breakthrough

SHA-1 is dead, from a security point of view, but has been a long time coming. A combined research collaboration between CWI and Google, published a paper on 23th of February 2017 that proved deliberate collisions can be created for SHA-1 (Secure Hash Algorithm -1). The researchers managed to forge a PDF doc so I have the same SHA-1 value as completely different document (aka collision).

OK, why is that such a big deal?

Background information and the risk

Hash functions are widely used in the cryptography and hence in the VPN world. They are used to verify the presence of a piece of information on the other peer (for example a pre-shared-key) that matches perfectly with yours (that is authentication) and to confirm that data has not been tampered with during transit (integrity), hash functions are used in the Public Key Infrastructure to verify integrity and sign the certificates (aka to verify that certain a person with a certain name has a certain public key).

The ability for someone to create a forged data string so that it matches the computed hash of another data string nullifies the security and the idea of using hash functions in cryptography.

Widespread

SHA-1 is still widely used for integrity/signing in IPsec IKEv1 (and sometimes IKEv2) and some PKI still support it so there are a multitude of certificates using it.

Furthermore, why is that important for Cisco VPN users?

IPsec IKEv1 does not support newer SHA algorithms (SHA-2) and the predominance of IPsec VPN is still built on IKEv1.

Even if you are using IKEv2 there could also be hardware restrictions preventing you from using modern hash functions (SHA-2) – legacy Cisco ASA devices (5505, 5510, 5520, 5540, 5550) cannot support newer hash functions in hardware and Cisco has not implemented the functionality into their software.

Recommendations

If your company is using a VPN and you need to audit them then ensure they are not using SHA-1 anymore. For expert VPN Security advice, contact 4CornerNetworks today.

Sources of Information:

https://shattered.io/static/shattered.pdf

https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/

http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/vpn/asa_91_vpn_config/vpn_ike.html#pgfId-1042794

© 4CornerNetworks - Website by Roslin Design
4CornerNetworks is the trading name of 4CornerNetworks Ltd
Registered Address: 27 The Mount, Rickmansworth, Hertfordshire WD3 4DW
Company Registration Number: 07920761
Registered in England
chevron-down