Security
SSL is a ubiquitous technology introduced in 1994. The use of SSL, and it’s descendant, TLS, is first and foremost based on established trust. A trusted authority validates a domain name as belonging to a particular entity. This trusted authority issues a Certificate to the entity, which is then used to “prove” ownership to any user of the domain.
But this model breaks when SSL/TLS is used on internal networks. Internet domain name rules are typically not used or enforced on internal networks. Managing certificates can be burdensome. Often network gear defaults to using a self-signed or otherwise “untrusted” certificate to facilitate session encryption.
All is well until the entity implements a vulnerability management program and the vulnerability scanner reports on those certificates used internally. Typical results include self-signed certificates, certificates signed by an untrusted Certificate Authority, etc. Note that these types of issues are separate and distinct from other SSL issues. The SSL protocol has gone through several cycles of updates as vulnerabilities within the protocol are discovered. As an example, all versions of SSL (1, 2, and 3) are deprecated and known to have vulnerabilities that affect their usefulness. This article does not address those issues, as they should be handled like any other vulnerability within the enterprise.
So if we listen to our vulnerability scans, it seems prudent to do something about all of these internally used certificates, if nothing other than to get “clean scans” from our scanner. But should we?
Risk mitigation starts with identifying risk. So how can we quantify the risk of self-signed certificates used internally? It helps to remember the original purpose of SSL: To authoritatively identify the host. Certificates work on the Internet because browser vendors distribute a list of root Certificate Authorities, or root CAs. These root CAs, or other CAs that have been authorized by a root CA, then produce a certificate by validating the certificate customer, sometimes with a phone call or an email. This is the basis of trust for Internet-facing SSL implementations.
So how can we provide the core function of SSL Certificates internally, that is, to authoritatively identify the host?
We have some challenges and a handful of solutions, each with advantages and disadvantages. The first option is to do nothing. This means accepting the risk that a particular service protected by a self-signed certificate is authentic. This is not an outlandish proposal. Often an SSL-protected service is the administrative interface for a system. This means only system administrators use the SSL-protected service. As system administrators tend to be more technically sophisticated, they may be more readily aware of the systems they manage. Getting a pop-up from a browser warning of an untrusted certificate just means the browser “sees” a self-signed certificate, something that might mean an attempt to masquerade as a legitimate service for criminal purposes, but is known and accepted internally, especially for a service system users do not use.
The second option is to establish an internal Certificate Authority, generate certificates for internal hosts, and add the Certificate Authority to users’ browsers/systems, to include the vulnerability scanner.
The advantage is that now internal systems can now be authoritatively identified, scans are clean, and all is right with the world. Believe it or not, this approach can actually increase the level of risk within the enterprise. If not done correctly, internal CAs can be abused to create unauthorized SSL certificates, destroying the basis of SSL, that is, trust that the certificate correctly identifies the host.
In order for an internal CA to be effective, controls must be in-place to limit the ability to create SSL certificates. This is not a trivial undertaking. Roles must be defined, processes documented, access controlled and logged, split-knowledge implemented, etc. Properly establishing and maintaining an internal CA is outside of the scope for this article, but the controls around managing an internal CA should be driven by the risk to the organization. Protecting one administrative interface to a network device is a very different risk profile than protecting a hundred RDP services used by all manner of users.
To identify the risks associated with the internal use of SSL certificates, first know the scope of the issue. What is the nature of the service being protected? How many users are exposed to the service? Does the service use credentials that are shared with different systems (e.g. SSO)?
Having a “failing” scan due to self-signed certificates internally may not be a failure. If the finding is related to the use of a “bad” certificate used internally, know the risks associated with the service, and be ready to show that the risks were identified and found to be acceptable. Otherwise, consider some of the solutions mentioned above, or other solutions as may be appropriate. Let risk drive the mitigation and controls used.
