Cisco ASA TLS handshake error

If you receive ASA with only DES/MD-5 encryption license then you might wish to upgrade your firewall to the stronger (3DES/AES) encryption license. Even after upgrade you can run on problems with connecting your Windows 7 Internet Explorer 8 or later to the ASA https interface (ASDM or WebVPN). Connections from ASDM Launcher application works fine, but direct connections from MS IE browser are failing. Debug of the connection will show you a couple of things:


- ASA sends TCP RST packet right after TCP handshake
- TLS debug shows (visible from ASA debug level logging) cipher negotiation errors and this is the root cause of our little problem.

Well, new IE browser doesn't want to connect to your ASA because ASA supports only des/md-5 and rc4/md-5 encryption while IE requires something a little bit better as a minimum for completing TLS handshake. Such poor encryption is the result of your ASA being shipped with weak encryption license by default. So, after encryption license upgrade issue:
show run all ssl

The command from above will discover what SSL/TLS cipher suits your ASA currently supports and if you don't see 3DES and AES encryption algorithms listed here type:
ssl encryption 3des-sha1 aes128-sha1 aes256-sha1

Now you should be able to connect with MS IE 8 or newer;)

Cisco IPS signature 5377/0 caveat

Today I received a support call about user's pc that cannot connect to the Internet suddenly, but able to talk with internal hosts. I've checked AIP-SSM log and found that this PC fired 5377/0 signature which triggers if "xp_cmdshell" (MS SQL Server stored procedure) word is found in HTTP request. It turned that this is one of our developer's PC and she fired this signature by simply searching Google for xp_cmdshell keyword:)


So, if you have SQL Server guys in your network create Event Action Rule Override to avoid breaking network communication for these people...


Regards,
Igor