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: Tuesday, 10. July 2018 22:25 PDT

Contents

1. News
2. Latest Blog Posts
3. Usage
   1. Examples
   2. Auxiliary Interface
4. Background
5. How it Works
6. Contact and Contributing
7. Statistics
   1. Connection Cipher Details
   2. Certificate Public Key Details

News

Latest Blog Posts

• The Matter of Heartbleed

• The SSLv3 POODLE Attack

• Dissecting the GnuTLS Bug

• Searching the ICSI Notary for Rogue Turktrust Intermediate Certificates

• The Tree of Trust

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 numbers. 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 17/2/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.

Statistics

Connection Cipher Details

The following graph shows the most-used cipher-suites that we saw being used in all connections in the last 30 days.

Certificate Public Key Details

The following graphs show statistics about the public keys contained in currently valid certificates.