Wireless Access



Every month or so, someone contacts the Aruba Security Incident Response Team because their vulnerability scanner of choice reports that use of AES-CBC within SSH is a vulnerability.  The vulnerability scanner vendors have been notoriously bad at understanding cryptography (example: interpreting HMAC-SHA1-96 as a 96-bit hash and flagging this as weak), so this is not surprising.  I'm going to write this post so that in the future, I can refer people back to it when they ask the question.


The original vulnerability was described in http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf, published in 2008.  A CERT database entry exists at http://www.kb.cert.org/vuls/id/958563.

Without forcing you to read the entire paper, the root of the problem was that an attacker could inject SSH packets into a session, and SSH would indicate whether or not the attacker had guessed a valid message length field.  An attacker could guess this with probability of 1 in 2^14 (that is a very small number) and if he guessed wrong, the SSH session would terminate.  So this by itself is already not a high risk for interactive SSH sessions - a user will notice if his SSH session resets over and over.  But for automated sessions that reconnect automatically and have no mitigations in place to detect error conditions, it could be a legitimate concern.  What's the problem with CBC?  Each block of ciphertext gets used as part of the crypto operation for the next block.  If an attacker can recover one block, that potentially lets him recover one additional block.  So already in my mind, I'm thinking "Low probability of success, high probability of being noticed, and even if it does succeed, only 32 bits of plaintext are leaked.  What's the big deal?"


Well, of course, any crypto leakage can potentially be a big deal.  Fortunately, the OpenSSH team made two changes in OpenSSH 5.2:

- They no longer return different error messages upon a failure to find a valid message length field.  That makes the attack much less effective.

- In the following release, they cause OpenSSH to continue reading up to the maximum message length even when an error has already been detected.  This removes the clue that an attacker would need in order to find a successful attack (an attacker might get a valid message length, but is going to fail on the MAC).  From the OpenSSH 5.2 release notes:

* This release also adds countermeasures to mitigate CPNI-957037-style
   attacks against the SSH protocol's use of CBC-mode ciphers. Upon
   detection of an invalid packet length or Message Authentication
   Code, ssh/sshd will continue reading up to the maximum supported
   packet length rather than immediately terminating the connection.
   This eliminates most of the known differences in behaviour that
   leaked information about the plaintext of injected data which formed
   the basis of this attack. We believe that these attacks are rendered
   infeasible by these changes.

In other words - in a post-OpenSSH 5.2 world, we do not need to worry about this attack.


As further evidence, the Common Criteria "Network Device Collaborative Protection Profile" (https://www.niap-ccevs.org/pp/cpp_nd_v1.0.pdf), which was written by an international technical community and adopted by the central governments of a wide variety of nations, requires AES-CBC to be supported.  Excerpting from the document:


FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses 
the following encryption algorithms and rejects all other encryption algorithms:
aes128-cbc, aes256-cbc, [selection: AEAD_AES_128_GCM, AEAD_AES_256_GCM, no other

Common Criteria evaluated products are used to protect national security information.  My interpretation:  If use of CBC mode ciphers in SSH were still a problem, these people would have mandated that it not be used, rather than what we see above.


Conclusion:  We at Aruba believe that the vulnerability scanner vendors are wrong on this, and have no plans to change our products to remove CBC support.


Questions?  Please reply and let me know.



Jon Green, ACMX, CISSP
Security Guy
Regular Contributor I



Does this apply to Airwave SSH as well?



It looks to me like AirWave's SSH is not locked down quite as restrictively
- it appears to use the OpenSSH default configuration. As AirWave begins to
incorporate a FIPS 140-2 validated crypto library, however, I think this
will change.

[LOCAL] : Available Remote Kex Methods =

[LOCAL] : Available Remote Send Ciphers =

[LOCAL] : Available Remote Send Macs =

Obviously you can control which ciphers you want to use from the client side
too. Or, AirWave lets you login to a root shell and you can adjust the
server side as well by editing /etc/ssh/sshd_config if you don't like what
you see.

Jon Green, ACMX, CISSP
Security Guy
New Contributor


Hi Jon, thanks for the hardening guide and this thread, very helpful.  My customer is asking me if there is a way to restrict acces to ssh on the controllers and clearpass to 256 only?  I could tell them they need to set their clients to 256 but it would be great if there was a way to restrict it on the host side to only 256.  If not that is ok too I just need a hard yes/no on that particular functionality.




Jon Prouty



To be clear, the question about running 256 is more around "how do we know we verify we are running AES 256 or 128 even though the software being used by Security is reporting 96 bit?".


This is more around wanting to provide the security team with details they can sink their teeth into instead of simply saying "Hey security, your tool is broken & reporting wrong information. We're already compliant. Have a nice day", and potentially starting WWIII.


Hope that makes sense.

Cheers and thanks,





The specific ciphers in use are hardcoded on those two products and can't be edited by an administrator.


It's pretty easy to show them what's actually supported by an SSH server - just put a client into debug mode when you connect.  SecureCRT for example has a "trace options" setting.  OpenSSH will let you specify the -vv option, so "ssh -vv some.hostname" will give you a dump that shows what the server offered, like this:

debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com



Be careful that you look at the second set of "kexinit" output - the first set is what the client supports.

Jon Green, ACMX, CISSP
Security Guy


And by the way, regarding AES256....  you need to look at security as the sum of all the parts.  Using AES256 when you're using a password for authentication is supreme overkill.  An attacker will go after your password - they aren't going to break AES256.  One is some amount of work, especially if you have a good password.  The second is exponentially more difficult.  Need to assign risk where it belongs. :)


Jon Green, ACMX, CISSP
Security Guy
Search Airheads
Showing results for 
Search instead for 
Did you mean: