Aggregating Certificate Transparency Gossip Using Programmable Packet Processors

(1)

Aggregating Certificate Transparency Gossip Using Programmable Packet Processors

Rasmus Dahlberg

Faculty of Health, Science and Technology Computer Science

E-Dissertation 30 HP Advisor: Tobias Pulls Examiner: Andreas Kassler Date: January 19, 2018

(2)

(3)

Aggregating Certificate Transparency Gossip Using Programmable Packet Processors

Rasmus Dahlberg

(4)

(5)

This thesis is submitted in partial fulfillment of the requirements for a Master’s degree in Computer Science. All material in this thesis that is not my own work has been identified and no material is included for which a degree has previously been conferred.

Rasmus Dahlberg

Approved, January 19, 2018

Advisor: Tobias Pulls

Examiner: Andreas Kassler

(6)

(7)

Abstract

Certificate Transparency (CT) logs are append-only tamper-evident data structures that can be verified by anyone. For example, it is possible to challenge a log to prove certificate inclusion (membership) and log consistency (append-only, no tampering) based on partial information. While these properties can convince an entity that a certificate is logged and not suddenly removed in the future, there is no guarantee that anyone else observes the same consistent view. To solve this issue a few gossip protocols have been proposed, each with different quirks, benefits, assumptions, and goals. We explore CT gossip below the application layer, finding that packet processors such as switches, routers, and middleboxes can aggregate gossip passively or actively to achieve herd immunity: (in)direct protection against undetectable log misbehaviour. Throughout the thesis we describe, instantiate, and discuss passive aggregation of gossip messages for a restricted data plane programming language: P4. The concept of active aggregation is also introduced. We conclude that (i) aggregation is independent of higher-level transparency applications and infrastructures, (ii) it appears most prominent to aggregate Signed Tree Heads (STHs) in terms of privacy and scalability, and (iii) passive aggregation can be a long-term solution if the CT ecosystem adapts. In other words, not all sources of gossip must be encrypted to preserve privacy.

(8)

Acknowledgements

First we would like to thank our advisor, Tobias Pulls, for his invaluable support throughout the course of this work. The initial premise was developed in cooperation with him and Andreas Kassler. We would also like to thank Ricardo Santos, Cristian Hernandez Benet, and Jonathan Vestin for sharing their SDN, P4, and NetFPGA knowledge; Jonas Karlsson and Javid Taheri for providing equipment; Toke Høiland-Jørgensen for informing us about XDP; and Karl-Johan Grinnemo for discussing minimum MTUs. Our NetFPGA SUME board was purchased within HITS, which is funded by the Swedish Knowledge Foundation.

(9)

List of Figures

1.1 Information security is about confidentiality, integrity, and availability. . . 1 1.2 A perceived TLS connection between Alice and Bob’s e-commerce business

can be actively intercepted if a fraudulent certificate c⁰_bob is issued to a MitM attacker. . . 2 2.1 A packet switch has a number of ports that process and queue packets. The

next hop is decided based on a routing table, packet header fields, and other metadata. . . 6 2.2 IPv4 packet header (dotted fields excluded for brevity). . . 9 2.3 A UDP header specifies a source port, a destination port, a datagram length

in bytes, and a checksum that covers the payload plus a number of header fields. . . 9 2.4 TCP header (dotted fields excluded for brevity). . . 10 2.5 DNS question-response format (dotted fields excluded for brevity). . . 11 2.6 A high-level P4 program can be compiled into a target-specific packet

(de)parser and a sequence of match-action tables that are populated by the control plane at runtime. . . 13 2.7 Between (de)parsing, the P4₁₄ forwarding model assumes an ingress pipeline,

a traffic manager, and an egress pipeline. A pipeline is composed of match- action tables. . . 14 2.8 A cryptographic hash function H is preimage resistant, second preimage

resistant, and collision resistant if it is computationally hard to determine any non-trivial input. . . 14 2.9 Merkle tree with values s–z. The dashed nodes compose an audit path for s,

and it is obtained by traversing the tree down to the leaf (select the hash of each sibling). . . 16 2.10 A simplified TLS session. . . 18

(13)

2.11 A TLS server can deliver SCTs using an X.509v3 certificate extension (sct x509), a stapled OCSP response (sct ocsp), or a TLS handshake exten-

sion (sct extn). . . 19 2.12 A log serves JSON encoded objects via HTTPS on request. . . 20 2.13 Gossip can detect logs that present split-views. . . 22 3.1 A TLS connection traverses a sequence of ASes that different entities control. 26 3.2 Network operators and backbone packet processors can aggregate gossip as

a service. . . 27 3.3 Passive STH aggregation involves a freshness check, two exact-match table

look-ups, and a signature verification. The size of a fresh history is bound by a constant. . . 30 3.4 Passive SCT aggregation involves two exact-match table look-ups and a

signature verification. The history grows linearly in the number of issued certificates (can be rotated). . . 31 4.1 Packet parser overview. The DNS state extracts the initial (fixed) portion

of the header, while variable components are parsed thereafter in multiple stages. . . 35 4.2 The ingress pipeline does per-packet security assessments, STH aggregation,

and routing towards the destination based on control-plane maintained tables. 36 4.3 In order to prevent an adversary from bypassing gossip, a DNS packet is

dropped if it does not contain a complete question section or a valid TXT string for recognized logs. . . 37 4.4 Emulated test environment using Mininet and a P4-enabled software target. 39 5.1 The method in this thesis evolves around hands-on experience using P4. . 42 5.2 STH interarrival times during September, October, and November. . . 45

(14)

List of Tables

2.1 Protocols in this thesis, grouped by layers in the Internet protocol stack. . 8 3.1 Protocols that deliver plaintext CT gossip. . . 28 5.1 Gossip protocols categorized by type, requirements, and application indepen-

dence. . . 46

(15)

1 Introduction

Suppose that Alice must place an order from Bob’s e-commerce business using a credit card.

Not only is it important that the service is available on demand (else Bob may experience revenue loss), but transactional confidentiality and integrity are critical to (i) prevent an eavesdropper from learning Alice’s credit card information, and (ii) detect tampering such as replacing the delivery address. As shown in Figure 1.1, an Information Technology (IT) system that provides these properties adheres to the Confidentiality, Integrity, and Availability (CIA) triad. This is a well-known starting point for information security [65].

confidentiality availabilit

y integrit

y IT security

Figure 1.1: Information security is about confidentiality, integrity, and availability.

