Wild Card Certificates - Revision history

Tom: /* Solutions */

2022-09-21T01:31:01Z

‎Solutions

Tom: /* Solutions */

2021-11-06T00:16:36Z

‎Solutions

Tom: /* Solutions */

2021-11-06T00:04:31Z

‎Solutions

Tom: /* Solutions */

2021-11-05T23:24:44Z

‎Solutions

Tom: /* Solutions */

2021-11-05T23:22:51Z

‎Solutions

Tom: /* Solutions */

2021-11-05T23:20:43Z

‎Solutions

Tom: /* Other Material */

2021-11-05T23:17:08Z

‎Other Material

Tom: /* Other Material */

2021-11-05T23:15:59Z

‎Other Material

Tom: /* Problems */

2021-11-05T23:13:17Z

‎Problems

Tom: /* Problems */

2021-11-05T23:12:38Z

‎Problems

@@ Line 15: / Line 15: @@
 ==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.
+# 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.
 # 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.

@@ Line 18: / Line 18: @@
 # 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.
 ==References==

@@ Line 16: / Line 16: @@
 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.
-# 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
+# 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.

@@ Line 17: / Line 17: @@
 # 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.
 # 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
 ==References==

@@ Line 16: / Line 16: @@
 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==

@@ Line 20: / Line 20: @@
 <references />
 ===Other Material===
-* [https://media.defense.gov/2021/Oct/07/2002869955/-1/-1/0/CSI_AVOID%20DANGERS%20OF%20WILDCARD%20TLS%20CERTIFICATES%20AND%20THE%20ALPACA%20TECHNIQUE_211007.PDF Avoid Dangers of Wildcard TLS Certificates and the ALPACA Technique] US NSA 2021 - was the source of some of the above information.
+* [https://media.defense.gov/2021/Oct/07/2002869955/-1/-1/0/CSI_AVOID%20DANGERS%20OF%20WILDCARD%20TLS%20CERTIFICATES%20AND%20THE%20ALPACA%20TECHNIQUE_211007.PDF 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.
 [[Category: Trust]]

@@ Line 11: / Line 11: @@
 * 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 recently shown 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)<ref>M. Brinkmann, + 7 ''ALPACA: Application Layer Protocol Confusion – Analyzing and Mitigating Cracks in TLS Authentication'' (2021) https://alpaca-attack.com/ALPACA.pdf</ref>, 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.
+* 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)<ref>M. Brinkmann, + 7 ''ALPACA: Application Layer Protocol Confusion – Analyzing and Mitigating Cracks in TLS Authentication'' (2021) https://alpaca-attack.com/ALPACA.pdf</ref>, 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==