The announcement earlier this month of the “Heartbleed” bug (CVE-2014-0160) in OpenSSL once again focused attention on the technology used to secure communications on the Internet. Heartbleed was a very serious vulnerability and we moved as quickly as possible to patch systems and eliminate this threat on behalf of our customers.
But security is not just about fire drills, there are many steps that can be taken over time to continually improve security. Over the last months we have rolled out several security improvements to Heroku SSL Endpoints, including:
- Perfect Forward Secrecy
- TLS 1.1, 1.2 support
- Updated ciphers
These enhancements have already been rolled out and are in effect for you today if you are running on our Cedar stack and using ssl:endpoint. If you are using the legacy ssl:hostname plan you will need to switch to ssl:endpoint to take advantage of the improvements.
With the new changes, your applications on Heroku now use the most up-to-date practices for securing incoming traffic. You can verify this by using an SSL testing tool like SSL Labs from Qualys. You should score at least an “A” using this tool. To get an “A+”, you will need to implement HTTP Strict Transport Security in your application. Our SSL endpoints will pass the appropriate headers through to your users.
Perfect Forward Secrecy?
While all of these changes are valuable, we want to draw some extra attention to Perfect Forward Secrecy. Imagine that an attacker is able to record the encrypted communication between a client and server for some time. Then at a later point, the attacker manages to steal the private key from the server. Perfect Forward Secrecy ensures this stolen private key cannot be used to decrypt communications from the past.
Heartbleed is an example of a bug that can be exploited to steal private keys. Should a similar bug be discovered in the future, you can now rest assured that past communications cannot be decrypted.
A Quick Note on BEAST
We often get questions about the BEAST attack, as SSL Labs will show it is no longer mitigated on the server side. BEAST is considered to be most effectively mitigated in clients at this point, so we have chosen to prioritize newer ciphers over the BEAST server mitigation. Qualys has an excellent write-up on this this, if you would like to learn more.