On the web, confidentiality and integrity are commonly provided by the successor of Netscape’s Secure Socket Layer (SSL). Composed of a handshake and a record protocol, this is referred to as Transport Layer Security (TLS) [15]. The purpose of an initial handshake is to establish key material that the record protocol can use to secure the session. Returning to our e-commerce example, this typically involves the presentation of a server certificate that proves to Alice whether she is interacting with Bob [5]. The proof is issued by a trusted Certification Authority (CA), who can vouch for arbitrary identity-to-key bindings.

This means that the CA ecosystem is no stronger than the weakest link: a malicious or compromised CA can impersonate any identity by issuing fraudulent certificates [18].

Google, among others, detected cases of certificate mis-issuance in the past [33, 41,42,71].

Figure 1.2 illustrates how a fraudulent certificate might be exploited. The idea is to actively route Alice to a Man-in-the-Middle (MitM) attacker [3, 72], such that a TLS connection is unknowingly established with the wrong party. From here on the connection

(16)

Alice

MitM

Bob

perceived TLS connection certificate c⁰_bob

1

certificate cbob 2

TLS:

c⁰bob 3

TLS:

cbob 3

Figure 1.2: A perceived TLS connection between Alice and Bob’s e-commerce business can be actively intercepted if a fraudulent certificate c⁰_bob is issued to a MitM attacker.

can be relayed to Bob, without any confidentiality or guarantees of integrity. Considering that this is a shortcoming that stems largely from centralized trust in the CA ecosystem, a significant amount of work exists on the topic. This includes, but is not limited to, approaches that suggest conditional trust [32], decentralized trust [36, 73], verifiable trust [47,48], and trust on first use [22,40,50,76, 49]. A related problem area is certificate revocation: what to do if fraudulent certificates are found or if private keying-material gets stolen [5,46,56].

1.1 Motivation

In order to detect mis-issued certificates retroactively, Laurie et al. [47] proposed an experimental standard that provides Certificate Transparency (CT). CT/bis, a second version of the protocol, also completed the working group last call within the Internet Engineering Task Force (IETF) [48]. The idea is to reject certificates that have yet to be logged in an append-only tamper-evident data structure [12], effectively forcing every client-accepted certificate to be publicly disclosed. Google Chrome already requires that certain certificate types be accompanied by at least two promises of log inclusion, and in the future the plan is to apply a similar criteria for all certificates [44]. Other browser vendors, such as Apple and Mozilla, only support optional forms of CT thus far.

CT is publicly verifiable in the sense that anyone can challenge a log to prove certificate inclusion and log consistency. The former is known as a membership proof, and the latter can be used to verify that version v_i extends version v_j efficiently for i > j (append-only).

At a first glance it may seem as if these cryptographic proofs suffice to distrust a log and

(17)

its operator completely, but additional effort is necessary to detect split-views. That is, in the worst case every CT-aware entity observes a different branch of the log. Fortunately, the notion of a perfect gossip mechanism can solve this issue: each time a log makes a signed statement, such as “x is the next state” or “y is a promise of log inclusion”, then it is instantaneously visible to everyone. While unrealistic, this gives an intuition of what needs to be resembled in the wild to detect misbehaving logs that serve split-views.

The lack of real-world gossip is in part because CT is being deployed incrementally, but also because there are many obstacles to overcome (Section 1.2). It appears that every approach has its own quirks and benefits, and what is applicable for some is not necessarily so for others. Therefore, we expect that the CT ecosystem will deploy several gossip mechanisms that complement each other in the future. This motivates additional research on the topic, and thus the premise of our thesis: gossip below the application layer. The term below the application layer does not mean that we should only consider lower layer protocols, but rather lower layer infrastructure such as packet processors. For example, recent research have resulted in greater programmability for switches and routers. We use this development, exploring a language for Programming Protocol-independent Packet Processors (P4) [6].

1.2 Challenges

First and foremost, CT gossip is complicated due to privacy issues. For example, a history of visited TLS servers can be deduced directly from shared promises of log inclusion, and a client can be fingerprinted by signed log states [58]. Secondly, a gossip candidate must scale to the entire Internet and work in incremental deployment scenarios. Finally, it should not rely on client-to-client communication [10]: decentralized membership management adds complexity [25], but more importantly a legitimate client cannot be distinguished from an adversary. In other words, it is nontrivial to tell if and when an item has been gossiped.

It should be noted that it is the link between an entity and a given gossip message that raises privacy issues; not the message itself. As such, an approach towards CT gossip should

(18)

not expose this link to any additional party. For example, under certain circumstances a promise of log inclusion can be shared with a domain name resolver [45,53] or an originating TLS server [58] without exposing the link to someone new (Section2.5.1).

1.3 Contribution

Our work considers the following research question: what would CT gossip look like below the application layer? As described below, we find that the increasingly flexible packet processing capabilities of switches, routers, middleboxes, and other related networking components may be leveraged for the purpose of CT gossip. Our contributions are:

– Design ideas for passive and active aggregation of gossip below the application layer.

– An outline of available and alternative sources of gossip that a network can process.

– How can and cannot passive aggregation be instantiated using P4, as well as a target-independent reference implementation for one identified plaintext source.

– A discussion regarding deployability, security, related work, and how to move forward.

In summary, we noticed that packet processors can learn a significant amount of data.

Among links, such as who visits whom on the Internet, this includes CT gossip. After proposing a high-level design that evolves around aggregating gossip messages in modern networking infrastructure, we explored a passive approach in an emulated P4-environment experimentally. We identified a number of limitations and restrictions that are P4 specific, e.g., it is hard to aggregate gossip that spans multiple packets at line-speed, but considering that the P4 abstraction is limited—basically an intersection of many different packet processor capabilities—our proof-of-concept is likely extensible to other techniques.

(19)

1.4 Disposition

The remainder of the thesis is structured as follows. Section 2 introduces necessary background and preliminaries, such as programmable networks, cryptographic building blocks, and CT. Section3 gives a high-level overview of our design ideas, namely passive and active aggregation of gossip messages in the network layer. Section4instantiates one of these design ideas in a language for programming protocol-independent packet processors:

P4. Section 5 discusses our method, findings, related, and future work. Finally, Section 6 concludes the thesis, and supplementary material is provided in AppendicesA–B.

(20)

2 Background

Let us start by giving a broad overview of relevant networking protocols and paradigms.

Next, we proceed to describe cryptographic building blocks and relevant security protocols.

Finally, we introduce principles of CT and earlier approaches towards gossip.

2.1 Networking

