The ability to quickly revoke a compromised key is critical to the security of a public-key infrastructure. Regrettably, most certificate revocation schemes suffer from latency, availability, or privacy issues. The problem is exacerbated by the lack of a native delegation mechanism in TLS, which increasingly leads domain owners to engage in dangerous practices such as sharing their private keys with third parties. We investigate the utility of "proxy certificates" to address long-standing revocation and delegation shortcomings in the web PKI. By issuing proxy certificates, entities holding a regular (non-CA) certificate can grant all or a subset of their privileges to other entities. This fine-grained control on delegating privileges requires no further actions from a CA, yet does not require trust on first use (TOFU). The lifetime of a proxy certificate can be made almost arbitrarily short to curb the consequences of a key compromise. We analyze the benefits of this approach in comparison to alternatives, discussing various use cases and technical implications. We also show that combining short-lived proxy certificates with other schemes constitutes an attractive solution to several pressing problems. Overall, we make the case that the benefits obtained from incorporating proxy certificates into the current PKI substantially outweighs the changes required in practice. Such changes are minimal, and would only be required on the browser end, should a domain owner opt to use proxy certificates.
@cite_34 recently showed, after analyzing as many as 48 browsers, that session resumption was also problematic for user privacy as it can be used to track the average user for up to eight days with standard settings. With a long session resumption lifetime, a majority of users can even be tracked permanently. Problems have also been discovered in the way CAs perform domain validation: exploiting a BGP vulnerability to hijack traffic, an attacker can obtain a rogue certificate from vulnerable CAs @cite_20 @cite_15 . also found serious vulnerabilities in popular implementations of SSL TLS using frankencerts'', certificates with unusual combinations of extensions and constraints @cite_36 .
@cite_36 @cite_15 @cite_34 @cite_20
1976919795 2889555490 2896648147 2889089210
Modern network security rests on the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. Distributed systems, mobile and desktop applications, embedded devices, and all of secure Web rely on SSL TLS for protection against network attacks. This protection critically depends on whether SSL TLS clients correctly validate X.509 certificates presented by servers during the SSL TLS handshake protocol. We design, implement, and apply the first methodology for large-scale testing of certificate validation logic in SSL TLS implementations. Our first ingredient is "frankencerts," synthetic certificates that are randomly mutated from parts of real certificates and thus include unusual combinations of extensions and constraints. Our second ingredient is differential testing: if one SSL TLS implementation accepts a certificate while another rejects the same certificate, we use the discrepancy as an oracle for finding flaws in individual implementations. Differential testing with frankencerts uncovered 208 discrepancies between popular SSL TLS implementations such as OpenSSL, NSS, CyaSSL, GnuTLS, PolarSSL, MatrixSSL, etc. Many of them are caused by serious security vulnerabilities. For example, any server with a valid X.509 version1 certificate can act as a rogue certificate authority and issue fake certificates for any domain, enabling man-in-the-middle attacks against MatrixSSL and GnuTLS. Several implementations also accept certificate authorities created by unauthorized issuers, as well as certificates not intended for server authentication. We also found serious vulnerabilities in how users are warned about certificate validation errors. When presented with an expired, self-signed certificate, NSS, Safari, and Chrome (on Linux) report that the certificate has expired - a low-risk, often ignored error - but not that the connection is insecure against a man-in-the-middle attack. These results demonstrate that automated adversarial testing with frankencerts is a powerful methodology for discovering security flaws in SSL TLS implementations. The security of Internet-based applications fundamentally relies on the trustworthiness of Certificate Authorities (CAs). We practically demonstrate for the first time that even a weak off-path attacker can effectively subvert the trustworthiness of popular commercially used CAs. Our attack targets CAs which use Domain Validation (DV) for authenticating domain ownership; collectively these CAs control 99 of the certificates market. The attack utilises DNS Cache poisoning and tricks the CA into issuing fraudulent certificates for domains the attacker does not legitimately own -- namely certificates binding the attacker's public key to a victim domain. We discuss short and long term defences, but argue that they fall short of securing DV. To mitigate the threats we propose Domain Validation++ (DV++). DV++ replaces the need in cryptography through assumptions in distributed systems. While retaining the benefits of DV (automation, efficiency and low costs) DV++ is secure even against Man-in-the-Middle (MitM) attackers. Deployment of DV++ is simple and does not require changing the existing infrastructure nor systems of the CAs. We demonstrate security of DV++ under realistic assumptions and provide open source access to DV++ implementation. User tracking on the Internet can come in various forms, e.g., via cookies or by fingerprinting web browsers. A technique that got less attention so far is user tracking based on TLS and specifically based on the TLS session resumption mechanism. To the best of our knowledge, we are the first that investigate the applicability of TLS session resumption for user tracking. For that, we evaluated the configuration of 48 popular browsers and one million of the most popular websites. Moreover, we present a so-called prolongation attack, which allows extending the tracking period beyond the lifetime of the session resumption mechanism. To show that under the observed browser configurations tracking via TLS session resumptions is feasible, we also looked into DNS data to understand the longest consecutive tracking period for a user by a particular website. Our results indicate that with the standard setting of the session resumption lifetime in many current browsers, the average user can be tracked for up to eight days. With a session resumption lifetime of seven days, as recommended upper limit in the draft for TLS version 1.3, 65 of all users in our dataset can be tracked permanently.