Weaknesses in the SSL protocol (the protocol for encrypting information over the internet) or the public certificate authority (CA) ecosystem that underpin it have received a lot of coverage recently and the last couple of weeks have been no exception.
The pervasive nature of SSL and its unique role in securing ecommerce and numerous cloud services makes SSL attractive to security researchers and attackers alike. However, many of the lessons learnt are in no way specific to SSL and must be applied to other Public Key Infrastructure (PKI) and encryption deployments if we're to avoid handing potential attackers a skeleton key to access our sensitive data or critical infrastructure:
- Recent research by École Polytechnique Fédérale de Lausanne has reminded us that for encryption or digital signatures to be effective keys must have a strong provenance as well as strong protection for their entire lifecycle. Keys generated by a software algorithm and without a good source of entropy or randomness can be easy to crack and so are vulnerable to attack.
- Mozilla continues to roll-out stronger policies to CAs, banning the issuance of "Man In The Middle - MITM" SSL certificates that allow an enterprise to intercept communication that is supposed to benefit from "end to end" encryption from web browser to web server. At present this will be enforced by commercial rather than technical measures.
- At the same time Twitter continues the trend towards using SSL encryption by default for all web traffic.
While this is all good news for anyone who cares about the confidentiality and integrity of sensitive communications, there’s also a catch. Organisations face the challenge of deploying ever more sophisticated real-time intrusion prevention systems (IPS) and data loss prevention (DLP) solutions to protect against data leakage or intrusion. However the trend towards an increased reliance on SSL and the removal of the truly transparent MITM option by purchasing a sub-CA certificate will force organisations to augment every workstation’s trusted Root CA store with their own internal CA Root.
The result is a hybrid PKI with a mix of public and private CAs and the potential to create a new internal point of attack if the internal PKI is not well planned and deployed. As the trust in the public CA ecosystem grows, organisations in a rush to deploy a web security gateway should take great care to avoid generating a weakly generated or weakly protected software key that is then trusted by all of their workstations. The existence of trust in such a key has the potential to be a gift for an attacker.
A properly planned and deployed private CA can work well where all machines are administered by a single authority. The next hurdle the industry must face is that this sort of implementation doesn't scale well across organisation boundaries and gets even more difficult in a "Bring Your Own Device - BYOD" environment. But that’s a topic for another day...