A computer network is a connected graph of nodes and edges. As such, any pair of nodes can communicate using a protocol that defines the syntax, semantics, and ordering of exchanged messages. For example, the Internet Protocol (IP) suit is used to transfer datagrams between a source and a destination on the Internet: a best-effort packet-switched network of networks [13,62]. This means that a datagram is transmitted by a source without allocating any network resources in advance, and intermediate packet switches forward it based on various header fields. A typical packet switch architecture is shown in Figure 2.1[38], where interfaces (edges) are connected to ports with queues. Based on a routing table that the control plane maintains (slow path), incoming packets are forwarded in the data plane to an outgoing port (fast path). An administrator can configure control plane algorithms and interact with stateful objects using a management plane protocol. Thus, these planes may be thought of as internal, switch-to-switch, and administrator-to-switch communication.

input ports output ports

switch fabric

Data plane Control plane CPU routing table

Figure 2.1: A packet switch has a number of ports that process and queue packets. The next hop is decided based on a routing table, packet header fields, and other metadata.

(21)

A common network abstraction is the Internet protocol stack [38]. It is composed of an application layer (L5), a transport layer (L4), a network layer (L3), a link layer (L2), and a physical layer (L1). The physical layer is responsible of transmitting individual bits that traverse an edge. This is a fundamental building block for the link layer, which groups a collection of bits into a frame. Each edge has a Maximum Transmission Unit (MTU), and it restricts the payload size of a frame: 1500 bytes for standard Ethernet.

Unlike the link layer that transports frames between adjacent nodes, the network layer provides logical communication between devices that speak IP. This is a best-effort delivery service where datagrams may be subject to bit flips, reordering, and loss, e.g., due to transmission interference on the link layer and congestion or routing changes on the network layer. Fortunately higher layer transport protocols can build upon IP to provide enhanced functionalities. For example, it is common to add L4 port numbers for process-to-process communication. Finally, application layer protocols are built on-top of the transport layer to use the Internet for different purposes, e.g., the web, email, and remote host access.

It is not within our scope to give a full networking introduction. In fact, we have already omitted many details. As we proceed to describe protocols that are particularly important in this thesis (Table2.1), a reader with little or no network experience may find the comprehensive work of Kurose and Ross useful “to see the forest through the trees” [38].

2.1.1 Internet Protocols

Considering that a packet parser will be programmed in Section4.3, we need basic knowledge of Internet protocols. We take a bottom-up approach, starting from the network layer with IPv4 [62]. The changes made in IPv6 [13] are mostly irrelevant for the purpose of this thesis, and hence excluded for brevity. Finally, a note on notation: figures that depict protocol headers use a white font for fixed-length fields, while black indicates a variable length.

Figure 2.2 shows an IPv4 header. The version number should be set to 0x4, and ihl

(22)

Table 2.1: Protocols in this thesis, grouped by layers in the Internet protocol stack.

Protocol Layer Category Section

IPv4 L3 unreliable transport 2.1.1 UDP L4 unreliable transport 2.1.1 TCP L4 reliable transport 2.1.1

HTTP L5 web transport 2.1.1

DNS L5 usability 2.1.1

X.509 L5 security 2.3.1

OCSP L5 security 2.3.2

TLS L5 security 2.3.3

CT L5 security 2.4

such that the header length is expressed in multiples of four bytes. Since the fixed portion of the header is twenty bytes, this value must not be less than five. Now recall that a link has an MTU. Therefore, a large IP packet may require fragmentation to fit an L2-frame. A receiver can reassemble a fragmented packet by inspecting identification (equal across all fragments), offset (in the original packet payload, expressed as multiples of eight bytes), and mf (set if more fragments are incoming). A sender can indicate that a packet should be dropped, rather than fragmented, by setting the “don’t fragment” bit (df). In addition, a packet can be dropped if the ttl counter reaches zero (decremented at each hop) or if checksum is invalid (packet header was subject to bit-flips). The protocol field specifies the upper layer protocol in the payload, and the next two words are source and destination IP addresses. Options are optional, but must not exceed 40 bytes: ihl_max is 0xf. Since length is 16 bits, the complete IPv4 packet is also restricted to 65, 535 bytes.

Figure 2.3 shows a User Datagram Protocol (UDP) header [61]. By having source and destination port numbers, logical process-to-process communication can be provided.

For example, a Network Time Protocol (NTP) server process would listen on port 123.

The header also includes the full UDP packet length in bytes, as well as a checksum that covers the payload and various header fields. This means that UDP is a no-frills transaction-oriented connectionless transport layer protocol that extends the unreliable

(23)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

version ihl ... length

identification ... df mf offset

ttl protocol checksum

source destination

options

Figure 2.2: IPv4 packet header (dotted fields excluded for brevity).

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

source destination

length checksum

Figure 2.3: A UDP header specifies a source port, a destination port, a datagram length in bytes, and a checksum that covers the payload plus a number of header fields.

delivery service of IP. UDP is often considered if an application is loss-tolerant, or if it requires low latency, little overhead, and fine-grained control: a packet is transmitted immediately by the sender, notably without any transactional state (best-effort delivery).

Figure2.4shows a Transmission Control Protocol (TCP) header [63]. By setting various flags, a three-way handshake is used to establish a stream-oriented connection between a source and a destination process. The use of sequence-acknowledgement numbers enable detection of and reaction to missing and unordered stream bytes. However, such reliable in-order delivery comes at the cost of state for each and every connection. For example, buffers must be allocated and a segment cannot be discarded until acknowledged by the receiver. Another prevalent feature of TCP is congestion control: the idea is to use all available bandwidth on a path, but without congesting the network or flooding the receiver.

The latter is regulated by the window field, while the former is controlled by limiting the number of unacknowledged bytes. Initially, this is a multiple of the Maximum Segment Size (MSS): the largest TCP segment that a host is willing to accept [1, 9]. IP fragmentation

(24)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

source destination

sequence number acknowledgement number

... flags window

checksum ...

options

Figure 2.4: TCP header (dotted fields excluded for brevity).

can be avoided if a host announces an MSS that is less than or equal to the path’s MTU, subtracted by all IPv4 and TCP header bytes (1460 bytes for Ethernet without options).

Finally, we arrive at an application layer protocol that is largely associated with UDP:

the Domain Name System (DNS) [54, 55]. This is a decentralized database that supports queries and answers on the form shown in Figure2.5. For example, a DNS query of type Address (A) and class Internet (IN) is used to request an IPv4 address for a given domain name: a sequence of labels, such as example and com, delimited by explicit length octets that humans express as dots (i.e., example.com). A following response is expected to echo the question, and if successful one or more resource records are returned in the answer section. The overall message format specifies an identifier, a query kind (opcode), a response status (rcode), a number of questions (QD), a number of answers (AD), and multiple flags.

