Perspectives: Improving SSH-Style Host Authentication with Multi-Path Probing
Total Page：16
File Type：pdf, Size：1020Kb
Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing Dan Wendlandt David G. Andersen Adrian Perrig Carnegie Mellon University Abstract Furthermore, a study by Reis et al. used client-side mea- surements to confirm that real-time snooping and modifi- The popularity of “Trust-on-first-use” (Tofu) authentica- cation of web traffic is a reality in today’s networks [20]. tion, used by SSH and HTTPS with self-signed certificates, In this paper, we examine a novel approach to authen- demonstrates significant demand for host authentication ticating a server’s public key. Traditional approaches to that is low-cost and simple to deploy. While Tofu-based server key authentication, such as a public-key infrastruc- applications are a clear improvement over completely inse- ture (PKI) [7, 5], rely on trusted entities (e.g., Verisign) cure protocols, they can leave users vulnerable to even that grant certificates based on the validation of real-world simple network attacks. Our system, PERSPECTIVES, identities. When done securely, such verification requires thwarts many of these attacks by using a collection of “no- significant (often manual) effort. While some network tary” hosts that observes a server’s public key via multiple hosts, primarily commercial websites, can afford to pay network vantage points (detecting localized attacks) and the high verification cost for these certificates, clients have keeps a record of the server’s key over time (recognizing no simple and effective means to authenticate connectivity short-lived attacks). Clients can download these records to most other hosts on the Internet. on-demand and compare them against an unauthenticated Because the high cost of creating and managing a host key, detecting many common attacks. PERSPECTIVES ex- PKI presented a substantial barrier to the replacement plores a promising part of the host authentication design of completely insecure protocols such as telnet, the SSH space: Trust-on-first-use applications gain significant at- model of host authentication emerged as a pragmatic so- tack robustness without sacrificing their ease-of-use. We lution. Authentication in the SSH model relies on the also analyze the security provided by PERSPECTIVES and user’s discretion to decide if an unauthenticated key is describe our experience building and deploying a publicly valid. Keys deemed valid by the client are cached locally available implementation. and used to authenticate subsequent communication with the same server. While some users may verify all new 1 Introduction or changed server public keys in a secure manner (e.g., by memorizing a key fingerprint or verifying the key via an alternate trusted channel), users often simply assume Despite decades of research into techniques for establish- the absence of an adversary on the initial connection and ing secure communication channels for networked applica- accept the initial key without verification. We refer to this tions, many of today’s popular protocols remain vulnerable common approach as Trust-on-first-use (Tofu) authenti- to Man-in-the-Middle (MitM) attacks. Some applications cation (it is also known as “leap-of-faith” authentication). provide no security whatsoever (e.g., HTTP), and others rely on self-signed keys or Diffie-Hellman-like key ex- The Tofu approach has two primary weaknesses: change that can protect against eavesdroppers, but not 1. By accepting any key on the initial connection, users against active adversaries who can interpose on communi- render themselves vulnerable to attack by any adver- cation between the two parties. sary either on the path between the user and the server While MitM attacks are not new, widespread use of or on a shared wireless LAN. shared wireless networks coupled with recent discoveries 2. On subsequent connections, the user must still man- of automated MitM attacks in the wild indicate that the ually determine the validity of any key that conflicts threat is increasingly relevant. For example, the Arpiframe with a cached key. A user who assumes such key worm uses ARP poisoning to interpose on the HTTP traffic changes are valid without verification receives no pro- of other hosts on the same LAN [26], while worms exploit- tection against MitM attacks. ing simple vulnerabilities in home routers exposed end- These weaknesses in the Trust-on-first-use approach are hosts to “drive-by pharming” attacks that use DNS to redi- particularly severe in the case of websites using self-signed rect clients fake versions of security-sensitive websites [9]. SSL certificates, because web clients tend to visit a large USENIX Association USENIX ’08: 2008 USENIX Annual Technical Conference 321 Client connects to service number of sites, increasing the number of vulnerable initial Service responds connections. Moreover, web users often lack the means with public key 1 2 and/or expertise to manually verify keys. Network PERSPECTIVES improves on basic Tofu authentication Service by having a collection of semi-trusted hosts called network Client 3 If offered key is untrusted, notaries periodically probe a large number of network client contacts notary services (e.g., SSH and HTTPS servers) to build a record 5 of the public keys used by those services over time. When a client receives an unauthenticated public key from a Client interprets service, it contacts the notaries to download the history relevant key data and Notary of keys used by that service. This additional data from accepts/rejects key diverse network vantage points over a span of time gives Notary returns records of clients the “perspective” to make a strictly better security 4 key history to the client decision: clients can often detect attacks during an initial connection or a key cache conflict, the two scenarios when Figure 1: Overview of a client using PERSPECTIVES.In the standard Tofu authentication is most vulnerable. practice, several notaries would be contacted in parallel be- fore making a key trust decision. Because notaries generate their data using automated network probes, applications using PERSPECTIVES enjoy the same simplified deployment model as SSH: no certifi- 2 Overview of PERSPECTIVES cate authority is needed to verify the identity of server We name our system PERSPECTIVES because it helps owners and grant them certificates. Instead, the validity clients make sound security decisions by leveraging views of a service’s key is determined by its existence on the from multiple network vantage points. PERSPECTIVES’ network over time. While the notary infrastructure adds task is to help clients determine whether they should ac- some complexity to a Tofu-based application, it exists in- cept an untrusted public key received while connecting dependent of both clients and servers. Servers can remain to a particular network service. Example services include unmodified while updated clients benefit from notary data. SSH access to an end-host or HTTPS access to a website While this paper focuses on protocols that use unauthen- that uses a self-signed SSL certificate. ticated keys (i.e., the SSH model), PERSPECTIVES can PERSPECTIVES uses a set of publicly available servers, also help even when PKI-signed certificates are used. As called network notaries, that monitor and record the his- we discuss in Section 8, because users often ignore browser tory of public keys used by a network service. A notary security warnings [21, 10], a MitM attacker can fool a user cryptographically signs (i.e., notarizes) statements saying by injecting a bogus self-signed certificate in the place of that at time t it observed service S using public key K. The a PKI-signed certificate. PERSPECTIVES clients can eas- basic operation of PERSPECTIVES is shown in Figure 1. ily detect this attack by comparing the received certificate When a client connects to a network service, it receives with those seen by the notaries. an offered key in reply. If the offered key is unauthenti- cated (i.e., it does not match an existing key in the client This paper makes four primary contributions: cache) the client must either accept the offered key, taking a security risk, or reject the key, losing the ability to com- 1. It presents the design of a modular network notary municate with the service. To obtain more information to infrastructure that tolerates internal failures and com- make this decision, the client contacts a set of notaries and promises (Sections 3 and 5). requests all observed key data for that service. The client 2. It describes a framework for (possibly automated) then uses application-specific key-trust policies (Section client policies that aggregate notary replies and deter- 4) to interpret this data and accept or reject the key. These mine if a key is trustworthy (Section 4). policies check for consistency between the offered key 3. It analyzes PERSPECTIVES’s ability to resist a vari- and the keys seen by each notary, often allowing clients to ety of network attacks within a realistic threat model, distinguish between a legitimate key and an attack. demonstrating that it can protect Tofu-based applica- tions from many MitM attacks (Section 6). 4. It describes the implementation and benchmarking 2.1 Threat Model & Attack Resistance of a publicly available release of PERSPECTIVES, in- Attackers mount MitM attacks by providing clients with cluding a robust notary server and modified OpenSSH a false public key in order to observe or modify network and Mozilla Firefox clients capable of implementing communications. In our attack model, an adversary can basic key trust policies (Section 7). compromise any path in the network as well as components 322 USENIX ’08: 2008 USENIX Annual Technical Conference USENIX Association of the notary infrastructure itself. Only the client and Because probing by network notaries does not protect server themselves must be completely trusted, a standard against all possible network attacks, we expect that highly requirement for host authentication schemes.