The ICSI Certificate Notary

Much of the Internet’s end-to-end security relies on the SSL protocol, along with its underlying X.509 certificate infrastructure. However, the system remains quite brittle due to its liberal delegation of signing authority: a single compromised certification authority undermines trust globally. The ICSI Notary helps clients to identify malicious certificates by providing a third-party perspective on what they should expect to receive from a server. While similar in spirit to existing efforts, such as Convergence and the EFF’s SSL observatory, our notary collects certificates passively from live upstream traffic at multiple independent Internet sites, aggregating them into a central database in near-realtime.

Last updated: Saturday, 18-May-2013 00:19:07 PDT

Contents

1. News
2. Usage
   1. Examples
   2. Auxiliary Interface
3. Background
4. How it Works
5. Contact and Contributing
6. The Tree of Trust
7. Statistics
   1. Number of Certificates Encountered per Day
   2. Certificate Public Key Details
8. Disclaimer

News

• 2013-03-19 We find that 58.76% of all our connections and 34.14% of all the seen certificates use RC4. This aligns with recent research by AlFardan et al. who find that 50% of all connections use RC4.

• 2013-01-05 None of our data providers encountered the two intermediate CA certificates accidentally issued by Turktrust.

• 2012-12-13 Added the tree of trust to visualize the relationships between intermediate and root CAs.

• 2012-12-11 Near the end of November, a user at one of our data providers began an experiment involving actively crawling the Internet for SSL certificates which explains the jump in the graph depicting the total number of certificates. This experiment continues today as the graph on unique certificates per day at the bottom of the page displays.

• 2012-11-06 Clarified the description of the DNS interface.

We also provide a changelog with a list of detailed changes concerning the notary infrastructure.

Usage

The ICSI Notary provides a public DNS interface to query its database. To request information about a certificate clients can send a DNS request to the following domain:

<sha1>.notary.icsi.berkeley.edu

The token <sha1> represents the SHA1 digest of a certificate (as, e.g., included in the information browsers report about SSL sessions). Our DNS service operates in two modes which employ A and TXT records respectively. In both modes, an answer of NXDOMAIN indicates that none of our data providers have encountered a certificate with the given digest.

For A record queries that have an associated entry, the notary answers with either 127.0.0.1 to indicate that we have seen the certificate, or with 127.0.0.2 if we can establish a valid chain to a root certificate from the Mozilla root store.

For TXT record queries, the notary replies with more details that come in the format of space-separated key-value pairs. We currently support the following keys:

• version: the current version of the response format
• first_seen: the day our data providers first saw the certificate (relative to 1/1/1970)
• last_seen: the most recent day any of them saw it
• times_seen: the number of different days in between first_seen and last_seen when at least one site encountered the certificate (including the interval endpoints)
• validated: a boolean flag indicating the current validation status of the certificate

An exemplary response for the digest C1956DC8A7DFB2A5A56934DA09778E3A11023358 may look like this:

version=1 first_seen=15387 last_seen=15646 times_seen=260 validated=1

We note that we log notary accesses for statistical purposes. However, our use of DNS provides clients with anonymity: when sending a recursive request to our DNS server, we only see the resolver’s IP address but not the one of the querier. If users want to avoid any evidence of their location, they can switch to public DNS services, such as OpenDNS or Google’s public DNS.

Examples

• Obtain a SHA1 digest from a certificate using OpenSSL and convert it into a domain that the notary can resolve:

  > openssl s_client -connect www.wikipedia.org:443 < /dev/null 2> /dev/null \
      | openssl x509 -outform DER \
      | openssl sha1 \
      | awk '{print $2 ".notary.icsi.berkeley.edu"}'
  

  This pipe sequence displays:

  75b75724743ff93d6df47f5c5a8c655a8f281bc2.notary.icsi.berkeley.edu
  

  Furthermore, you could pipe this result to xargs dig +short to query the notary directly.

• Check whether our notary could validate a certificate recently:

  > dig +short 592978A72A9061F70AD7C44C4D449DCF258CD534.notary.icsi.berkeley.edu
  127.0.0.2
  

  When asking the notary for an A record (the default mode of operation of the dig assumes A record queries), a non NXDOMAIN answer indicates that our data providers have seen the certificate ..D534 at some point in the past. An answer of 127.0.0.2 signifies that our most recent validation attempt went successfully.

• Retrieve details about a given certificate:

  > dig +short txt C1956DC8A7DFB2A5A56934DA09778E3A11023358.notary.icsi.berkeley.edu
  "version=1 first_seen=15387 last_seen=15646 times_seen=260 validated=1"
  

  When asking the notary for a TXT record, the notary returns three numbes. The first number reflects the first day our data providers have encountered the certificate ..3358, which was 15,387 days after 1/1/1970, i.e., on 2/17/2012. The second number 15,646 represents the last day they saw the certificate, i.e., on 2/11/2012. The third number 260 lists the number of different days between these two dates where it least one of our data providers encountered this certificate. When comparing this number to the difference of the first two, we get a rough idea how popular the certificate is. Since 15,646 - 15,387 + 1 = 260, we see that the certificate showed up on all days in the closed interval [first_seen, last_seen].