For example, QR is set for responses, AA for authoritative answers (uncached), and TC if an intermediate middlebox truncated a UDP response that did not fit the next link’s MTU.

The latter could also be due to exceeding the legacy UDP-DNS packet size: 512 bytes.

DNS is used by many applications on the Internet. A notable one is the web, which relies on an American Standard Code for Information Interchange (ASCII) encoded—and thus human-readable—get-response HyperText Transfer (HTTP) protocol to fetch, upload, and modify different types of web objects via TCP port 80 [24]. A web object is identified by a Uniform Resource Locator (URL): a protocol, a domain name, and a local path to

(25)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

identifier

QR opcode AA TC ... rcode QD

AN ...

question section

answer resource record section ...

(a) Structure

0 15

domain name type class

. . .

length data

(b) Resource record

0 15

domain name type class

(c) Question

Figure 2.5: DNS question-response format (dotted fields excluded for brevity).

the object. For example, the three parts ofhttp://example.com/index.html are HTTP, example.com, and index.html. The referenced object can be fetched by composing a GET request: a line with the local object path, a number of headers, an empty line, and an empty body. In response, the following lines would be returned: a status code, a number of headers, an empty line, and a body. A status code of 200 indicates success (object found).

2.1.2 Software Defined Networking

Software Defined Networking (SDN) is a concept that enhances the toolbox of a network administrator [27]. Instead of configuring proprietary packet switches and middleboxes through different narrow interfaces, the idea is to consolidate all control planes into a logically centralized controller that is programmed via a well-defined interface [23]. An SDN-enabled target is initially unprogrammed, but it can ask the controller for instructions at runtime. For example, this could be a question on the form “where should packets with destination Medium Access Control (MAC) address x be forwarded”. The received response is used as a future reference, which means that the controller is not involved for all packets.

Scalability and reliability can also be improved by distributing the controller. Commercially,

(26)

Google showed that this is practical while interconnecting data centers world-wide [34].

A widely supported target-to-controller-interface is OpenFlow [51]. Largely, its success is due to a good balance between programmability and what target vendors are willing to open up: a table of flow-to-action entries, a secure target-to-controller channel, and an interface that allows proprietary internals to be viewed as a black box. Each entry in a flow table has a match key and an associated action. For example, the match type could be exact, the match field a destination MAC address, and the action an outgoing port.

While the basic functionality of OpenFlow has resulted in a large number of innovative applications, it is somewhat limited because the data plane is fixed in advance: a new protocol will not become widely supported before standardization and target support. The latter is a timely process in hardware, e.g., in the range of three to four years. Additionally, in an open source software switch [60], it is complex and expensive to maintain a fork [67].

2.1.3 Data Plane Programmability Using P4

The deficiencies of OpenFlow motivated research on data plane programmability. Briefly, the idea is to allow a programmer to specify the capabilities of a target, e.g., recognized protocol headers, packet (de)parsing, and possible actions, such that a local or an external control plane can use these later on to provide runtime instructions. While we focus on P4 [6], a language for programming protocol-independent packet processors, be aware that data plane programmability is a broader topic than explained here. Moreover, by P4 we refer to the 2014 dialect: P4₁₄. A newer 2016-dialect is available, but it is neither fully nor widely supported by existing targets. Notable improvements include a generalized switch architecture, more expressive language constructs, and an explicit deparser definition.

Figure 2.6 provides a broad overview of P4’s key abstractions. A programmer declares a collection of protocol headers and a finite state machine that creates parsed packet representations. Successfully parsed protocol fields and other metadata are then used as input while traversing a sequence of match-action tables. Supported match types include

(27)

Parser . . .

match-action

Deparser

packet in packet out

Metadata bus

Compiler 1 main.p4 parser tables

deparser

Controller

app 2

runtime

Figure 2.6: A high-level P4 program can be compiled into a target-specific packet (de)parser and a sequence of match-action tables that are populated by the control plane at runtime.

exact (all bits must match) and valid (the header must be parsed). An action could be a compound of P4 primitives, such as popping headers or modifying fields, but it is also possible to use target-specific instructions [69]. Simple stateful objects are also available (registers), which is one of several differences when compared to SDN and OpenFlow. It should be noted that P4 does not specify any runtime behaviour, only data plane capabilities.

Thus, a target’s control plane must populate the defined match-action tables at runtime.¹ A complete P4 program that performs routing based on MAC addresses is shown in Appendix A. First, an incoming packet is parsed by a state machine that extracts an Ethernet header before accepting. Next, a single match-action table named routing is applied in an ingress pipeline of match-action tables. Between ingress and egress, a packet traverses a traffic manager that handles replication, multicast, and queueing (Figure2.7).

This architecture is hard-coded in P4₁₄. Finally, the target’s control plane can specify table entries that result in two different compound actions: do drop or set egress. The former marks that a packet should be dropped, while the latter sets an output port (only applicable for ingress). After traffic management and before deparsing, another sequence of match-action tables may be applied in an egress pipeline (not necessary in our example).

1https://web.archive.org/web/20180107231926/https://p4.org/api/p4-runtime-putting-the- control-plane-in-charge-of-the-forwarding-plane.html(December 2017), accessed January 2018

(28)

Ingress Traffic

manager Egress

Figure 2.7: Between (de)parsing, the P4₁₄ forwarding model assumes an ingress pipeline, a traffic manager, and an egress pipeline. A pipeline is composed of match-action tables.

2.2 Cryptography

Before presenting any security protocol or CT, we need basic knowledge of the following cryptographic building blocks: hash functions, digital signature schemes, and Merkle trees.

2.2.1 Hash Functions

Given an arbitrary input space I and a fixed output space O, a hash function h makes a deterministic projection of i ∈ I to o ∈ O. Typically, the cardinality of I is much larger than O, and collisions are therefore inevitable. In a cryptographic context, it is often required that different types of collisions should be computationally hard to find [2]. For example, preimage resistance requires that it be hard to compute an i ∈ I based on o ∈ O. Similarly, second preimage resistant adds that it should be hard to find a different i⁰ ∈ I that shares the same projection. Finally, collision resistance requires that it be computationally hard to find any i 6= i⁰, such that i, i⁰ ∈ I and h(i) = h(i⁰).² These properties are shown in Figure2.8.

