New research by three German Universities has discovered that TLS is vulnerable to certificate confusion where wildcard or multi-domain certificates have been deployed. Dubbed ALPACA, Application Layer Protocol Confusion—Analyzing and Mitigating Cracks in TLS Authentication, the researchers’ findings are described in an academic paper that's scheduled to be presented in August at Black Hat USA 2021 and the USENIX Security Symposium 2021.
According to the research, adversaries can launch man-in-the-middle (MitM) attacks to redirect TLS traffic to a different endpoint because TLS is independent from the application layer and does not bind TCP connections to the desired application protocol (e.g., HTTP, SMTP, IMAP, POP3, and FTP).
The researchers demonstrated that their technique works by registering an account with email provider Mailfence. However, they say they found similar exploitable issues at a major Bitcoin exchange, the website of a large university, and the Government of India's webmail service. In total, the researchers identified 1.4 million web servers that are potentially vulnerable to protocol confusion and 119,000 of these that are open to attack by an exploitable application server.
“Cross-protocol attacks are a familiar and devastating category of attacks made famous by such threats as the DROWN attack of 2016 and many others,” says Pratik Savla, lead security engineer at Venafi. “In this class of attacks, a threat actor enables a client to initiate a transaction in one protocol but towards the server that knows a different protocol. An attacker might take advantage of this scenario and make such a transaction appear as a valid transaction in the second protocol.”
Although the researchers argue that ALPACA attack is difficult to be implemented because it requires a number of prerequisites and depends on the complicated interplay between applications, protocols, and browsers, it should not be ignored. To mitigate this threat, they suggest implementing Application Layer Protocol Negotiation (ALPN) and Server Name Indication (SNI) extensions to TLS as a barrier to cross-protocol attacks. However, the downside to this suggestion is that deploying these protections could shut out legacy clients and servers that haven't been updated yet.
At the same time, Mozilla and the CA/B Forum are mandating that wildcard certificates will be prohibited for domains validated with the HTTP method. The justification behind this decision is that the use of such certificates prohibit the HTTP validation method from verifying domain control.
The HTTP domain validation method (officially known as method 6, Agreed-Upon Change to Website) demonstrates control over a domain by placing a file at a specific directory of the website. However, websites do not have the same level of controls as DNS has, where there is a formal delegation of permissions from the domain to subdomains. If example.com, protected by a wildcard certificate, gets compromised or impersonated, the attackers can use the compromised certificates to further launch subdomains that can be different entities like phishing sites.
As a result, Mozilla and the CA/B Forum are mandating that issuance of wildcard certificates containing domains validated with the HTTP method be limited to issuance of exactly the validated domain. This decision will impact customers since it’s a common method used for domain validation. If they still want to continue using this method, then they must validate each SAN:DNSName individually.
“This research lays bare (even though a bit tangentially) as well as reinforces the extreme vulnerability that wildcard certificate usage can lead to for organizations,” notes Savla. “Companies should keep in mind that the more extensively wildcard certificates are used in their environment, the more it could result in the widening of the attack surface. And any added reactionary approach would only serve to prolong security incident response.”
Before using wildcard certificates, you should make sure you understand the value and the risks of these certificates. After all, you don’t want to see your organization’s name associated with a phishing attack. A compromised wildcard certificate can lead to serious repercussions. But you can avoid (or at least mitigate) the potential impact of an attack by using short-lived, non-wildcard certificates.