Security

Hi,

 

We've noticed that the onboarding for linux (ubuntu) & MAC OS X devices doesn't go as planned. When those devices are captured in a restricted vlan, where they can only connect to the CP, they get a TLS error; TLS1.0 & TLS1.1 are no longer supported on their browser (firefox/chrome). If they enable TLS1.0 & TLS1.1 they see the SSL error in attach.
Now, just to be sure, CP onboarding sends the onboarding page in TLS1.2, as you can see in see second attach.

The weird thing is that users in this restricted vlan say that it doesn't matter which site they are trying to reach, they get this error. Before implementation of NAC, this was not the case, and it is on multiple sites/users...

To be complete I added a screenshot of the restricted vlan and another screenshot with the ACL on the switch.

What type of switch are using?



Thank you

Victor Fabian

Pardon typos sent from Mobile

We've had this on cisco WS-C2960S-48TS-L with IOS 12.2(55)SE10 & a cisco C9300-24T with  IOS 16.08.01a 

Did you enable HTTPS on the switch ?
You can use the following command :
ip http secure-server



Thank you

Victor Fabian

Pardon typos sent from Mobile

yes, we did.

To be complete; a shortened version of the switch' config in attach.

We narrowed the issue down a bit, but no solution yet.

We use a restricted vlan for the self-registration. In this vlan we use an acces list:

 

ip access-list extended Onboard_ACL
deny udp any any eq bootpc
deny udp any any eq bootps
remark ClearPass servers
deny tcp any host ipaddress primary
deny tcp any host ipaddress secondary
deny udp any any eq domain
permit ip any any

 

Afterwards the users go into this same vlanID, but without the ACL, where they do not have such an TLS error.

Now what we can see on the browser, whenever the ACL is in place, we get no cipher keys (attach1). Without the ACL we get -as expected- a whole bunch of cipher keys (attach2)
Now this clearly sends us in the right direction, but what can be the root cause of this?

It took some time to get the right persons/equipment on the right places in these times, but we've found the solution.

Thought it would be interesting for someone encountering the same issue.

 

The TLS errors combined with the cipher keys we saw earlier were indeed a good indication. We use some old equipment, C2960, C3560, etc, with the recommended IOS from CISCO, which is the12.2(55)SE12.

 

If you check the version and the used cipher keys, you'll get;

 

Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ----------
* 1 52 WS-C3560G-48PS 12.2(55)SE12 C3560-IPBASEK9-M

Configuration register is 0xF

switch#sh ip http client secure status
HTTP secure client ciphersuite: 3des-ede-cbc-sha des-cbc-sha rc4-128-md5 rc4-128-sha
HTTP secure client trustpoint:

 

Modern browsers won't use those cipher keys for some time now. If we upgrade to IOS 15.0(2) we see:

 

Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ----------
* 1 52 WS-C3560G-48PS 15.0(2)SE11 C3560-IPBASEK9-M

Configuration register is 0xF

switch#sh ip http client secure status
HTTP secure client ciphersuite: 3des-ede-cbc-sha des-cbc-sha rc4-128-md5
rc4-128-sha aes-128-cbc-sha aes-256-cbc-sha dhe-aes-128-cbc-sha
dhe-aes-256-cbc-sha

 

Which includes more recent cipher keys.

We can conclude that our switches intercepts the https session for onboarding, and since the cipher key was not supported on the switch, the complete session failed...