H

?

fixed

(a) Search preimage

H H

fixed ?

h

(b) Search second preimage

H H

? ?

h

(c) Search any collision

Figure 2.8: A cryptographic hash function H is preimage resistant, second preimage resistant, and collision resistant if it is computationally hard to determine any non-trivial input.

2Notice that the brute force effort of finding any collision is much easier due to the birthday paradox.

(29)

2.2.2 Signature Schemes

A digital signature is used to bind a signer’s secret key to a given message. The basic idea is to ensure authenticity, which means that the origin and integrity of a message can be verified with regards to a public verification key. Additionally, a signer cannot deny issuing the signature (non-repudiation). Given a message space and security parameter λ, a digital signature scheme is composed of algorithms for key generation, signing, and verification [26]:

– {sk, vk} ←^$KGen(1^λ): on input of a security parameter λ, it outputs a secret key sk and a verification key vk.

– s ← Sig(sk, m): on input of a secret key sk and a message m, it outputs a signature s.

– {false, true} ← Vf(vk, s, m): on input of a verification key vk, a signature s, and a message m, it outputs true if s is a valid signature for m.

A common security notion for digital signature schemes is existential unforgeability under known message attack. Despite the capability of having any message signed by an oracle O before attempting to break the scheme, it should be computationally hard for an adversary that does not know the secret key to find a valid tuple (s, m) not returned by O.

Computational difficulty in λ is often reduced from mathematically hard problems, such as prime-number factorization or the discrete logarithm problem.

2.2.3 Merkle Trees

The idea of a Merkle tree is to enable aggregation of the tree’s structure and content [52].

This is achieved by hashing every node recursively, from the leaves up to the root, until a single root hash remains. An example is shown in Figure2.9: values are stored and hashed by the leaves, whereas interior nodes hash the concatenation of their children’s hashes. If H is a collision resistant hash function, then a Merkle tree has two important properties: a root hash can be viewed as a unique snapshot of the data structure, and an audit path can

(30)

h³₀← H(h²₀kh²₁)

h²₁← H(h¹₂kh¹₃)

h¹₃← H(h⁰₆kh⁰₇)

h⁰₇← H(z) h⁰₆← H(y)

h¹₂← H(h⁰₄kh⁰₅)

h⁰₅← H(x) h⁰₄← H(w)

h²₀← H(h¹₀kh¹₁)

h¹₁← H(h⁰₂kh⁰₃)

h⁰₃← H(v) h⁰₂← H(u)

h¹₀← H(h⁰₀kh⁰₁)

h⁰₁← H(t) h⁰₀← H(s)

Figure 2.9: Merkle tree with values s–z. The dashed nodes compose an audit path for s, and it is obtained by traversing the tree down to the leaf (select the hash of each sibling).

be generated to prove whether a leaf contains a certain value (dashed nodes). Given a root hash r, an audit path P , and a value v, anyone can reconstruct r⁰ and check if r= r^? ⁰. For further details on how to verify an audit path, refer to the work of Laurie et al. [47, 48].

2.3 Certificates and Transport Security

First the X.509 standard and common certificate types are introduced. These end-entity certificates are presented to clients as certificate chains, and should be rooted in trusted CA certificates. Next certificate revocation is described, and an overview of TLS is provided.

2.3.1 X.509

An X.509 certificate is a digitally signed document that specifies an association between an identity and a public key. It is issued by a trusted CA, who vouches for the validity of given key bindings after performing a number of checks. For example, if an entity can pass a Domain Validation Control (DVC) via email, DNS, or HTTP, a Domain Validated (DV) certificate can be obtained. Other types of X.509 certificates are also available, such as Organization Validation (OV) and Extended Validation (EV). The main difference when compared to DV is that OV and EV requires further investigation after passing a DVC.³

While the syntax and semantics of X.509 are quite complex, it is sufficient to know that an X.509 certificate is basically a sequence of serialized tag-length-value pairs. Some are

3http://web.archive.org/web/20170628142124/https://support.comodo.com/index.php?

/Knowledgebase/Article/View/253/1/what-is-required-for-validation, accessed January 2017

(31)

mandatory, such as version (X.509v3), serial number (unique), and validity period. Others are optional, expressed as extensions that are identified by Object Identifiers (OIDs) [5].

2.3.2 Revocation

If a certificate must be revoked by a CA, e.g., due to mis-issuance or key compromises, this information can be distributed via Certificate Revocation Lists (CRLs) [5]. While it is conceptually simple to maintain a signed list of revoked certificates, it is not necessarily timely and it does not scale well due to a linear growth. Instead, an entity can use the Online Certificate Status Protocol (OCSP) to ask for a certificate’s revocation status: a CA includes an Authority Information Access (AIA) extension during issuance, such that an OCSP responder can be found at an HTTP URL [56]. The request-response format is similar to that of X.509 (serialized), and it is also possible to define new extensions. Notice that OCSP is not privacy friendly for a requester, but if a responder’s signed responses are stapled by a certificate holder it is possible to provide revocation statuses proactively [59].

2.3.3 Transport Layer Security

HTTP over TLS (HTTPS) is a de-facto standard that provides confidentiality, integrity, and replay protection on the web. As shown in Figure 2.10, a handshake is initiated by sending a client hello message which specifies supported TLS versions, accepted cipher suites, and more. In response, a server hello message is returned which negotiates a version, selects a cipher suite, and provides other server-side parameters. Next, a server typically transmits a certificate and a signed key exchange message that proves to the client that the server is authentic. Finally, based on exchanged cryptographic parameters, a shared secret can be derived by both parties. This is used for handshake authentication and encryption.

TLS uses a serialized type-length-value format to encode messages; client and server hello extensions are also supported. For example, a client can specify a Server Name Indication (SNI) extension when visiting a virtual server, and a server can staple OCSP responses. In the stable version of TLS [15], the initial handshake takes place in plaintext.

(32)

TLS client TLS server

Hello, let’s talk TLS. I accept these parameters...

Hi back, alright. Then I choose these...

By the way, here is my certificate And my signed part of the key exchange

Great, here is my key exchange too I’m ready. Verify that all is good Me too. You must also verify that all is good ClientHello

ServerHello Certificate KeyExchange KeyExchange

Finished

Finished protected application data

Figure 2.10: A simplified TLS session.

Consequently, both extensions and certificates are up-for-grabs by traversed targets. As of TLS 1.3, this will change such that nothing but the client-server key exchange is sent in the clear [66]. While TLS 1.3 provides many other new features, these are irrelevant for us.

