To stay secure: Four new SSL implementation thoughts
10 years ago, I left my position as the principal architect at a major U.S. financial institution. We developed the standards for how SSL was used inside the bank and their systems. Because of the weakness of ADC hardware at the time, we standardized on the “fastest and lightest” ciphers that would allow us to be compliant for online banking. In today’s age, many would argue that is absolutely foolish. But is it?
We know that SSL has changed a lot in the last 10 years. Old ciphers are now considered insecure, obsolete, and out of PCI compliance. In looking at what many companies have shared about how they deal with SSL, we know there’s a blend of “just enough” cryptography to pass, and “Next-Gen” crypto, as some are calling it. According to Gartner, 50% of traffic in enterprises today is encrypted.
There’s a reason for this: If done incorrectly or in attempts to use existing investments, you may be forced to use weak ciphers. An example of this is when we built our own SSL-based Reverse Proxy (similar to what an SSL VPN does today), we used an off-the-shelf ADC to do the encryption. This worked great in single user testing. If we used 3DES or AES256 ciphers, we could get exactly four users logged into the system before it overwhelmed the load balancer. When we weakened the ciphers to RC4-MD5 (128 bit), we could get hundreds of concurrent users through the system. Times have changed, and ADC technology has vastly improved its capabilities for SSL. Not all vendors are equal though when it comes to SSL capabilities, and this is where it gets tricky.
Say, for example, you’ve been using an Intrusion Detection or Intrusion Prevention system, and now you want to inspect encrypted traffic. How long has the IPS/IDS vendor been in the SSL space? For every hardware-based crypto card, there’s a cost associated with that hardware. For every device that HAS (and not all of them do) hardware cards, how many of them are capable of doing Next-Gen Crypto? One thing is for sure is that Elliptic Curves take a LOT more processing power, and the older legacy systems using CPU only may introduce a lot of latency.
[You might also like: Network Security Does Not Matter When You Invite the Hacker Inside]
ECDH is a variant of the Diffie-Hellman protocol using elliptic curve cryptography. Elliptic curve Diffie-Hellman (ECDH) is an anonymous key agreement protocol that allows two parties, each having an elliptic curve public-private key pair, to establish a shared secret over an insecure channel. This shared secret may be used as a key, or better yet, to derive another key which is then used to encrypt subsequent communications with a symmetric key cipher.
Alternative protocols include the Fully Hashed MQV (FHMQV), an authenticated protocol for key agreement based on the Diffie-Hellman scheme. SSL supports forward secrecy using two algorithms, the standard Diffie-Hellman (DHE) and the adapted version for use with Elliptic Curve cryptography. Diffie-Hellman will NOT work in Out of Path solutions for mitigation. This poses a real problem for some deployment options.
Because of the Snowden revelations, companies are pushing forward with Next-Gen Crypto. We know that companies are still buying older, obsolete technologies that do not support ECDH. With the amount of cyber-attacks leaning toward SSL, some interesting times are ahead. More failures are going to be because of crypto hardware being insufficient, and compromises in data security will be made to attempt to utilize these obsolete technologies being sold today. Some companies openly admit that they do not support Diffie-Hellman and encourage you to turn off the cipher specs to accommodate their obsolete technology. We think this is a step in the wrong direction.
We encourage companies to help future-proof their environments by utilizing central points of SSL for security tools. One example is to utilize technologies that will work with today’s Next-Gen Crypto and use Asymmetric Key Exchange. NIST has standardized elliptic curve cryptography for digital signature algorithms in FIPS 186 and for key establishment schemes in NIST Special Publication 800-56A. With the GDPR compliance deadline in May 2018, we predict this issue will become a much larger issue for companies.
