Showing papers by "Paul Syverson published in 2019"

KIST: Kernel-Informed Socket Transport for Tor

Abstract: Tor’s growing popularity and user diversity has resulted in network performance problems that are not well understood, though performance is understood to be a significant factor in Tor’s security. A large body of work has attempted to solve performance problems without a complete understanding of where congestion occurs in Tor. In this article, we first study congestion in Tor at individual relays as well as along the entire end-to-end Tor path and find that congestion occurs almost exclusively in egress kernel socket buffers. We then analyze Tor’s socket interactions and discover two major contributors to Tor’s congestion: Tor writes sockets sequentially, and Tor writes as much as possible to each socket. To improve Tor’s performance, we design, implement, and test KIST: a new socket management algorithm that uses real-time kernel information to dynamically compute the amount to write to each socket while considering all circuits of all writable sockets when scheduling cells. We find that, in the medians, KIST reduces circuit congestion by more than 30%, reduces network latency by 18%, and increases network throughput by nearly 10%. We also find that client and relay performance with KIST improves as more relays deploy it and as network load and packet loss rates increase. We analyze the security of KIST and find an acceptable performance and security tradeoff, as it does not significantly affect the outcome of well-known latency, throughput, and traffic correlation attacks. KIST has been merged and configured as the default socket scheduling algorithm in Tor version 0.3.2.1-alpha (released September 18, 2017) and became stable in Tor version 0.3.2.9 (released January 9, 2018). While our focus is Tor, our techniques and observations should help analyze and improve overlay and application performance, both for security applications and in general.

Self-Authenticating Traditional Domain Names

Abstract: We introduce Self-Authenticating Traditional (SAT) domain names. SAT domains are traditional recognizable domains resolvable via the Domain Name System (DNS). They are also self-authenticating—they encode in the name itself a public key for authenticating the SAT domain. We present an implementation of our SAT domains for servers and a corresponding Firefox WebExtension that validates connections to them. SAT domains weave security directly into the fabric of the Web by building authentication into URLs themselves. Thus, by simply posting links to other SAT domains, a SAT site that a user trusts assures that user of the ability to make hijack-resistant connections to any of those domains. Because just the address attested in this way is sufficient for users to create a secure connection to a recognizable domain, we call this dirt simple trust. We present implemented examples of this and describe other channels to establish dirt simple trust. The public keys we embed in SAT domain names are in the format of Tor onion service keys. Specifically, a SAT domain includes the encoding of an onion service public key as a subdomain of a registered domain name. But the client can be ignorant of Tor and need not direct traffic over any onion routing network to obtain our protections. This makes SAT domains compatible with other browsers and standard routing infrastructure. Nonetheless, our extension also works in Tor Browser. We also explore systems developed and deployed by others that associate a self-authenticating domain with a traditional DNS domain using existing Web authentication mechanisms, but without building security in directly. Recently, major providers have deployed. onion alternative services to support load balancing and improved performance for Tor users. Though superficially similar to SAT domains, our analysis indicates that these alternative services are not actually self-authenticating. They also increase the effectiveness and impact of client tracking attacks acknowledged in the design of alternative services. We describe such attacks and describe another benefit of our WebExtension: it provides an interface allowing users to selectively block or permit alternative services.