IOS and IOS-XE AnyConnect, TLS 1.0 and PCI DSS Compliance

[ghostinthenet]

I'm wondering if anyone has found a workaround for this problem.

In order to be PCI DSS compliant, TLS 1.0 must be completely disabled on Internet-facing devices by June of this year. This is actually a bit of a misstatement because PCI scanning services such as Security Metrics are marking the presence of TLS 1.0 as a compliance failure right now.

At present, Cisco IOS and IOS XE do not have a mechanism for disabling TLS1.0 and so AnyConnect installations are failing scans. An exception request can be submitted every six months to waive the requirement, but this will no longer be an option in June.

Cisco has indicated that there is presently no way to make IOS and IOS XE compliant, but that there is an enhancement request (CSCuv24653) in the bug database to allow this. There hasn't been a lot of activity on this enhancement request, so I'm looking for other options in the event that a fix doesn't materialize.

With IOS 15.5(3)M, TLS 1.1 and 1.2 are supported for AnyConnect with the 4.x client, so abandoning TLS 1.0 is doable, but the gateway will still negotiate down to 1.0 and trigger a failure when scanned.

I thought I might be able to use something like FPM to drop TLS 1.0 packets, but FPM has been removed from IOS and I can't find a similar function.

Has anyone else been faced with this?

[Philip D'Ath]

My first choice would be to get an ASA to use for your user to site AnyConnect connections.  It has the "ssl cipher" command, which lets you disable tlsv1.

For example I have configured:

ssl cipher tlsv1.1 fips
ssl cipher tlsv1.2 fips
ssl cipher dtlsv1 fips

I also specify the "fips" option, as that disables all weak crypto.

[ghostinthenet]

The ASA is great for access VPN connectivity, but far too limited in functionality for infrastructure VPN use, so it would have to be added alongside the existing router. This creates more trouble as the customer would have to get a new IPv4 block from the ISP and reconfiguring all of the DMVPN spokes for the new address. I suppose I could forward 80/tcp, 443/tcp and 443/udp from the public interface to a DMZ with the ASA, but I've never tried putting an AnyConnect headend behind NAT and am not sure how well it would work.

Also, adding new hardware just to address a missing control (that really should be there already) seems to be a bit overkill.

[Philip D'Ath]

I do agree with you Jody.  The routers are far more powerful when it comes to VPNs - except for support for AnyConnect and user to site VPNs.

It will work behind NAT, and the NAT you mention is sufficient.

[Philip D'Ath]

I'll also give you a completely different way of solving it - go to IKEv2.  I did this recently because I had a client want a full Suite-B compliant solution, and you can't do it with TLS on a router because it doesn't support the strong crypto.  IKEv2 does on an IOS router.

I created this article describing the process using full certificate authentication.  It doesn't get much better than this crypto wise.

http://www.ifm.net.nz/cookbooks/Cisco-IOS-router-IKEv2-AnyConnect-Suite-B-Crypto.html

[ghostinthenet]

This has promise!

I hadn't thought of this angle. Thank you for pointing it out.

How do you find the IKEv2-based AnyConnect works when behind things like hotel hotspots? Also, what mechanism is available for auto-deployment? Doesn't it still have to use a web interface for that?

[Philip D'Ath]

Referring only to when using it with an IOS router; I nearly exclusively use IKEv2 for all VPNs now.  I find it rock solid reliable.

There is zero support for auto-deployment.  The support is poor, nay terrible, in this area.  It only uses the normal IPSec ports, so there is no http/https for serving anything up.  You have to manually create an XML file (which is not too bad, you only do it once), and then it has to be copied into the directory:

%ProgramData%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\

There is no provision for importing profiles for users (like with the old IPSec client).

Actually to be fair, there is the MSI version of AnyConnect, and I know it supports windows installer transforms.  I just checked the pre-deployment page:

http://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect40/administration/guide/b_AnyConnect_Administrator_Guide_4-0/deploy-anyconnect.html

And it says a profile can be bundled with the installer.  So I suspect I could create a self-extracting zip file that extracts out the files and the anyconnect installer and runs it automatically.  I must have a play with that.

So perhaps my comments about how difficult deployment is results from my own ignorance.

Your second question - hotel hot spots.  I have no idea.  It works great through NAT.  So the Hotel would only need to allow the normal NAT-T ports (udp/500 and udp/4500).

Pretty much all my users rely on 3G/4G now.

[ghostinthenet]

I just received an update for enhancement request CSCuv24653, but it looks like the fix has only been implemented in the Denali code for IOS-XE. Does anyone know if this is going to be retrofitted to mainline IOS?

[ghostinthenet]

Further update received. It's been added to the IOS 15.6 code, so we're good to go.

[Evgeni Yampolski]

Hi Jody Lemoine,

running asr1001x-universalk9.03.17.02.S.156-1.S2-std.SPA.bin

would you please advise what is the cli to disable sslv3?

cant find it anywhere.... :(

Thank you

[ghostinthenet]

According to the details in the feature request, you need to be at 15.5(3)M3.1, 15.6(3.0d)M or 16.4(0.131). Looks like 15.6(1)S2 isn't going to have it.

[Evgeni Yampolski]

Sounds like this is not yet available for asr1001x platform.

[no] ip http secure-version [tlsv1.0] [tlsv1.1] [tlsv1.2]

[Akshayata]

The CLI which would help you to alter the TLS version on IOS would be:

router(config)#ip http tls-version ?
TLSv1.0 Set TLSv1.0 version Only
TLSv1.1 Set TLSv1.1 version Only
TLSv1.2 Set TLSv1.2 version Only

This CLI was introduced to the fixed versions as a resolution to the enhancement request CSCuv24653.

[ghostinthenet]

Interestingly, after upgrading to 15.6(3)M2 and adding the "ip http tls-version TLSv1.2" command to the configuration, nothing has changed. The VPN portal page still supports TLSv1.0 as if nothing had changed at all. I'm beginning to think the VPN portal doesn't obey the "ip http" commands and needs its own nerd knob to be implemented. After waiting a year, I'm hoping that this isn't the case... but it's possible.

[vishasi2]

For TLSv1.2 support with VPN: CSCux73159

Unfortunately, this isn't fixed.