2.4 Certificate Transparency

The goal of CT is to make all X.509 certificates visible to public scrutiny [47, 48]. This is achieved by mandating that every certificate must be logged in an append-only and cryptographically tamper-evident data structure called a CT log. The cryptographic properties of such a log stem from an append-only Merkle tree, which makes it possible to produce two types of proofs: inclusion and consistency. An inclusion proof consists of an audit path that terminates in a signed root hash (Section2.2.3). Consistency proofs are similar, but include only those hashes that are needed to prove two roots consistent (append-only without tampering).⁴ Anyone can detect mis-issued certificates by observing all logs, and correctness can be verified by querying for certificate inclusion and log consistency.

If we assume that every CT-aware entity observes the same log (perfect gossip mechanism), the result of this public verifiability is that nobody needs to trust a log or its operator.

4If interested, refer to the work of Laurie et al. [47, 48] or Crosby and Wallach [12] for further details.

(33)

Despite a simple idea and strong cryptographic foundation [8, 17], the instantiation of CT is more complicated in practise. For example, there are different types of log entries, signed statements, and policy components. The fact that all issued certificates are publicly disclosed also introduces new problems, such as leaking information about private hosts in a network [21]. However, our scope excludes everything that is not related to gossip.

2.4.1 Log Entries and Signed Statements

A log stores a sequence of entries that anyone can submit. If the issuer of a submitted certificate is recognized, the log returns a cryptographic promise that the entry will be appended to the underlying Merkle tree within a Maximum Merge Delay (MMD). This promise is called a Signed Certificate Timestamp (SCT), and it corresponds to a leaf entry of type X.509 or pre-certificate. A pre-certificate can be viewed as a CA’s intention to issue a given identity-to-key binding: it is possible to reconstruct a pre-certificate from an X.509 certificate chain, and it is useful because returned SCTs can be embedded in the final certificate. A CT-compliant TLS server must provide SCTs in the presented X.509 certificate, a stapled OCSP response, or a TLS handshake extension. Each of these delivery methods are depicted further in Figure2.11, where a comma distinguishes different messages.

TLS server Log

TLS client CA

initiate handshake sct x509;

sct extn;

sct ocsp certificate request, ocsp request

c, sctocsp x509:pre-certificate, ocsp:(pre-)certificate

sct response

extnocsp:issue c all:issue c with sct

extn:c

sct response

Figure 2.11: A TLS server can deliver SCTs using an X.509v3 certificate extension (sct x509), a stapled OCSP response (sct ocsp), or a TLS handshake extension (sct extn).

(34)

In addition to SCTs, logs issue Signed Tree Heads (STHs). The most central part of an STH is its Merkle tree root hash, but it also contains an entry counter, a timestamp, and a digital signature. As such, an STH can be viewed as a snapshot that captures a log’s state at any given time. Proof fetching and gossip is based on observed SCTs and STHs.

2.4.2 Log Interface

Every CT log has a well-known URL. For example, Google’s Rocketeer log can be reached via HTTPS at ct.googleapis.com/rocketeer.⁵ By adding a pre-defined path to the base URL, it is possible to submit (pre-)certificates, fetch the latest STH, challenge the log to prove inclusion or consistency, and more. The response is encoded using JavaScript Object Notation (JSON): a data-interchange format that is easily read and written by humans. As shown for a sample query in Figure2.12, an object is simply a collection of key-value pairs.

1 c u r l h t t p s : // ct . g o o g l e a p i s . com / r o c k e t e e r / ct / v1 / get - sth

2 {

3 " t r e e _ s i z e ": 1 7 5 3 1 1 4 4 1 ,

4 " t i m e s t a m p ": 1 5 1 2 2 9 9 9 9 0 3 7 3 ,

5 " s h a 2 5 6 _ r o o t _ h a s h ": " w o 7 C 1 [ . . . ] B N X k =" ,

6 " t r e e _ h e a d _ s i g n a t u r e ": " B A M A R [ . . . ] L p V p G "

7 }

Figure 2.12: A log serves JSON encoded objects via HTTPS on request.

2.4.3 Status Quo

Despite optional CT support in several browsers, let us focus on the most definite and mature deployment in Google Chrome. At the time of writing, we are still in the first phase of viewing EV certificates as DV unless accompanied by two or more SCTs (one of which must be from a Google-operated log). However, the next phase of mandating that every certificate be publicly logged is right around the corner: it was initially announced for

5https://web.archive.org/web/20171215041903/https://www.certificate-transparency.org/

known-logs, accessed January 2018

(35)

October 2017,⁶ but later postponed until April 2018.⁷ In other words, the current status quo of CT is that Chrome clients require a threshold of SCTs for presented EV certificates.

Unless gossip is deployed in the future, CT does not solve the centralized trust issues of the CA ecosystem. For example, Chrome clients currently trust that logs behave correctly.

Proponents and opponents of CT appear to disagree on the feasibility of real-world gossip.

2.5 Gossip

Disseminating information within a group of members is a classical networking problem.

Seminal papers on the topic date back to the 1950’s, where the effectiveness of different communication patterns were explored in theory and practise [4, 39]. Most of the early work considers a static group of members and optimal message complexities [29], evolving around variations of the gossip problem: all nodes in a complete graph should learn a unique item from every other node. This is also referred to as the telephone problem, in which n entities start with one scandal each and communicate by phone. If n ≥ 4, the communication pattern is set in advance, and all known scandals are exchanged every time without failures, it is possible to achieve an optimal solution of 2(n − 2) phone calls [28].

An early use-case of gossip-based information dissemination in computer science was database synchronization. Since then, a wide variety of application areas were suggested, including distributed data aggregation and wireless sensor networks [35]. While the exact definition and instantiation of gossip can vary, a common denominator is that the group is dynamic and each member selects gossip targets uniformly at random [37]. This requires effective membership management [25], which in itself may be a complex bottleneck of an otherwise simple, scalable, and robust gossip protocol. Probabilistic gossip protocols are said to be scalable because the communication load of individual nodes should be O (log n)

6https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/78N3SMcqUGw/

ykIwHXuqAQAJ(October 2016), accessed January 2018

7https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/sz_3W_xKBNY/

6jq2ghJXBAAJ(April 2017), accessed January 2018

(36)

for groups of n members [14]. Such proactive message redundancy makes the protocol resilient against many types of failures, e.g., lossy links and intermittent nodes.