Auxiliary Interface

In addition to the primary interface described above, we also offer a DNS interface compatible to Google’s (now defunct) Certificate Catalogue. The domain <sha1>.cc.notary.icsi.berkeley.edu serves TXT records containing three space-separated values of the form first_seen last_seen times_seen with the fields having the same meaning as discussed above. For example, querying for the digest ...D534 returns the answer 15387 15646 260.

Background

The Secure Socket Layer (SSL/TLS) protocol serves as a centerpiece of the Internet’s end-to-end security, providing secure encrypted channels and authentication through its underlying X.509 certificate infrastructure. In a nutshell, X.509 certificate authorities (CAs) sign SSL server certificates, which clients then verify against a list of trusted root CA certificates that ship with their operating system or client software. Unfortunately, this system is quite brittle due to its liberal delegation of trust. All root and intermediate CAs share the authority to sign any certificate Internet-wide. Hence, the compromise of a single intermediate undermines the entire X.509 certificate infrastructure, rendering CAs an attractive target for attackers.

As demonstrated by several recent high-profile incidents, an attacker typically acts as a man-in-the-middle (MITM) to assume the identity of a well-known secure site (e.g., a bank or email provider) by serving a malicious certificate. From the victim’s perspective, the presented certificate validates correctly against their root store and hence the attack goes unnoticed. While the weaknesses of the current state have been widely acknowledged, there is no real solution in sight. The security community has proposed a number of alternative PKI architectures (e.g., EFF’s Sovereign Keys, Google Transparency); however, widespread adoption remains unlikely for the medium-term future due to the fact that both clients and servers would have to support a new system.

SSL notaries represent an alternative approach to improve the existing state without architectural changes. A notary maintains a third-party database of known server certificates. When clients encounter a certificate, they can match it against the notary’s version and flag mismatches as possible attacks. Notaries represent an attractive extension to the existing X.509 architecture as they introduce a non-obtrusive reputation scheme into the standard validation process. Perspectives pioneered this method and Convergence provides an improved implementation.

Our work follows this approach by offering a novel notary service for SSL clients. However, while existing notaries build their certificate databases actively—by either scanning the IP address space from different vantage points, or by asking users to submit what they see—we passively extract X.509 certificates from live network traffic as observed on an ongoing basis at operational sites. As such, our notary complements existing services by providing a near real-time perspective on certificates in actual use by a large client population, along with further reputation information such when we first observed a specific certificate and the number of sites that have reported it.

How it Works

To feed our notary service, we are currently working with about 10 organizations that have instrumented their border gateways with our monitoring infrastructure, uploading all certificates they see to a central system at the International Computer Science Institute in near real-time. We use the open-source Bro network monitor to extract certificates from all SSL connections, independent of the transport-layer ports. To avoid revealing information about the collecting site, we only inspect outgoing connections, and we do not record any information that would directly identify a client system. We implemented the SSL analysis as a Bro script that we give operators at participating sites.

When a site uploads data to our institute, we first import it into a database residing in an internal network. We exclude non-web certificates (e.g., Tor and Grid activity) and then generate a text zone file in DNSBL format on an hourly basis that we transfer over to the externally visible notary.icsi.berkeley.edu system located in a DMZ. We serve the zone file with an enhanced version of rbldnsd, a stripped-down, high-performance DNS server commonly used for high-volume blacklist-style information.

Contact and Contributing

Feel free to contact us for questions and feedback at notary@icsi.berkeley.edu. We are looking forward to hear about applications making use of the provided DNS interface. We are also seeking further sites to include into our data collection; please let us know if you may consider contributing data to the ICSI Notary.

The Tree of Trust

To better understand the relationships between root and intermediate CAs, we extracted from each certificate chain the path of intermediate CAs up to the root and then merged all paths into one single graph—the tree of trust.

In this graph, each node represents a CA, where red nodes correspond to root CAs and green nodes to intermediates. The node diameter scales logarithmically with the number of certificates signed by the node. Similarly, the color of the green nodes scales proportional to the diameter. For example, large and deep green nodes represent intermediate CAs which have signed a large number of certificates, as opposed to small and light green nodes.

We provide an interactive version of the tree of trust for easier navigation. Hovering over a node highlights all intermediate CAs for the corresponding root CA. Clicking on a node displays additional information in a side bar, including the exact number of certificates issued by that CA, the value of the issuer field, the validity period, key size and signature algorithm of the associated public key. Moreover, the search bar allows for quick location of a CA by name.

Statistics

• Number of certificates in notary: 1110516
• Number of non-expired certificates in notary: 759205
• Number of validated certificates in notary: 597127

Number of Certificates Encountered per Day

Certificate Public Key Details

The following graphs show statistics about the public key contained in the certificate.

Disclaimer

ICSI provides the notary as a service to the community for non-commercial use only. Use at your own risk. Neither ICSI and nor its contributors assume any responsibility for correctness and availability, and they shall not be held liable for any actions taken on the basis of the provided information.