The Lurking Menace of Broken TLS Validation
Monday October 15, 2012
As Transport Layer Security (TLS) becomes ubiquitous in securing network communication, it is critical that protocol implementations are written in a secure manner and correctly follow appropriate specifications. Recent research has highlighted widespread and pervasive protocol level flaws in the usage of TLS libraries. Specifically, implementations often do not perform proper hostname validation or do not require certificate authenticity checks by default - the effect of this is that while traffic is encrypted, authentication is not properly performed and can be broken by an active network attacker.
While the root causes of these flaws are varied, two prominent culprits are the difficulty in using current cryptographic libraries such as OpenSSL and the absence of proper unit tests to insure that validation is performed correctly. iSEC has released three artifacts to help address this wide spread security issue.
Certificate Validation in OpenSSL:
OpenSSL is widely used as a primitive in SSL implementations; however, it is non-trivial to use correctly and does not provide hostname validation. Everything You've Always Wanted to Know About Certificate Validation With OpenSSL provides clear guidelines on how to perform certificate validation using OpenSSL.
TLSPretense is a tool for testing certificate and hostname validation as part of an TLS/SSL connection. Testing is performed by actively intercepting and modifying certificates or replacing valid certificates. Example modifications include injecting self-signed certificates or certificates signed by a valid certificate authority but for a different hostname.
The SSL Conservatory:
This project intends to be a repository for well-documented and correct sample code to perform certificate validation using various languages and libraries. As a start, we have provided reference code to perform thorough certificate and hostname verification with OpenSSL.