In this thesis, we consider gossip protocols for CT logs. Our group is heterogeneous and dynamic, consisting of browser agents, command-line utilities (e.g., curl and wget), web servers, third-party auditors, among others. According to the restrictions in Section 1.2,⁸ these entities need to share their views of the logs to each other by gossiping signed log statements. A log statement must be signed to prevent false rumours, but also to hold a misbehaving log accountable. The concept of CT gossip is depicted further in Figure2.13.

A B C

D E

D’ E’

Log:

Subgroup

gossip

Figure 2.13: Gossip can detect logs that present split-views.

2.5.1 Signed Certificate Timestamps

Recall that an SCT is a log’s promise of appending a (pre-)certificate within an MMD. If a TLS client wishes to distrust a log and its operator, an SCT must be gossiped in a raw format or as an STH after being resolved (fetch an inclusion proof). Unfortunately, none of these options are particularly good for a client: a visited server’s subject name can be deduced directly from an SCT. This leaves us with two options: use an anonymity network such as Tor [16], or only interact with entities that know about the visited server already.

CT-over-DNS is a prominent example of how an HTTPS client can ask its DNS resolver to relay a query to the log [45,53]. The idea is that the resolver already translated a server’s domain name to an Internet Protocol (IP) address. Thus, asking for an inclusion proof or an old consistency proof does not necessarily leak any additional information about a client’s visited servers. Google is currently evaluating the impact of using CT-over-DNS [70], but

8No explicit membership management is a notable difference when compared to earlier work on gossip.

(37)

we can conclude already that this approach is not applicable for everyone. For example, the work of Szalachowski and Perrig [74] show that 6.70% of all IN TeXT (TXT) responses which fit within a legacy UDP-DNS packet fail. After setting response body sizes of 1005 bytes and 1997 bytes, the failure rates increase to 18.56% and 49.92%, respectively.

The ongoing work of Nordberg et al. [58] takes a similar approach, permitting clients to share SCTs with originating TLS servers who’s logs already indicate whether a client is a visitor. The idea is to hold on to served SCTs, and submit them repeatedly as SCT feedback on subsequent visits. If a client is subject to a MitM attack that ceases some time in the future, the fraudulent certificate and its SCTs will be provided to the legitimate server. As such, it is up to the server to take further actions: revoke certificates and resolve or gossip SCTs. While a server is not constrained by privacy, it must be modified (quirk).

2.5.2 Signed Tree Heads

A split-view can be detected if CT-aware entities exchange STHs from many different vantage points. However, such STH gossip can occasionally result in privacy issues. For example, suppose that a TLS client receives an historical STH from server A, and shortly thereafter it is shared with server B. If A and B collude, this could be used to track a client cross-origin. Similarly, suppose that every CT-aware entity is served a unique STH. This would permit a log and a number of colluding servers to determine who gossips (or more importantly, who does not gossip). As a final example, suppose that a TLS client is served a hard-coded inclusion proof and an STH x in the presented certificate (recommended in CT/bis). If only a few log entries are associated with x, e.g., due to a small batch where most certificates are revoked, a visited server could be determined with high likelihood.

In order to reduce the ability to track a client through STH gossip, Nordberg et al. [58]

require that an STH must not be shared unless it is less than two weeks old and from a log that announces at most one STH per hour. In other words, per definition the authors consider an STH personally identifiable if there are more than 336 unique STHs in the gossip

(38)

window per log. The idea of their gossip mechanism is to let TLS servers become pools of fresh STHs: the two communicating parties pollinate each other’s windows by exchanging a number of fresh STHs, and periodically or on given events the server hands over these to an external CT auditor who verifies that every view is consistent. The concept of modifying clients and servers (quirk) to engage in STH pollination was initially introduced by Chuat et al. [10]. However, their protocol only gossip the most recently encountered STH, and

involve consistency proofs to reduce the number of log connections (simulated results).

Thus far, we only considered retroactive approaches towards gossip. It is also possible to gossip proactively by co-signing log statements [73]. A challenge with co-signing is that a signing group must be selected and maintained, but if deployed it could give a TLS client immediate feedback that somebody else observed an STH. In some sense, this is similar to Laurie’s idea of announcing every STH in another log: the selected log becomes a witness by issuing an SCT, but without the need of an additional cosigning infrastructure [30].⁹

2.5.3 Trusted Approaches

Nordberg et al. [58] describe several scenarios in which a TLS client may be willing to share SCTs and STHs with a trusted third-party auditor. Although this is generally inapplicable as a solution (give up privacy), it is closely related to last resort auditing: what to do if a misbehaving log refuses to serve an inclusion or consistency proof? For example, manual investigation will most likely be needed to handle persistent issues: query the log from different vantage points, contact the operator, require an explanation, and so forth. This goes far beyond the capabilities of an average user, but given explicit consent it may be reasonable to report potential log misbehaviour to a statically pinned and trusted auditor [40].

Google is looking into an approach towards STH gossip that puts every Chrome client on the same view [70]. This is achieved by pushing the same set of verified STHs down to the clients, who can resolve SCTs to those STHs using CT-over-DNS. In other words, the

9https://mailarchive.ietf.org/arch/msg/trans/7eL7nu3eaAxEf4snLj7w0TUnrwE(January 2017), accessed January 2018

(39)

idea is that Chrome clients are served a consistent view by a shared trusted party (quirk).

For security, it is important that every client gets the same component updater. If gossip works, this can be solved by another transparency application: binary transparency [31,57].

2.6 Summary

At the time of writing, the status quo of CT is to trust that no log presents any split- view. This trust can be eliminated by assuming a perfect gossip mechanism, and reduced by deploying a gossip protocol. Considering that each approach towards gossip has its own quirks, such as requiring server modifications (SCT feedback and STH pollination), additional infrastructure components (STH cosigning), or no privacy (trusted auditor), there is definitely room for improvement and new suggestions. We introduced a significant amount of background to help the reader understand CT and gossip, as well as networking paradigms and protocols that are relevant as we proceed in this thesis. By now the reader should be familiar with the Internet protocol stack, SDN, data plane programmability, cryptographic primitives, certificates, TLS, principles of CT, and earlier work on gossip.

(40)

3 Design Ideas

Consider how a TLS client is interconnected to a TLS server. As shown in Figure 3.1, an access technology connects the communicating parties to a sequence of intermediate networks called Autonomous Systems (ASes) [38]. This setup allows traversed ASes to learn a significant amount of information, both from plaintext protocols and traffic analysis.

