HPN SSH/SCP NONE Cipher Switching
NONE Cipher Switching
The NONE cipher is, essentially, a method to transfer data using the SSH protocol but without any encipherment of the data. While this may seem counter to the whole concept of SSH, which does stand for security after all, there are valid reasons for wanting to make use of the NONE cipher in production environments. First and foremost is the drastically decreased load on the CPU. Encipherment with almost any modern robust cipher is very computationally expensive and as such can act as a bottleneck even on the fastest systems. Even inexpensive ciphers can start to act as a bottleneck if there are multiple simultaneous connections or other concurrent CPU intensive applications running.
In many instances the encipherment isn't even actually necessary. Users commonly use SCP to transfer non-sensitive bulk data: data sets, applications, soure code archives, and other routine data whose potential for misuse 'in the wrong hands' is minimal, or data that is already encrypted prior to transfer. However, people are often forced to use SCP because justifiably concerned system administrators have disabled any protocol that transfers authentication data (password for example) in the clear. Other methods of transfering bulk data - such as Kerberized FTP and Grid FTP do not encipher the data but do incorporate secure authentication methods. However, SSH/SCP didn't give users that option - it was, in almost all cases, full encryption or refused connections.
Considering the manner in which people are now using SCP and the additional requirements of high speed transfers it would be best if we could devise a method to make use of the NONE cipher reasonable. We decided that if we could have full encryption of the authentication process and then somehow switch the cipher to NONE afterwards we would have a useful solution that met the needs of the users and the system administrators.
Fortunately a review of the OpenSSH code revealed that most of the mechanisms we needed were already in place the most important of which being the ability to switch ciphers in mid-stream. We devised a method through which a message would be passed between the client and server requesting a cipher switch. We then simple had to advertise the NONE cipher as the only available cipher. As long as both the client and server supported the NONE cipher all remaining data transferred on that SSH channel would be in plaintext. However, we decided that it was still important to maintain the assurance of data integrity to guard against man in the middle attacks. Therefore we decided to leave the Hashed Message Authentication Code (HMAC) routines in effect even for plaintext transfers. While this does add some overhead we felt it was fully justified.
The one main problem with NONE ciphers are the possibility that a user might log into an interactive shell session while using it and, at some point, use their password to log into another machine. The effect of which would be to transfer their password (and all of their keystrokes) in the clear. Therefore, we decided to place restrictions on how the NONE cipher could be used. We have put safeguards in place that should under almost all situations prevent it from being used during an interactive session. Anytime SSH spwans a TTY or if the user uses the '-T' to supress TTYs the NONE cipher is disabled. While its possible that a user could somehow get around these restrictions we feel that these safeguards should be sufficient.
In summary:
- NONE cipher means less CPU load
- NONE cipher does not disable HMAC data integrity checks
- NONE cipher cannot be used in a non-bulk transfer or TTY session
- NONE cipher is roughly equivilant to useing GridFTP or Kerberized FTP
- NONE cipher should be used with caution
The National Science Foundation and
Cisco Systems, Inc.