Difference between revisions of "Wild Card Certificates"
From MgmtWiki
(→Solutions) |
m (→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 | + | # View all the computers using the same certificate as operating in a [[Secure 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. |
| − | # If it is not possible to secure all locations using the HTTPS keying material, then there must be some additional application level security in place to overcome that vulnerability. In no case should security features like [[Token Binding]] that mix security at transport layer and application layer be encouraged. | + | # If it is not possible to secure all locations using the HTTPS keying material, then there must be some additional application-level security in place to overcome that vulnerability. In no case should security features like [[Token Binding]] that mix security at transport layer and application layer be encouraged. |
# The simplest solution is to avoid any user of [[Wild Card Certificates]] altogether. | # The simplest solution is to avoid any user of [[Wild Card Certificates]] altogether. | ||
# Another solution is to literally create a secure enclave behind a proxy server that is the only server to have access to the HTTPS keying material and can be trusted to send the incoming data only to the correct application, provided that the full server name will unerringly identify the application. | # Another solution is to literally create a secure enclave behind a proxy server that is the only server to have access to the HTTPS keying material and can be trusted to send the incoming data only to the correct application, provided that the full server name will unerringly identify the application. | ||
Latest revision as of 18:31, 20 September 2022
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 Secure 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.
- If it is not possible to secure all locations using the HTTPS keying material, then there must be some additional application-level security in place to overcome that vulnerability. In no case should security features like Token Binding that mix security at transport layer and application layer be encouraged.
- The simplest solution is to avoid any user of Wild Card Certificates altogether.
- Another solution is to literally create a secure enclave behind a proxy server that is the only server to have access to the HTTPS keying material and can be trusted to send the incoming data only to the correct application, provided that the full server name will unerringly identify the application.
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.
