Wireless Access

Reply
Occasional Contributor I

SSH Ciphers

Is there a way to change which SSH ciphers and/or Algorithms are enabled in AOS? A recent vulnerability scan shows CBC mode ciphers and insecure HMAC algorithms are enabled.

 

We are using AOS 6.3.0.1-FIPS

Frequent Contributor I

Re: SSH Ciphers

Is there a way to "disable" the cipher/algo without turning SSH?

"If there's a will, there's a way."
New Contributor

Re: SSH Ciphers

I have the same issue.  I can no longer use cbc flavored ciphers, which is apparently all that the Aruba 650 will support.  I just updated to the 6.4.3.3 build, and it still throws an error.

 

I am trying to scp a file from my server to the Aruba. 

 

The error reads:

no matching cipher found: client aes128-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

 

What this implies to me, is that teh client (Aruba, in this case) has the ciphers: aes128-cbc and aes256-cbc -- My server is presenting the remainder of the error list.

 

So far I have had no luck fixing this, but tech support said they should support ctr flavored ciphers.  The error, from what I am reading, implies that the controller does not support these ciphers.  Any help would be much appreciated.

Moderator

Re: SSH Ciphers

I'm afraid SSH ciphers are not configurable - they are hardcoded at build time.

 

Because the US Government (and other national governments) is typically our strictest customer from a security standpoint, we've chosen to make our SSH ciphersuites comply with their requirements.  We comply with the Network Device Protection Profile (https://www.niap-ccevs.org/pp/pp.cfm?id=CPP_ND_V1.0) which states:

 

FCS_SSHC_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 algorithms].

As you can see, there's no flexibility here to support CBC and ALSO support CTR - we're limited to only this list.  In the future, we are likely to add support for the GCM-based ciphers here, but we would then still be required to leave CBC enabled.


Frankly, the risk of exposure from https://www.kb.cert.org/vuls/id/958563 is so exceedingly small that I don't think anyone should be worrying about it.

---
Jon Green, ACMX, CISSP
Security Guy
New Contributor

Re: SSH Ciphers

Discovering this problem (yet again).

 

Todays issue is that openssh 7 doesn't include these ciphers, so its impossible to use any system that has an up to date openssh package installed.

 

Any news on the way forwards?

Moderator

Re: SSH Ciphers

It's working OK for me - any details on who built that version of OpenSSH?  This is from Ubuntu 16.04:

 

OpenSSH_7.2p2 Ubuntu-4, OpenSSL 1.0.2g-fips 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to arubaos.atl.arubanetworks.com [63.80.98.178] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8
debug1: match: OpenSSH_5.8 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to arubaos.atl.arubanetworks.com:22 as 'bugz'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group14-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: ssh-rsa SHA256:Zdl4mNSwfLXzcYJQCxAt859gmtLVPr5+chiYX9NBCXA
debug1: Host 'arubaos.atl.arubanetworks.com' is known and matches the RSA host key.
debug1: Found key in /home/jon/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: password,keyboard-interactive

 

 

 

---
Jon Green, ACMX, CISSP
Security Guy
New Contributor

Re: SSH Ciphers

That's interesting... .I tried Fedora 24 which has:

 

# rpm -qa | grep openssh
openssh-server-7.2p2-6.fc24.x86_64
openssh-clients-7.2p2-6.fc24.x86_64
openssh-7.2p2-6.fc24.x86_64

 

I'll try it against some RedHat systems later on - but they should work out of the box because they still have openssh 6.x. I wonder what specifics ubuntu use to build openssh - as most were dropped upstream by openssh.

Occasional Contributor I

Re: SSH Ciphers

John does this still apply.  I know this is an old post but we are running 6.5.1.9 AOS and 8.2.4 Airwave. We recent had Nessus scan done and both the controller and Airwave findings are "

SSH Weak MAC Algorithms Enabled and SSH Server CBC Mode Ciphers Enabled "the receomedned solutions are "

Contact the vendor or consult product documentation to disable MD5 and 96-bit MAC algorithms

Contact the vendor or consult product documentation to disable CBC mode cipher encryption, and enable CTR or GCM cipher mode encryption.

 

I know thess are low risk but we are in the process of getting an ATO and we have to provide POAM for these.

Thanks

Thomas

 

Moderator

Re: SSH Ciphers

My opinion of Nessus being 100% wrong about this has not changed.  However, arguing this point has worn us down.  In an upcoming ArubaOS release, we're going to provide a knob to shut off AES-CBC and HMAC-SHA1-96.  I've been told AOS 6.5.3.4 and 6.5.4.4, coming in December.  The feature will not be backported to 6.5.1.x.

 

You mentioned ATO, so I'll assume you are doing a DoD deployment.  Until recently, AES-CTR was not approved by NIAP, so deploying it would have put you out of compliance with CNSS policy 11.  That changed a few months ago when NIAP adopted NDcPP 2.0, so this is the first time we're able to offer it and still maintain compliance with DoD policy.

---
Jon Green, ACMX, CISSP
Security Guy
Occasional Contributor I

Re: SSH Ciphers

Thanks John , this is a DOJ deployment.


Thomas

IMPORTANT NOTICE: This message may contain privileged and confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: