The Security Architecture of the Chromium Browser

Most current web browsers employ a monolithic architecture
that combines “the user” and “the web” into a single
protection domain. An attacker who exploits an arbitrary
code execution vulnerability in such a browser can steal sensitive
files or install malware. In this paper, we present the
security architecture of Chromium, the open-source browser
upon which Google Chrome is built. Chromium has two
modules in separate protection domains: a browser kernel,
which interacts with the operating system, and a rendering
engine, which runs with restricted privileges in a sandbox.
This architecture helps mitigate high-severity attacks without
sacrificing compatibility with existing web sites. We
define a threat model for browser exploits and evaluate how
the architecture would have mitigated past vulnerabilities.


AES-GCM-SIV: Specification and Analysis

Abstract. In this paper, we describe and analyze the security of the AES-GCM-SIV mode of operation, as defined in the CFRG specification [10]. This mode differs from the original GCM-SIV mode that was designed in [11] in two main aspects. First, the CTR encryption uses a 127-bit pseudo-random counter instead of a 95-bit pseudo-random value concatenated with a 32-bit counter. This construction leads to improved security bounds when encrypting short messages. In addition, a new key derivation function is used for deriving a fresh set of keys for each nonce. This addition allows for encrypting up to 250 messages with the same key, compared to the significant limitation of only 232 messages that were allowed with GCM-SIV (which inherited this same limit from AES-GCM). As a result, the new construction is well suited for real world applications that need a nonce-misuse resistant Authenticated Encryption scheme. We explain the limitations of GCM-SIV, which motivate the new construction, prove the security properties of AES-GCM-SIV, and show how these properties support real usages. Implementations are publicly available in [8]. We remark that AES-GCM-SIV is already integrated into Google’s BoringSSL library [1], and its deployment for ticket encryption in QUIC [16] is underway.


Evolution of high-performance networking in Chromium

After wowing the audience with some surprise sleight-of-hand magic, Jim Roskind of Google gave us a taste of the power of gathering metrics at scale to guide performance engineering. Jim started his talk with an overview of client-side histograms. Histograms in Chromium are super-fast at runtime — a “slow” setup path allocates the histogram buckets and defines their dynamic range, but after setup everything is lock-free and lightning-quick. The framework has a simple developer API for bumping up counters, which lets engineers record metrics with as few as 2-3 lines of code. After an overview of their histogram framework, Jim showed off examples of successful investigations they’ve done into DNS resolution, TCP connection latency, UDP reachability, and the efficacy of FEC. These findings influenced the design of the QUIC network protocol, which is used heavily by Google.

HTTP2 server push: Lower latencies around the world

With HTTP2 push, Facebook has built out a new client/server interaction model, which now makes it possible for the company’s Edge/FBCDN servers to ‘push’ required images and Live streams from the server for a News Feed story or on-going live stream. HTTP2 Server push features are now available to the public. This talk will cover how Facebook leverages HTTP2 to achieve lower latencies.

QUIC @ Google

QUIC is a multiplexed transport protocol running over UDP. It builds on the success of SPDY and HTTP/2 to make the web faster (e.g. improving page load latency, reducing video playback buffering), and to provide a platform for internet-scale experimentation. This talk will give an overview of QUIC, how it’s used today at Google, including deploying QUIC for YouTube video streaming, and what lies ahead.

Picasso: Lightweight Device Class Fingerprinting for Web Clients

In this work we present Picasso: a lightweight device class fingerprinting protocol that allows a server to verify the software and hardware stack of a mobile or desktop client. As an example, Picasso can distinguish between traffic sent by an authentic iPhone running Safari on iOS from an emulator or desktop client spoofing the same configuration. Our fingerprinting scheme builds on unpredictable yet stable noise introduced by a client’s browser, operating system, and graphical stack when rendering HTML5 canvases. Our algorithm is resistant to replay and includes a hardware-bound proof of work that forces a client to expend a configurable amount of CPU and memory to solve challenges. We demonstrate that Picasso can distinguish 52 million Android, iOS, Windows, and OSX clients running a diversity of browsers with 100% accuracy. We discuss applications of Picasso in abuse fighting, including protecting the Play Store or other mobile app marketplaces from inorganic interactions; or identifying login attempts to user accounts from previously unseen device classes.


The Security Impact of HTTPS Interception

Abstract—As HTTPS deployment grows, middlebox and antivirus
products are increasingly intercepting TLS connections to
retain visibility into network traffic. In this work, we present a
comprehensive study on the prevalence and impact of HTTPS interception.
First, we show that web servers can detect interception
by identifying a mismatch between the HTTP User-Agent header
and TLS client behavior. We characterize the TLS handshakes
of major browsers and popular interception products, which
we use to build a set of heuristics to detect interception and
identify the responsible product. We deploy these heuristics at
three large network providers: (1) Mozilla Firefox update servers,
(2) a set of popular e-commerce sites, and (3) the Cloudflare
content distribution network. We find more than an order of
magnitude more interception than previously estimated and with
dramatic impact on connection security. To understand why
security suffers, we investigate popular middleboxes and clientside
security software, finding that nearly all reduce connection
security and many introduce severe vulnerabilities. Drawing on
our measurements, we conclude with a discussion on recent
proposals to safely monitor HTTPS and recommendations for
the security community.