Creativa - Fotolia
Many of today's most prevalent internet-based services rely on consumer and business trust inherently. Individuals...
need to trust the e-commerce sites they purchase from, organizations need to validate and trust the partners and services they rely on, and everyone needs a way to verify that the trust they're presented with is verifiable in some generally accepted way.
In 2016, AWS started AWS Certificate Manager and Amazon Trust Services to use and manage certificates through Amazon. AWS is now in the process of moving certificates for its internal services -- such as Amazon Elastic Cloud Compute and Amazon DynamoDB -- to Amazon Trust Services.
In the past several years, faith in SSL/TLS has diminished significantly. Many of the most well-known cryptographic ciphers used to do SSL/TLS handshakes have proven mathematically weak, all the current versions of SSL are considered unsafe, and the vast majority of SSL/TLS implementations rely on open source software that has been soundly and repeatedly compromised. To top it all off, some of the world's certificate authorities (CAs) -- the organizations charged with providing the highest level of confidence in the SSL/TLS trust hierarchy -- have been shown to be less than fully trustworthy.
With its recent shift to Amazon Trust Services, AWS has become its own certificate authority. What this means is that a significant portion of the infrastructure that tenants are using is protected by Amazon, and only Amazon, with no other vetted parties in the trust hierarchy. This raises a big -- and obvious -- question: Is this new AWS certificate authority system a good thing or a bad thing?
The pros and cons of the AWS certificate authority
What the failure of SSL and the use of cryptographic certificates represent is nothing short of a total breakdown in internet trust and identity validation -- who is communicating with whom? Is the site I'm communicating with actually trusted and validated by a trusted provider? Can I trust what my browser is showing me?
In the case of AWS, users will have to place their trust entirely in Amazon for all the services it provides. This includes the main web sign-in page and all the services on the back end. The possible threat scenarios are the same as those for any CA or public key infrastructure deployment.
Weak cipher suites used for certificates could potentially lead to cryptographic vulnerabilities that attackers could exploit. A compromise of Amazon's CA could easily lead to a complete trust breakdown across all AWS services. Exposure of customer secrets, such as keys or passwords, or man-in-the-middle attacks could happen in either of these cases.
For many customers, the biggest challenge with the AWS certificate authority will be the lack of visibility into Amazon's PKI controls and components. For example, what software does Amazon use for its CA services? If it is homegrown -- which is likely -- are open source tools and libraries involved, and how are they vetted? What independent auditing will be done on the Amazon CA system to reassure customers that some degree of independent oversight is present?
On the flip side, there's a very good chance that AWS will actually be more secure by handling its own certificates. While there are definitely risks, AWS has a good track record in security so far, and there's no reason to expect that to change with full control of the CA trust hierarchy within its service model. In fact, it's likely that it'll do a better job than many of the other CAs we've seen over the years.
Customers should, as always, ask for as much detail about the AWS certificate authority services as AWS will provide, and push for ISO 27001 and other audits that can provide third-party assurance of valid controls.