Difference between revisions of "Wild Card Certificates"
From MgmtWiki
(→Other Material) |
(→Solutions) |
||
| Line 15: | Line 15: | ||
==Solutions== | ==Solutions== | ||
Most security solutions are not formulated as principles to adhere to but as checklists of things that developers must do or must avoid and so are written as heuristics that have proven valuable in the past to preventing loss. The following should be viewed as heuristics in that vein. | Most security solutions are not formulated as principles to adhere to but as checklists of things that developers must do or must avoid and so are written as heuristics that have proven valuable in the past to preventing loss. The following should be viewed as heuristics in that vein. | ||
| − | # View all the computers using the same certificate as operating in a secured enclave with the same security rules applied to every computer and every service within that enclave. While there is another heuristic that claims that security perimeters no longer can be trusted, that heuristic cannot be applied to computers and services that depend on the same certificate. Otherwise the security of all can be compromised by the weakest security server in the enclave. | + | # View all the computers using the same certificate as operating in a secured enclave with the same security rules applied to every computer and every service within that enclave. While there is another heuristic that claims that security perimeters no longer can be trusted, that heuristic cannot be applied to computers and services that depend on the same certificate. Otherwise the security of all can be compromised by the weakest security server in the enclave. It is certainly possible that servers with access to the wild card HTTPS keying material are in widely disbursed geographical locations, which will make the task difficult. But that difficulty must be overcome to be secure. |
==References== | ==References== | ||
Revision as of 15:20, 5 November 2021
Wild Card Certificates
Wild Card Certificates allows servers with different URLs, but the same origin to use the same security certificates.
Context
Web servers use digital certificates to establish a connection between the server and the user's computer also called the client computer, that is secure against a variety of attacks by malicious actors with a variety of motives.
- A wildcard certificate is a single certificate with a wildcard character in the X509 certificate subject field (ex. CN = *.example.com) or subject alternative name field allowing the certificate to validate the identity of multiple subdomains of the same root domain.
Problems
- Acquiring and maintaining certificates and secured servers is an expensive and time consuming process. Such security is not put there to gain customers but to protect the providers from losses of both money and disgruntled customers.
- Mixed security sites allows both HTTP (unsecured) and HTTPS (secured) connections for a variety of good reasons including redirection of all traffic to a secured connection.
- Any server that can communicate with clients using the same certificate (and hence the same same origin URL) has access to all cookies and data in any client computer that connects to the it. Increasingly the security features of the browser are shared only with services attaching to the same origin URL end points. That security can thus be breached by any server that can utilize that certificate.
- Cybersecurity researchers have shown (2021) that using wildcard or other certificates that represent servers with mixed levels of security can lead to exploitable web vulnerabilities that don’t depend on TLS weaknesses or private key compromises. Under certain conditions, this technique, dubbed Application Layer Protocols Allowing Cross-Protocol Attacks (ALPACA)[1], allows malicious actors to exploit fault tolerance features of web browsers and servers combined with protocol confusion between HTTP and other text-based protocols protected by TLS to perform arbitrary actions and view sensitive data.
Solutions
Most security solutions are not formulated as principles to adhere to but as checklists of things that developers must do or must avoid and so are written as heuristics that have proven valuable in the past to preventing loss. The following should be viewed as heuristics in that vein.
- View all the computers using the same certificate as operating in a secured enclave with the same security rules applied to every computer and every service within that enclave. While there is another heuristic that claims that security perimeters no longer can be trusted, that heuristic cannot be applied to computers and services that depend on the same certificate. Otherwise the security of all can be compromised by the weakest security server in the enclave. It is certainly possible that servers with access to the wild card HTTPS keying material are in widely disbursed geographical locations, which will make the task difficult. But that difficulty must be overcome to be secure.
References
- ↑ M. Brinkmann, + 7 ALPACA: Application Layer Protocol Confusion – Analyzing and Mitigating Cracks in TLS Authentication (2021) https://alpaca-attack.com/ALPACA.pdf
Other Material
- Avoid Dangers of Wildcard TLS Certificates and the ALPACA Technique US NSA 2021 - was the source of some of the above information and contains a large volume of related material.