While this is a well-known privacy limitation, we suggest that it be used to aggregate gossip passively or actively without exposing a client’s privacy to an additional third-party. In other words, the premise is similar to that of CT-over-DNS and SCT feedback, but with newly identified infrastructure components (e.g., switches, routers, and middleboxes). Let us start by giving an overview of our setting, and then proceed with principles of aggregation.

TLS client

AS1

ASn

TLS server

coaxial cable

fibre optic

. . .

Figure 3.1: A TLS connection traverses a sequence of ASes that different entities control.

3.1 Overview

We leverage that a TLS client must already trust traversed ASes. For example, if a connection traverses an AS that performs pervasive traffic monitoring, sensitive information such as handshakes, IP addresses, port numbers, DNS queries, and OCSP requests can be exposed. Like Nordberg et al. [58], we consider an STH privacy-sensitive if it is personally identifiable: either due to being older than two weeks (unfresh) or because it originates from a log that uses an STH frequency larger than one hour (excessive). A certificate-SCT pair can also be personally identifiable if it is uniquely provided to a client. Therefore, we assume that issuing many certificate chains for tracking purposes would raise suspicion, and that there is only a single SCT for each log entry (implementation dependency).

(41)

As shown in Figure 3.2, we envision that some backbone ASes and large network operators would be willing to provide gossip as-a-service (light yellow packet switches).

In return, a form of herd immunity can be achieved. This means that a large portion of the CT ecosystem gets direct protection from split-views because an aggregating vantage point is available, while those that should be unprotected get indirect immunity unless they can be distinguished from the herd. For security, we rely on the assumption that it is nontrivial for a misbehaving log to bypass all on-path aggregators, e.g., by influencing relevant routing decisions indefinitely and forever. This is not only reasonable because the Internet is decentralized with many different actors, but if an adversary can control the infrastructure to such large extents we suspect that there are greater problems than gossip.

backbone ASes CT logs SCTs

STHs Amazon

Cloudflare

Facebook Google

Universities . ..

Figure 3.2: Network operators and backbone packet processors can aggregate gossip as a service.

3.2 Passive Aggregation

The idea of passive aggregation is as follows: if a gossip message traverses a packet processor in plaintext, it might as well be aggregated to assess whether a log serves a consistent view.

Let us start by describing available and alternative plaintext sources of gossip. Thereafter we introduce aggregation logic that involves little or no collection of personally identifiable data.

(42)

3.2.1 Available Plaintext Sources

Table 3.1 gives an overview of protocols that deliver CT gossip in plaintext. A DNS get-STH response is an IN-class TXT-type resource record where each field in the payload is an ASCII-encoded and dot-delimited field: <size>.<timestamp>.<root>.<signature>.

While an OCSP extension that contains an SCT or a CT/bis object is serialized,¹⁰ the response itself is typically HTTP encapsulated. In contrast, a TLS handshake message that contains a certificate-SCT, an SCT extension, or a CT/bis object extension is fully serialized.

Table 3.1: Protocols that deliver plaintext CT gossip.

protocol version chains SCTs STHs

DNS No TLS 7 7 3

OCSP No TLS 7 3 3

TLS ≤ 1.2 3 3 3

Future adoption of DNS-over-TLS and TLS 1.3 will reduce today’s available plaintext sources. For example, it is not permitted to send unencrypted certificates or hello extensions in TLS 1.3. OCSP could be served over HTTPS if the revocation status of a responder’s certificate is omitted for trusted roots. However, it appears that nobody does it like that.

3.2.2 Alternative Plaintext Sources

Recall from Section2.4.2 that a log’s interface is served over TLS. Perhaps this is unintuitive if we go back to the notion of a perfect gossip mechanism: instead of disclosing SCTs and STHs to public scrutiny, end-to-end encryption hides served views by default. Therefore, let us consider if confidentiality and integrity are necessary for signed log statements:

– Get-STH: given a sound STH frequency, the latest STH is not personally identifiable. It should also be trivial to infer whether a client fetches an STH based on size correlations,

10 A CT/bis object is a TransItem that encapsulates serialized SCTs, STHs, and proofs [48].

(43)

and tampering can be detected because the response payload is signed. In other words, confidentiality and integrity are apparently redundant transport requirements.

– Add pre-certificate: only applicable for CAs. Thus, the removal of confidentiality does not affect client privacy. Tampering of (pre-)certificates and SCTs can also be detected through signature verification. As such, TLS appears to be redundant once again.

– Add certificate: anyone can submit an X.509 certificate. This means that it is harder to evaluate the impact of removing confidentiality. For example, suppose that a TLS client submits presented certificates that have yet to be logged at runtime.

Consequently, an additional side-channel may be created for newly traversed ASes.

Another property that TLS provides is replay protection. This is not important for a (pre-)certificate submission since a log must already handle duplicates, and a response can either be valid or invalid (verified by the receiver). Replayed STHs are more concerning, but it is possible to reason about freshness by inspecting the timestamp.¹¹ Notably a client can distinguish between a misbehaving log and a malicious network if TLS is enabled, but not if it is disabled. However, afterwards it is not possible to convince a third-party of misbehaviour in either case. This means that replay protection serves a limited purpose.

In conclusion, it appears that a log’s get-STH endpoint could be served without TLS.

While this might also be true for (pre-)certificates, it is harder to aggregate these messages for two reasons. First, a connection is not necessarily symmetrical. If only a request or a response is available, a log cannot be held accountable for potential misbehaviour: an SCT cannot be verified without the corresponding (pre-)certificate. Second, SCT-tracking is linear in the number of issued certificates. In contrast, a window of fresh STHs is constantly bound by a log’s announced MMD and STH frequency. An aggregator that observes an additional STH for a given window thus holds a binding proof of log misbehaviour.¹²

11A stricter criteria can be applied in practise: a log must not provide STHs older than an MMD [47,48].

12While a first-generation CT log can announce an STH frequency, it is not mandatory until CT/bis.

Aggregating Certificate Transparency Gossip Using Programmable Packet Processors

Aggregating Certificate Transparency Gossip Using Programmable Packet Processors

Rasmus Dahlberg

Aggregating Certificate Transparency Gossip Using Programmable Packet Processors

Rasmus Dahlberg

Abstract

Acknowledgements

Contents

List of Figures

List of Tables

1 Introduction

1.1 Motivation

1.2 Challenges

1.3 Contribution

1.4 Disposition

2 Background

2.1 Networking

2.2 Cryptography

2.3 Certificates and Transport Security

2.4 Certificate Transparency

2.5 Gossip

2.6 Summary

3 Design Ideas

3.1 Overview

3.2 Passive Aggregation