Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations

By Chad Brubaker, Suman Sekhar Jana, Baishakhi Ray, Sarfraz Khurshid, Vitaly Shmatikov. 2014

248 citations recorded by the source corpus.

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.

Subfields: Information Systems, Software, Signal Processing

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Information Systems

In Software

In Signal Processing

Citations in the corpus

DeepXplore: Automated Whitebox Testing of Deep Learning Systems (2017, methodology): “Such differential testing techniques have been applied successfully in the past for detecting logic bugs without manual specifications in a wide variety of traditional software [6, 11, 14, 15, 45, 86].”
Closing the AI accountability gap: defining an end-to-end framework for internal algorithmic auditing (2020, methodology): “Adversarial testing is a common approach to finding vulnerabilities in both pre-release and postlaunch technology, for example in privacy and security testing [6].”
NEZHA: Efficient Domain-Independent Differential Testing (2017, methodology): “For instance, Frankencerts [24] and Mucerts [32] incorporate partial grammars for X.”
SFADiff: Automated Evasion Attacks and Fingerprinting Using Black-box Differential Automata Learning (2016, methodology): “Differential testing has been used successfully for testing a diverse set of systems including C compilers [32], Java virtual machine implementations [11], SSL/TLS implementations [8], mobile applications for privacy leaks [20], PDF malware detectors [31], and space flight software [18].”
Guided differential testing of certificate validation in SSL/TLS implementations (2015, methodology): “In particular, 8,127,600 frankencerts could only yield 208 discrepancies, which further reduce to only 9 distinct ones, among the many SSL/TLS implementations [13].”
HVLearn: Automated Black-Box Analysis of Hostname Verification in SSL/TLS Implementations (2017, background): “Once a model is inferred for a certificate template, HVLearn checks the model for bugs by finding discrepancies with the inferred models from other implementations or by checking against regular-expression-based rules derived from the specification.”
Sealed-Glass Proofs: Using Transparent Enclaves to Prove and Sell Knowledge (2017, methodology): “Note that SGX enclaves do not have access to a trusted source of (absolute) time, which is required for certificate validation (incidentally, many bugs discovered in [56] were due to incorrect verification of a certificate’s validity period).”
Fuzzing: A Survey for Roadmap (2022, background): “One way to gather a valid input corpus is to download files from the Internet [26].”
Protocol State Fuzzing of TLS Implementations (2015, unknown): “[10] or using the tool x509test1.”
The Art, Science, and Engineering of Fuzzing: A Survey (2018, background): “Several fuzzers [41], [171], [59] have used differential testing to identify discrepancies between similar programs, which are likely to indicate a bug.”
Combating Attacks and Abuse in Large Online Communities (2016, background): “However, an attacker can still intercept HTTPS tr affic, by setting up a proxy [1] between her phone and Waze server as a man-in-the-middle att ack [199, 57].”
Defending against Sybil Devices in Crowdsourced Mapping Services (2015, background): “However, an attacker can still intercept HTTPS traffic, by setting up a proxy [2] between her phone and Waze server as a man-in-themiddle attack [40, 9].”