Of the attached list of cipher suites which one or two are t

Of the attached list of cipher suites, which one or two are the most secure, and which one or two are the least secure? Why?

Cipher Suites (17 suites) Cipher Suite TLS ECDHE ECDSA WITH AES 128 GCM SHA256 (0xc02b) Cipher Suite: TLS ECDHE RSA WITH AES 128 GCM SHA256 (0xc02f) Cipher Suite TLS ECDHE ECDSA WITH AES 256 GCM SHA384 (0xc02c Cipher Suite: TLS ECDHE RSA WITH AES 256 GCM SHA384 (0xc030) Cipher Suite: Unknown (0xcca9) Cipher Suite: Unknown (0xcca8) Cipher Suite TLS ECDHE ECDSA WITH CHACHA20 POLY1305 SHA256 (0xcc14) Cipher Suite: TLS ECDHE RSA WITH CHACHA20 POLY1305 SHA256 (0xcc13) Cipher Suite TLS ECDHE ECDSA WITH AES 128 CBC SHA (0xc009) Cipher Suite TLS ECDHE RSA WITH AES 128 CBC SHA (0xc013) Cipher Suite: TLS ECDHE ECDSA WITH AES 256 CBC SHA (0xc00a) Cipher Suite TLS ECDHE RSA WITH AES 256 CBC SHA (0xc014) Cipher Suite: TLS RSA WITH AES 128 GCM SHA256 (0x009c) Cipher Suite TLS RSA WITH AES 256 GCM SHA384 (0x009d) Cipher Suite TLS RSA WITH AES 128 CBC SHA (0x002f) Cipher Suite: TLS RSA WITH AES 256 CBC SHA (0x0035) Cipher Suite TLS RSA WITH 3DES EDE CBC SHA (0x000a

Solution

It is now well-known that (some) SSH sessions can be decrypted (potentially in real time) by an adversary with sufficient resources. SSH best practice has changed in the years since the protocols were developed, and what was reasonably secure in the past is now entirely unsafe.

The first concern for an SSH administrator is to disable protocol 1 as it is thoroughly broken. Despite a stream of vendor updates, older Linux releases maintain this flawed configuration, requiring the system manager to remove it by hand. Do so by ensuring \"Protocol 2\" appears in your sshd_config, and all reference to \"Protocol 2,1\" is deleted. Encouragement also is offered to remove it from client SSH applications as well, in case a server is inaccessible or otherwise overlooked.

For further hardening of Protocol 2 ciphers, I turn to the Stribika SSH Guide. These specifications are for the very latest versions of SSH and directly apply only to Oracle Linux 7.1.

For older versions of SSH, I turn to the Stribika Legacy SSH Guide, which contains relevant configuration details for Oracle Linux 5, 6 and 7.

There are only two recommended sshd_config changes for Oracle Linux 5:

Ciphers aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-ripemd160

Unfortunately, the PuTTY suite of SSH client programs for Win32 are incompatible with the MACs hmac-ripemd160 setting and will not connect to a V5 server when this configuration is implemented. As PuTTY quietly has become a corporate standard, this likely is an insurmountable incompatibility, so most enterprise deployments will implement only the Cipher directive.