A Case of Misplaced Trust
A lot of trust is placed in certificate authorities. SSL/TLS on its’ own protects against a malicious actors. It does this by intercepting communications. However, certificate authorities do nothing to prevent sending data to someone who has found a way to route client traffic to a copycat website.
Certificate Authorities is Not the Silver Bullet
In fact, there is no assurance that the endpoint they are attempting to visit is actually the site they’re visiting. To combat this, browsers maintain a carefully curated list of trusted Certificate Authorities, who are responsible for verifying domain ownership before signing a website’s certificate. Once the site’s certificate is signed, the browser verifies its “chain of trust”. This can be done by finding a trusted path of digital signatures, from a root certificate in its store to the leaf certificate the endpoint presents (potentially by way of a trusted intermediate certificate authority). Alternatively, the browser will present the user with an error.
The problem with this is that any certificate authority your browser trusts is able to issue certificates, trusted worldwide, for any domain on the public internet. A compromise of any one of these CAs could result in enough fodder for an attacker to maliciously intercept traffic from your users with them being none the wiser. We recommend you set policies to cull the list of CA’s trusted by their web browsers. However, this is not enough.
CAA Records
RFC 6844(https://tools.ietf.org/html/rfc6844), which specifies the standard for CAA records, is the IETF’s answer to this problem. CAA records are metadata published as a record type in a domain’s authoritative DNS. This allows an organization to publish a white-list of certificate authorities authorized to issue certificates for that domain.
CA’s are then expected to query for this record type at the root of the domain they’re considering issuing a certificate for. CA’s then deny requests that violate an organization’s published CAA policy. It is similar to how SPF records work for email. Optionally, DNSSEC can be used on top of CAA records to verify DNS integrity if both the verifying CA and the record holder’s DNS infrastructure support DNSSEC. DNSSEC uses digital signatures to digitally sign DNS records and changes.
Administratively, most organizations are only going to work with a handful of trusted partners to provide them with SSL/TLS certificates. There are always exceptions. For example, a lot of legacy software does not necessarily verify intermediate authorities in the certificate chain correctly.
Certificate Options
Thawte certificates are a popular choice in this scenario https://www.ssltrust.com.au/thawte-ssl. Thawte does a tremendous amount of work behind the scenes to ensure device compatibility by insuring that there are never multiple paths to verify their leaf certificates. Let’s say that our example organization issues almost all of their certificates through GeoTrust, but has some business critical software that has trouble verifying intermediate certificates. Through GeoTrust, your organization uses a WildCard certificate for many internal services. However, consider your organization mandates leaf certificates for extra security in their DMZ. The business wants to ensure that wildcard certificates only issue Extended Validation and not Domain Validation certificates. This business currently does not publish a CAA policy. However, their savvy CIO who read this article requests it.
How would they go about this? First, they would need to ensure that their provider for authoritative DNS supports the record type. BIND has always supported arbitrary record types. Windows Server has supported CAA records since Server 2016. Most cloud providers as of this writing will support CAA record types. Next, the user must craft the record to conform exactly to the RFC.
Your Record Would Then Look Like This:
YourDomain.com. CAA 0 issue “thawte.com”
0 issue “geotrust.com”
0 issuewild “geotrust.com; policy=ev”
0 iodef mailto:incidents@yourdomain.com
Each of these statements in most providers are single statement. Therefore, the above is probably 4 records of type CAA in any order.
CAA Records are not a Fix-All
Ultimately, CAA records are far from a silver bullet. Many providers still do not support these record types, and some others support them incompletely. Additionally, many providers do not support DNSSEC, so an attacker in control of one of the internet’s autonomous systems Border_Gateway_Protocol, or one of its core routers, could potentially trick the CA’s systems into ignoring CAA records. For larger organizations, CAA records can be useful to enforce internal policies.
An IT department might elect to enforce CAA policies on their domain in order to prevent another department from operating “Shadow IT”. As a result, the they would not funnel requests for SSL/TLS certificates through a help desk ticket. Without a CAA policy, this might occur with impunity, but if Sharon in Marketing works for an organization that employs CAA records, Information Technology would receive an email from the CA that rejects her request. It also serves as a layer of protection against a malicious administrator who tries to issue a wildcard certificate under-the-radar shortly before leaving the company. (EV certificates often trigger separation of duties policy within a company). Even if imperfect, CAA records are a powerful way to mitigate a very substantial risk.
Tags: CAA, Certificate Authorities, Cybersecurity, DNS records, Policy
