Wsemail: a Retrospective on a System for Secure Internet Messaging Based on Web Services
Total Page:16
File Type:pdf, Size:1020Kb
WSEmail: A Retrospective on a System for Secure Internet Messaging Based on Web Services Michael J. May Kevin D. Lux Kinneret Academic College University of Pennsylvania, Rowan University [email protected] [email protected] Carl A. Gunter University of Illinois Urbana-Champaign [email protected] Abstract 1 Introduction Web services are a mature technology nearing their Web services offer an opportunity to redesign a va- twentieth birthday. They have created the founda- riety of older systems to exploit the advantages of a tion for highly interoperable distributed systems to flexible, extensible, secure set of standards. In this communicate over the Internet using standardized work we revisit WSEmail, a system proposed over protocols (e.g. SOAP, JSON) and security mech- ten years ago to improve email by redesigning it as anisms (e.g. OAuth (IETF RFC 6749), XMLD- a family of web services. WSEmail offers an alterna- SIG [5]). Legacy systems and protocols must be tive vision of how instant messaging and email ser- reevaluated to see how they can benefit from mod- vices could have evolved, offering security, extensi- ern architectures, standards, and tools. As a case bility, and openness in a distributed environment in- study of such an analysis and redesign, we present stead of the hardened walled gardens that today's an expanded study of WSEmail [20], electronic mail rich messaging systems have become. WSEmail's ar- redesigned as a family of web services we first imple- chitecture, especially its automatic plug-in download mented and presented in 2005. feature allows for rich extensions without changing the base protocol or libraries. We demonstrate WSE- Such a return is warranted due to a consideration mail's flexibility using three business use cases: secure of how internet messaging technologies have evolved channel instant messaging, business workflows with in the past decade and a half. When we first im- routed forms, and on-demand attachments. Since plemented WSEmail, email and instant messaging increased flexibility often mitigates against security (IM) services were strictly disjoint. Instant messaging and performance, we designed WSEmail with secu- solutions (e.g. AOL Instant Messenger, ICQ) were rity in mind and formally proved the security of one server centric, offered little to no security, had weak of its core protocols (on-demand attachments) us- authentication, and worked only when both sides arXiv:1908.02108v2 [cs.NI] 12 Dec 2019 ing the TulaFale and ProVerif automated proof tools. were online. Email services were more mature with We provide performance measurements for WSEmail endpoint security and authentication options, but in functions in a prototype we implemented using .NET. order to support uniformity across a vast installed Our experiments show a latency of about a quarter base, the resulting system had shortcomings in the ar- of a second per transaction under load. eas of flexibility, security, and integration with other messaging systems. For instance, problems of remote authentication and extensibility plagued attempts to reduce spam, while poor integration with browsers and operating systems made it a vector for the prop- Keywords Internet electronic mail, web services, agation of viruses, malware, and ransomware. In the WSEmail, security, performance, rich messaging, on- intervening years, IM and email have evolved sepa- demand attachments, email workflow rately. 1 Email has become hardened with the standard- troduction of new security protocols, richer message ization of spam blocking (e.g. real time black hole routing (such as routing based on the semantics of a lists, policy block lists), DomainKeys Identified Mail message), and close integration with diverse forms of (DKIM) (IETF RFC 6376), Domain Name System communication such as IM. Security Extensions (DNSSEC) (IETF RFC 4033- The benefits of flexibility can be validated by show- 5), and encryption by default between Mail Transfer ing diverse applications. We show the flexibility of Agents (MTAs). Together, they made email more se- WSEmail in three applications we implemented based cure in transit and reduced the quantity of received on its framework: secure instant messaging, secure spam. Push notifications changed the speed at which business workflow messaging, and on-demand attach- users see email, but the fundamental message format ments, in which email with an attachment leaves the is unchanged. Importantly, it has remained an open attachment on the sender's server rather than plac- system with distributed management and no central ing it on the servers of the recipients. We achieve point of control. all of this while avoiding becoming a \closed garden" In parallel, IM underwent fundamental changes as by explicitly considering extensibility and on-demand the new generation of tools (e.g. Facebook Mes- download of client extensions. This allows endpoint senger, WhatsApp, Skype, Slack, WeChat) intro- servers to design their own rich messaging extensions duced stronger authentication, end-to-end security, and deploy them locally while maintaining interoper- and rich communications features such as bots, mini- ability with others. applications, and video chat. IM apps cache messages Flexibility, however, often has a high cost for se- sent or received while offline and can show proof of curity and performance. We therefore develop tech- delivery. In contrast to email services, IM networks niques to measure and mitigate these costs for WSE- have become \closed gardens" with little to no inter- mail. WSEmail's first contribution was a case study operability. With few exceptions, access is available of a formal analysis of on-demand attachments. The only via dedicated clients via a central point of con- challenge was to design the security for the attach- trol. Support for offline sending and receiving blur ment based on emerging federated identity systems. the boundary between IM and email, but IM security Due to space restrictions, the proof is not reproduced protocols (e.g. Signal Protocol [12]) are centralized, here, but can be found in Lux et al. [20] and in an on- preventing distributed management and customiza- line appendix (see below). In this work, we first detail tions. No integration with email is possible. WSEmail's architecture and three of its applications. It didn't have to be this way. They show the flexibility we can achieve using our ar- We built WSEmail to replace legacy protocols with chitecture while providing strong security guarantees. protocols based on SOAP, WSDL, XMLDSIG and Second, we carry out a set of experiments to deter- other XML-based formats. The protocols are proven mine the efficiency of our base system, including its technologically (they have been standardized for over security operations. Since email systems need to also 15 years) and they are inherently extensible, give have good performance on older hardware, we show stronger guarantees for message authentication, and our experiments on a testbed built from older hard- are amenable to formal modeling and proof. ware and systems. Both studies demonstrate promise for the security and performance of WSEmail. WSEmail is designed to perform the functions of ordinary email but also enable additional security WSEmail shows an alternative evolutionary path functions and flexibility. The primary strategy is to email and IM could have taken, keeping advantages import these virtues from the standards and devel- from both and giving a path for future growth and opment platforms for web services. Our exploration improvement. of WSEmail is based on a prototype architecture and The paper is organized as follows. First, we implementation. WSEmail messages are SOAP mes- sketch WSEmail's architecture, focusing on its se- sages that use web service security features to sup- curity assumptions and continue with a discussion port integrity, authentication, and access control for about how plug-ins function. Section 3 discusses both end-to-end and hop-by-hop message transmis- interface details of the WSEmail base architecture, sions. The WSEmail platform supports the dynamic including detailed descriptions of how messages are updating of messaging protocols on both client Mail sent and received. Section 4 discusses applications User Agents (MUAs) and server MTAs to enable cus- we have explored with WSEmail, including IM, se- tom communications. This flexibility supports the in- mantic based routing for business workflows, and on- 2 Figure 1: Messaging architecture demand attachments. Section 5 presents our imple- mentation and its performance. Section 6 has re- lated work and compares WSEmail to similar messag- ing systems. Section 7 concludes. Interested readers can find more information in the online appendix at http://www2.kinneret.ac.il/mjmay/wsemail/. 2 Base Architecture Figure 2: WSEmail Deployment Diagram The base protocols for WSEmail are illustrated in Figure 1. In the common case, similar to SMTP, an MUA Sender Client SC1 makes a call on its MTA third tier uses root certificates similar to the ones Sender Server SS to send a message M1. This and in browsers. Overall, this addresses interdomain au- other calls are SOAP calls over TCP; the message M1 thentication in a practical way at the cost of full end- is in the body of the SOAP message and the SOAP to-end confidentiality. Confidentiality is preserved header contains information like the type of call and between hops by TLS or another tunnel protocol. In security parameters. The message is structured as a a basic instance, the message from SC1 to RC will be collection of XML elements, including, for instance, given an XMLDSIG signature by SS that is checked a subject header. A sample trace of WSEmail mes- by both RS and RC. sages can be found in the online appendix. After re- ceiving the call from SC1, the server SS makes a call The novel aspects of WSEmail's architecture are in on the Receiver Server RS to deliver the mail from the integration and flexibility of the MUA authenti- the Sender Domain SD to the Receiver Domain RD.