8

At work we've been trying to move our external-facing services away from a policy of inclusivity (where we tried to accept as many people as possible) to a more security-focused setup.

The first step was pen-testing some of our core web applications, where the focus tends to be on weaknesses in the application code, but a lot has been said of the SSL/TLS suites and ciphers. Off the back of these test results, I have managed to at least get enough people interested in attaining the A-, A and A+ "grades" in the Qualys tests (management like quantifiable grades -- who knew?!).

However, another key component of some of our software is bulk-file upload/download via SFTP (i.e. over SSH). I always have tried to apply as good practice as I could determine on the SFTP servers, so we routinely use:

  • key-only authentication
  • blacklisting repeated authentication failures
  • 2,048-bit keys
  • disabling shell, exec and port-forwarding

But I must concede that I know very little about the crypto implementations, so the default settings have almost always been used. However, I presume that, if a pen-tester flags RC4, 3DES, MD5, et al. in a TLS-based setup, they would also flag these algorithms in an SFTP server (were it included within their scope).

I'm primarily working on a Windows stack, and we've been using VanDyke VShell as our SFTP server of choice for a number of years. By default, it enables all Cipher and MAC options (except for 'None') and all Key Exchange options except for 'Kerberos' and 'Kerberos (Group Exchange)'.

This leaves the following algorithms, as named by the VShell application:

  • Key Exchange: diffie-hellman-group14, diffie-hellman, diffie-hellman-group
  • Cipher: AES-256-CTR, AES-192-CTR, AES-128-CTR, AES-256, AES-192, AES-128, Twofish, Blowfish, 3DES, RC4
  • MAC: SHA1, SHA1-96, MD5, MD5-96, UMAC-64 (and, in more recent versions) SHA2-512, SHA2-256

As for the questions:

  1. Where are the best references for me to determine which of these are now considered too weak to use?
  2. How can I best-determine whether disabling any of these will adversely affect my end-users?
  3. Are there any Qualys-like tests that I can use to regularly evaluate these servers, preferably with compelling evidence with which to beat management into submission?
jimbobmcgee
  • 408
  • 1
  • 4
  • 12
  • 2
    MD5, SHA-1 and RC4 should not be used anymore. – Daniel Ruf Dec 04 '15 at 18:14
  • @DanielRuf - that doesn't exactly leave me with very much on the MAC front. Is `UMAC-64` particularly useful? Besides, I thought SHA1 was still safe-enough for message authentication -- is that no longer the case? – jimbobmcgee Dec 07 '15 at 14:00
  • 1
    Daniel is incorrect regarding the hashes. Both of those are not bad to use for MACs, although it is still better to use something stronger. It is completely true that RC4 should be avoided, however. – forest Apr 07 '16 at 01:24

1 Answers1

4

  1. Unfortunately the standards bodies don't fully agree on a single list of ciphers for SSL/TLS or SSH security. The following document and it's internal references will help a lot and I would think that in general owasp.org would be a great place to keep up with weak ciphers but unfortunately there is no one universal list at this time.

    https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

    For SSH hardening specifically look at the following:

    https://stribika.github.io/2015/01/04/secure-secure-shell.html

    Ultimately an up to date list mapping the cipher supported with a reason why each one was depreciated would be useful for everyone but I haven't seen such an effort yet.

  2. The best way to know what your end users are using is to monitor actual traffic to your site. You can either enable cipher suite logging on your SFTP server or webserver or simply use a protocol analyzer like WireShark, tshark specifically, for this.

    https://www.wireshark.org/

    Generally you will find that limiting cipher suites is actually easy because most clients from the last 5-10 years support a wide range of ciphers.

  3. To test this I highly recommend using the nmap ssl enumerate ciphers .NSE script or for SSH the SSH2 enumerate algorithms script:

    https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html

    The command to test a website will look similar to the following:

    nmap --script ssl-enum-ciphers -p 443 www.website.org

    There are similar scripts for other protocols, for SSH the following would work

    https://nmap.org/nsedoc/scripts/ssh2-enum-algos.html

    This information can be gathered from the debug2 information in the ssh -vvv option but nmap is far easier to automate.

    For externally testing websites there are sites like the following which will tell you information about depreciated SSL/TLS ciphers on HTTPS based services.

    https://www.ssllabs.com/ssltest/

At this time there are no "Qualys like test websites that match their SSL test website for SSH" the closest way to get similar information for SSH is to use ssh -vvv option or use the nmap NSE script ssh2-enum-algos.html. There are other solutions to this but nmap is probably the easiest to implement and it's very scriptable so you could have it test a huge number of IP's easily.

Trey Blalock
  • 14,099
  • 6
  • 43
  • 49
  • SFTP and SSH do not use SSL/TLS suites, nor exactly the same algorithms, although they share primitives like AES and HMAC and RSA. SFTP is an FTP-like protocol (but not actually FTP) over SSH. *FTPS* is FTP (exactly) over SSL/TLS but is relatively rare. – dave_thompson_085 Apr 07 '16 at 09:41
  • dave_thompson_085 You are correct I think I cleaned up the language at the end enough to prevent confusion. – Trey Blalock Apr 07 '16 at 13:48