WSEmail: A Retrospective on a System for Secure Internet Messaging Based on Web Services
WWSEmail: A Retrospective on a System for Secure InternetMessaging Based on Web Services
Michael J. MayKinneret Academic [email protected] Kevin D. LuxUniversity of Pennsylvania, Rowan [email protected] A. GunterUniversity of Illinois [email protected]
Abstract
Web services offer an opportunity to redesign a va-riety of older systems to exploit the advantages of aflexible, extensible, secure set of standards. In thiswork we revisit WSEmail, a system proposed overten years ago to improve email by redesigning it asa family of web services. WSEmail offers an alterna-tive vision of how instant messaging and email ser-vices could have evolved, offering security, extensi-bility, and openness in a distributed environment in-stead of the hardened walled gardens that today’srich messaging systems have become. WSEmail’s ar-chitecture, especially its automatic plug-in downloadfeature allows for rich extensions without changingthe base protocol or libraries. We demonstrate WSE-mail’s flexibility using three business use cases: securechannel instant messaging, business workflows withrouted forms, and on-demand attachments. Sinceincreased flexibility often mitigates against securityand performance, we designed WSEmail with secu-rity in mind and formally proved the security of oneof its core protocols (on-demand attachments) us-ing the TulaFale and ProVerif automated proof tools.We provide performance measurements for WSEmailfunctions in a prototype we implemented using .NET.Our experiments show a latency of about a quarterof a second per transaction under load.
Keywords
Internet electronic mail, web services,WSEmail, security, performance, rich messaging, on-demand attachments, email workflow
Web services are a mature technology nearing theirtwentieth birthday. They have created the founda-tion for highly interoperable distributed systems tocommunicate over the Internet using standardizedprotocols ( e.g.
SOAP, JSON) and security mech-anisms ( e.g.
OAuth (IETF RFC 6749), XMLD-SIG [5]). Legacy systems and protocols must bereevaluated to see how they can benefit from mod-ern architectures, standards, and tools. As a casestudy of such an analysis and redesign, we presentan expanded study of WSEmail [20], electronic mailredesigned as a family of web services we first imple-mented and presented in 2005.Such a return is warranted due to a considerationof how internet messaging technologies have evolvedin the past decade and a half. When we first im-plemented WSEmail, email and instant messaging(IM) services were strictly disjoint. Instant messagingsolutions ( e.g.
AOL Instant Messenger, ICQ) wereserver centric, offered little to no security, had weakauthentication, and worked only when both sideswere online. Email services were more mature withendpoint security and authentication options, but inorder to support uniformity across a vast installedbase, the resulting system had shortcomings in the ar-eas of flexibility, security, and integration with othermessaging systems. For instance, problems of remoteauthentication and extensibility plagued attempts toreduce spam, while poor integration with browsersand operating systems made it a vector for the prop-agation of viruses, malware, and ransomware. In theintervening years, IM and email have evolved sepa-rately.1 a r X i v : . [ c s . N I] D ec mail has become hardened with the standard-ization of spam blocking ( e.g. real time black holelists, policy block lists), DomainKeys Identified Mail(DKIM) (IETF RFC 6376), Domain Name SystemSecurity Extensions (DNSSEC) (IETF RFC 4033-5), and encryption by default between Mail TransferAgents (MTAs). Together, they made email more se-cure in transit and reduced the quantity of receivedspam. Push notifications changed the speed at whichusers see email, but the fundamental message formatis unchanged. Importantly, it has remained an opensystem with distributed management and no centralpoint of control.In parallel, IM underwent fundamental changes asthe new generation of tools ( e.g. Facebook Mes-senger, WhatsApp, Skype, Slack, WeChat) intro-duced stronger authentication, end-to-end security,and rich communications features such as bots, mini-applications, and video chat. IM apps cache messagessent or received while offline and can show proof ofdelivery. In contrast to email services, IM networkshave become “closed gardens” with little to no inter-operability. With few exceptions, access is availableonly via dedicated clients via a central point of con-trol. Support for offline sending and receiving blurthe boundary between IM and email, but IM securityprotocols ( e.g.
Signal Protocol [12]) are centralized,preventing distributed management and customiza-tions. No integration with email is possible.It didn’t have to be this way.We built WSEmail to replace legacy protocols withprotocols based on SOAP, WSDL, XMLDSIG andother XML-based formats. The protocols are proventechnologically (they have been standardized for over15 years) and they are inherently extensible, givestronger guarantees for message authentication, andare amenable to formal modeling and proof.WSEmail is designed to perform the functions ofordinary email but also enable additional securityfunctions and flexibility. The primary strategy is toimport these virtues from the standards and devel-opment platforms for web services. Our explorationof WSEmail is based on a prototype architecture andimplementation. WSEmail messages are SOAP mes-sages that use web service security features to sup-port integrity, authentication, and access control forboth end-to-end and hop-by-hop message transmis-sions. The WSEmail platform supports the dynamicupdating of messaging protocols on both client MailUser Agents (MUAs) and server MTAs to enable cus-tom communications. This flexibility supports the in- troduction of new security protocols, richer messagerouting (such as routing based on the semantics of amessage), and close integration with diverse forms ofcommunication such as IM.The benefits of flexibility can be validated by show-ing diverse applications. We show the flexibility ofWSEmail in three applications we implemented basedon its framework: secure instant messaging, securebusiness workflow messaging, and on-demand attach-ments, in which email with an attachment leaves theattachment on the sender’s server rather than plac-ing it on the servers of the recipients. We achieveall of this while avoiding becoming a “closed garden”by explicitly considering extensibility and on-demanddownload of client extensions. This allows endpointservers to design their own rich messaging extensionsand deploy them locally while maintaining interoper-ability with others.Flexibility, however, often has a high cost for se-curity and performance. We therefore develop tech-niques to measure and mitigate these costs for WSE-mail. WSEmail’s first contribution was a case studyof a formal analysis of on-demand attachments. Thechallenge was to design the security for the attach-ment based on emerging federated identity systems.Due to space restrictions, the proof is not reproducedhere, but can be found in Lux et al. [20] and in an on-line appendix (see below). In this work, we first detailWSEmail’s architecture and three of its applications.They show the flexibility we can achieve using our ar-chitecture while providing strong security guarantees.Second, we carry out a set of experiments to deter-mine the efficiency of our base system, including itssecurity operations. Since email systems need to alsohave good performance on older hardware, we showour experiments on a testbed built from older hard-ware and systems. Both studies demonstrate promisefor the security and performance of WSEmail.WSEmail shows an alternative evolutionary pathemail and IM could have taken, keeping advantagesfrom both and giving a path for future growth andimprovement.The paper is organized as follows. First, wesketch WSEmail’s architecture, focusing on its se-curity assumptions and continue with a discussionabout how plug-ins function. Section 3 discussesinterface details of the WSEmail base architecture,including detailed descriptions of how messages aresent and received. Section 4 discusses applicationswe have explored with WSEmail, including IM, se-mantic based routing for business workflows, and on-2igure 1: Messaging architecturedemand 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 readerscan find more information in the online appendix at . The base protocols for WSEmail are illustrated inFigure 1. In the common case, similar to SMTP, anMUA Sender Client SC makes a call on its MTASender Server SS to send a message M . This andother calls are SOAP calls over TCP; the message M is in the body of the SOAP message and the SOAPheader contains information like the type of call andsecurity parameters. The message is structured as acollection of XML elements, including, for instance,a subject header. A sample trace of WSEmail mes-sages can be found in the online appendix. After re-ceiving the call from SC , the server SS makes a callon the Receiver Server RS to deliver the mail fromthe Sender Domain SD to the Receiver Domain RD .The Receiver Client RC makes calls to RS to inquireabout new messages or download message bodies. Inparticular, RC makes a call to RS to obtain messageheaders and then can request M .The deployment diagram for WSEmail’s client andserver and the associated nodes they use is shown inFigure 2. Security Architecture
Our design is based on athree-tier authentication system combined with anextensible system of federated identities. The firsttier provides user (MUA) authentication based onpasswords, public keys, or federated identity tokens.The second tier provides server (MTA) authentica-tion based on public keys with certificates similar tothose used for Transport Layer Security (TLS). The Figure 2: WSEmail Deployment Diagramthird tier uses root certificates similar to the onesin browsers. Overall, this addresses interdomain au-thentication in a practical way at the cost of full end-to-end confidentiality. Confidentiality is preservedbetween hops by TLS or another tunnel protocol. Ina basic instance, the message from SC to RC will begiven an XMLDSIG signature by SS that is checkedby both RS and RC .The novel aspects of WSEmail’s architecture are inthe integration and flexibility of the MUA authenti-cation and the ability of both MUAs and MTAs toadd new security functions dynamically. To illustratea variation in the base protocol, consider our designfor IM. Referring again to Figure 1, an instant mes-sage M is dispatched from a client SC to RC while SC is outside its home domain SD . In this case SC contacts SS to obtain a security token T that willbe recognized by RS . Once it is obtained, SC sends M authenticated with the credential to RS and indi-cates (in a SOAP header) that it should be treated asan instant message by RS and RC . Instant messagesare posted directly to the client, with the client nowviewed as a server that accepts the instant messagecall. RS and RC are able to apply access control forthis function based on the security token from SC .The token is recognized because of a prior arrange-ment between SS and RS .3igure 3: Component diagram for WSEmail client, server, and associated services. The plugins are elaboratedon in Figure 4 4 lug-ins The WSEmail MUA and MTA are basedon a plug-in architecture capable of dynamic exten-sions. Security for such extensions is provided thougha policy for trusted sources and the enforcementmechanisms provided by web services. On-demandattachments are an example of such a plug-in, as area variety of kinds of attachments with special seman-tics. A party that sends a message with such an at-tachment automatically includes information for thereceiver about where to obtain the software neces-sary to process the attachment. The client provideshooks for plug-ins to access security tokens, after firstperforming an access control check on the plug-in.
Composite Architecture
The composite archi-tecture for the MUA (client) and server (MTA) isshown in Figure 3. The server components shownperform the following tasks.
Database Manager
Provides access to thedatabase for message storage and retrieval.
DNS Resolver
Provides an interface to the DNSsystem.
Plug-ins Manager
Allows for increased functional-ity without changing the base server code. Wedetail how they work in Section 3.1 below.
Message Queue
Queues messages for local and re-mote delivery.
Local MTA
Serializes messages to a local data store( e.g. saving to a spool file).
To explain WSEmail’s architecture, we outline itscode and plug-in architecture and interfaces. Theinterfaces describe how much access the applicationhas to the mail server or client software, in additionto where the plug-in is activated for message deliveryor reading. Plug-ins are used on both the server andthe client.
Server plug-ins are code libraries that conform to in-terfaces known to the server. When the server is ini-tialized, it goes through a list of plug-ins to load froma configuration file. For each plug-in, an object classis listed along with the name of a library from whichit can be loaded. The server looks for the library and tries to instantiate and load the object. If successful,the server requests further configuration data fromthe plug-in and uses it to put the plug-in in the ap-propriate execution queue. The process of loading orunloading plug-ins is dynamic; they can be loaded orunloaded at any time during execution. The execu-tion queues can also be reprioritized or disabled atrun time.All server plug-ins implement the IServerPlugin in-terface, which allows the server to understand theplug-in’s purpose and add it to the appropriate pro-cessing queues. There are two main classes of plug-ins in WSEmail: message dependent and RPC-like(or message-independent). The component diagramfor some example plug-ins is shown in Figure 4.Figure 4: Component diagram for some exampleplug-ins.Message dependent plug-ins require that a messagebe present to execute. They can be inserted in var-ious places in the delivery cycle, including at initialreceipt of a message (ISendingProcessor) or at thefinal destination of a message (IDeliveryProcessor).ISendingProcessor plug-ins perform processing sim-ilar to that done by sendmail ( e.g. verifying relaypermissions, stripping oversized attachments) in reg-ular email systems. IDeliveryProcessor plug-ins actsimilar to user-space programs such as procmail orvacation messaging scripts in regular email systems.Figure 5 shows the interactions and data flow of in-coming WSEmail and extension requests.RPC-like plug-ins implement a generic “catch-all”5igure 5: An overview of server-side plug-insinterface (IExtensionProcessor). On initializing, theplug-ins provide the server with an extension identi-fier . It is used by the server to route incoming re-quests to the appropriate plug-in. There is no re-quired or defined structure for the requests. Mostplug-ins view requests as just XML documents orfragments, providing flexibility in terms of the dataan application can process.The server plug-ins are run after the core serverhas performed message authentication. The serverauthenticates a message by examining its attachedsecurity tokens such as X.509 certificates, usernamesignatures, or federated identity certificates. If theyare valid, the message is entered into a queue to beprocessed by the appropriate plug-ins. In the caseof IExtensionProcessor and IDeliveryProcessor plug-ins, an “environment” object is created and passed tothe plug-in to allow access to authentication tokensand raw XML streams from the server. Other plug-ins are only given the message that triggered theirexecution.Plug-ins can implement more than one interface,which can increase functionality. Some plug-ins are composite , implementing both IExtensionProcessorand IDeliveryProcessor (or any variant), allowingthem to interact with messages as they are deliv-ered, but also to be configurable using a protocolthat interacts with the IExtensionProcessor interface.Implementing multiple interfaces allows plug-ins toshare data that should be accessible through multiplepaths. Section 4 shows examples of useful compositeplug-ins.We implemented some server plug-ins in WSE-mail that would be typical for enterprise applica-tions: data store access (IDataAccessor), databaseconnection management (IDatabaseManager) mes-sage queues (IMailQueue), and local delivery (ILo-calMTA).
Client-side plug-ins affect message reading and aremore dynamic than server-side plug-ins. Like server-side plug-ins, client-side plug-ins are code libraries,but for ease of implementation extend an abstractclass (DynamicForms.BaseObject) instead of imple-menting an interface. They contain more informa-tion than server-side ones, including version and net-work location information. With the additional in-formation, a plug-in can create messages that canbe processed by clients that do not have the plug-in installed. This is accomplished by having a stubexecuted by the receiving client download the plug-in from its supplied network location (after user ap-proval). Plug-in code is self-signed using MicrosoftAuthenticode. Plug-in information ( i.e. version,name, library location) is saved in a local registryto let the recipient use the plug-in again later.A plug-in’s user interface is up to the plug-in de-signer. A plug-in can have no interface at all, afew message boxes, or a rich GUI. Since WSEmail isbased on the .NET framework, plug-in designers canuse .NET’s UI elements without the need to transferadditional graphics libraries. A sample plug-in inter-face is shown in Figure 6. Plug-ins also have accessto authentication information in the mail client andmay petition users for access to their federated to-ken. This allows plug-ins to perform secure web ser-vice calls to perform functions such as automaticallyfilling in information.Multiple plug-ins can be contained within one li-brary file. Each plug-in will be enumerated (via.NET’s reflection libraries) and registered with theclient application. This allows system administratorsto deploy one library with updated plug-ins insteadof deploying each one separately.
When Alice wants to send a message to Bob that usesa plug-in, she attaches a “form” from her registry toher message (Figure 7). The form presents Alice witha user interface to fill in relevant information. Af-ter filling out the form, the information is serializedto an XML document and attached to the message.The original message is notified by the plug-in whereit should be sent next to be appropriately processed;in this case, Bob’s inbox. The plug-in is unloadedand a flag is set on the message header indicatingthe presence of a form. The flag is displayed in Al-ice’s list of sent messages and Bob’s inbox on receipt,6igure 6: Sample application (a timesheet)allowing them to see which messages in their inboxcontain forms without needing to download all of themessage’s contents (see Figure 8). Figure 9 illustratesthe process.When Bob’s server receives Alice’s message, he seesthe new message appear in his inbox with an anno-tation indicating the message contains an attachedform. He can view the message normally, but canalso view the attached form. When Bob tries to viewthe form, the mail client attempts to load the ap-propriate plug-in or download it if it’s not alreadypresent using information contained in the recipient’splug-in registry and information in the form. Afterthe plug-in is loaded, the XML document containingthe payload of the form is pushed to the plug-in thatdeserializes the data and loads necessary state. Theplug-in then takes control, displaying a GUI that in-cludes the information Alice sent. Figure 10 demon-strates the typical flow for the recipient of a messagewith a form attached.
WSEmail allows rich XML formats, extensible se-mantics on clients and routers, and a range of secu-rity tokens. Since there are substantial development Figure 7: New message screenFigure 8: Inbox screenplatforms for these features from software vendors, wecan use WSEmail as a foundation for a suite of inte-grated applications that share common code, routing,security, and other features. To illustrate, we sketchthree applications that we implemented with our pro-totype system. They are examples of a way forwardthat integrates email and IM and improves securityand flexibility while avoiding the pitfalls of becominga walled garden.
IM is a messaging technique like email, but isintended for communicating short messages syn-chronously. An overview of a standard IM architec-ture is shown in Figure 11. IM is typically disjoint7igure 9: Client-side plug-ins from the sender’s per-spectiveFigure 10: Client-side plug-ins from the recipient’sperspectivefrom email, using different clients, servers, routing,and security. This is unfortunate since the two mes-saging systems have many things in common. Weexperimented with integrating the two by allowingWSEmails to be marked as instant messages (see Fig-ure 7). Such messages are posted directly to a win-dow on the recipient client by the client server (seeFigure 12), subject to an access control decision. Ourimplementation uses the same client, server, software,and security as the email functions. There is an op-tion that allows multiple parties to use TLS tunnelsto a single server.WSEmail’s IM plug-in is a composite plug-in, im-plementing IDeliveryProcessor and IExtensionPro-cessor. When the IM client program is started, theuser automatically registers her location on the serverusing the IExtensionProcessor interface. The plug-inrecords the location information in an internal table.Later, when the server receives a message flagged asan instant message, it passes delivery control of themessage to the instant messaging plug-in using theIDeliveryProcessor interface. The plug-in consults itstable of user locations and sends the message directlyto the client if it finds a match. If no match is found,the plug-in relinquishes control of the message, pass-ing it back to the server. The server can then attemptdelivery using a different matching plug-in.Instant messages are sent to clients using Microsoft Figure 11: Instant Messaging OverviewFigure 12: Instant Messaging screen.NET Remoting (now superseded by Windows Com-munication Foundation). Similar to Java’s RMI, Re-moting allows an object to be distributed across anetwork. Clients remote their IM queues and have aseparate thread watch it. As the server pushes mes-sages into the queue, the client watcher thread pullsthem out and displays them in a conversation-like in-terface.After a conversation has been established, userscan change to a synchronous channel. An additionalserver-side plug-in coordinates the shift from asyn-chronous WSEmail messages to a “party line” se-cured with TLS. At the user’s request, the plug-inallocates a TCP port running TLS and notifies allparticipants in the conversation of the available chan-nel. The TLS ports do not have to be opened on themail server, so it is possible for the mail server to actas a broker and pass the connection request on to asecure chat server farm. The recipients of the invita-tions are given a choice to accept the channel conver-sion. When connecting to the secure chat server, theclients are presented with the server’s X.509 certifi-cate and are asked to present their own certificates forauthentication. Clients who do not provide a certifi-8ate are not able to join the new secured chat session.The secure channel instant message brokering al-lows users to create secure channels with arbitrarygroups of people. Since the messaging flows over theTLS channel, they do not have the lag of the com-position and forwarding of a WSEmail message. Ifthe users have an existing X.509 architecture, theycan easily authenticate to each other. If they lacka shared X.509 architecture, everyone (including theserver) will need to set up certificate trust relation-ships.
Many organizations carry out their business processworkflows ( i.e. forms) using web forms or other webtechniques. In implementing such a system, there isa choice between a centralized system where a singleweb server is used by everyone and a decentralizedsystem where information is routed by email. Emailsystems work best with loosely described workflowsand loosely coupled participants, such as ad hoc col-laborations between enterprises where neither orga-nization can carry out all functions on a web servermanaged by the other party.WSEmail supports workflow management usingrouted forms, attachments that are sent to particu-lar people or roles in a specified order. Routed formsuse client-side plug-ins to create a rich user inter-face. The forms are designed to look like their papercounterparts. We created prototypes for time sheets(Figure 6) and requisition forms, including an inter-face to enter the required data and rules that specifywhich roles in the organization must “sign off” to ap-prove a form. A sample workflow scenario of a formthat must be passed through a chain of recipients toreceive final approval is shown in Figure 13.The sender follows the steps described in Sec-tion 3.3. In our prototype, the forms are muchsmarter than their paper counterparts. They can,for example, provide basic spreadsheet-like function-ality or automatically populate data using the user’sfederated token and a secure web service query to ahuman resources database. To address the securityof the workflow, each user has a unique X.509 cer-tificate with the certificate’s common name (CN) asthe user’s email address. A person in the workflowsigns off on the form by attaching a digital signa-ture to the XML. The message thereby acquires anapproval list that can be verified and audited by athird party. The verifier can use X.509 certificates tocheck that the data have not been tampered with and can authenticate the approval of each member in theworkflow.As an extension of the workflow model, users candelegate their responsibilities. Delegation is done bya user providing the name or names of people whocan sign off on a form instead of him. This adds apowerful automation feature. Using server-side plug-ins, a form can be received by a program that makesdecisions about delegation given the current approvallist and data in the form. A common business processthat could use such a feature is a requisition form. Forexample, a department may be allowed to buy itemsunder a certain fixed price, but if the total price isgreater than a certain amount, additional approvalby a member of the purchasing department might berequired. A requisition workflow program could eas-ily detect this condition and expedite the purchaseprocess by automatically forwarding the form to peo-ple who can approve the purchase or to people towhom they have delegated their responsibility.Figure 13: Sample Workflow ScenarioA workflow in our system can send its result toanother program. The receiving program could thenvalidate the entire form and perform the required op-erations ( e.g. file an order, perform database ma-nipulations). With an increasing number of onlineretailers exposing their order processes as web ser-vices, it is possible to automate more business func-tions end-to-end within a common application suchas WSEmail.Because WSEmail also functions as a decentralized9ystem, a workflow form can extend across multi-ple enterprises. All of the enterprises in the work-flow would need to have an agreement to trust acommon certification authority (CA) or cross-trusteach other, but that is the only additional configura-tion that is needed. With that setup, they can userouted forms in WSEmail to create multi-enterpriseprocesses. There are many applications that coulduse such a setup such as negotiating prices with asupplier or gathering approvals for press releases frominterdependent corporations. Since the data are con-tained within the email message, the question of whohosts the data and applications for the exchange iseliminated. WSEmail sends the data wherever nec-essary.
Attaching files to email is a simple and convenientway to send files to a group. However, there aremany problems with email attachments that WSE-mail sought to improve. For instance, except for cer-tain proprietary email systems, there is no versioncontrol system for email attachments, which usuallyresults in many message resends so that each persongets the newest version of a file. Second, the way at-tachments are bundled in POP3 (IETF RFC 1939)requires users to download the entire message andattachments, even if the user only wants to read themessage (a problem solved in IMAP4 (IETF RFC3501) and critical to bandwidth and power limiteddevices). A common solution is to post the attach-ment on a secured cloud-hosted website and to send alink in the message to it. Unfortunately, this createsan administrative and security headache since attach-ments are stored on third-party servers and sendersmust set up access control rules and authenticationon an external server or for recipients who are not intheir administrative domain.WSEmail solves the problem by introducing theconcept of “on-demand” attachments. Simply, mes-sage attachments are handled as a plug-in to theWSEmail base protocols. The plug-in is composite,implementing both IExtensionProcessor and ISend-ingProcessor. The client creates a message that con-tains information about the attachment such as itssize, description and a SHA1 hash in addition to thenormal message fields. The request to the server con-tains the message as normal, along with the attach-ments using a binary encoding format. When themessage is received by the server, the request is inter-cepted by the “on-demand” plug-in using the ISend- Figure 14: On Demand Attachments ProtocolingProcessor interface. The plug-in gains access tothe binary encoded attachments in the requests. Theattachments are stripped from the request and savedto a database along with a list of all the recipients.
Globally Unique Identifiers (GUIDs) are generatedand injected in to the original message such that eachGUID relates to one of the binary encoded attach-ments. Delivery of the message now continues nor-mally.A user who receives a copy of the message will seethat a file is attached, but will not have a copy of ityet. The user just has the GUID for the file and thelocation from which it can be obtained. If the userdecides to retrieve the attachment, she first acquiresa federated identity token from her server. The tokenis presented using the IExtensionProcessor interfaceto the server that originally stripped the attachmentalong with the GUID. The server verifies the authen-ticity of the token and that the supplied user’s tokenis permitted access to the GUID. If there is a match,the server sends the attachment back to the requestoras a binary encoded attachment. An overview of theprotocol is shown in Figure 14.We specified the on-demand attachments proto-col formally using the TulaFale [7] specification lan-guage, which has constructs for public key signaturesand salted password authentication. The TulaFalescript compiles to a script that is verifiable with theProVerif protocol verifier of Bruno Blanchet (version1.11) [9]. With this we were able to prove the follow-10ng correspondence theorem for on-demand attach-ments: if a receiving client (RC) retrieves an on-demand attachment with SC (sending client) as itsreturn address, then SC sent the attachment . De-tails of the proof and its construction can be foundin Lux et al. [20] and in the online appendix.
SOAP web services have been criticized for being slowdue to their verbose XML formats and implementa-tion decisions [23]. Security and flexibility sometimeslead to performance challenges as well. Hence a se-cure, flexible implementation of messaging based onweb services may raise concerns about throughputand bandwidth utilization. We tested our WSEmailprototype to investigate these concerns and to illus-trate the benefits of flexibility. To evaluate efficiency,we built a test bed to stress test the client and serverapplications and their communication protocols. Inthis section we describe the implementation, test bed,and experimental results.Our code can be downloaded from https://github.com/lux-k/wsemail .We simulated an email environment where manyusers share an email server. They can send messagesto others in the local domain or in an external do-main. A user may also interact with her inbox, view-ing and deleting messages. For our test, we definedfour standard email operations: send, list, retrieve,and delete as we discuss below.
Our WSEmail prototype runs on Windows server andclient systems. Version 1.0 was implemented on the.NET framework version 1.1 and relies on the WebServices Enhancement (WSE) 1.0, CAPICOM 2.00,SQL Server 2000 (to store server messages), and IIS5.0. The current version consists of 68 interfacesand 343 classes organized into 30 projects (see Ap-pendix A for UML models). Most of the software isC mentalis.org ) since the .NET 1.1 platform doesnot provide native support for server TLS sockets.In 2004, we upgraded WSEmail to version 1.1 to getWS-Policy [4] support from Microsoft WSE 2.0. WSEmail uses DNS SRV records (IETF RFC 2782)to determine routing. This lets us run WSEmail overother protocols without changing the way DNS isqueried. We can also exploit the priority and weightattributes in the records. The properties of SRVrecords allow for future enhancement and present-day configuration that is similar to how SMTP is de-ployed.
Our test bed consisted of four clients, two mail servers(designated local and external), one test coordinator,and one database/DNS server. The arrangement ofthe test bed is shown in Figure 15.The test clients (T1–T4) performed operations bysending requests to the “local” email server, S i . Thetest client actions were coordinated by the test co-ordinator, S tc . There was a second server, S e , thatacted as both the “external” email server and a loadgenerator for the “local” system. S db hosted a mes-sage storage database and DNS records for S i and S e . The clients all had Pentium 4 2.8GHz processorswith 512MB of memory and Windows XP Profes-sional. They performed four operations during thetest execution: (1) send a message to a recipient, (2)list the headers of messages in the client’s inbox, (3)retrieve a message, (4) delete a message.The test coordinator, S tc , was responsible for dis-tributing the test specifications, starting the test, andreceiving results from each client. S tc broadcastedits network address, instructing all clients to connectto it and download the test specifications file. Theclients then waited for S tc to announce the start ofthe test, after which the clients executed requests to S i in compliance with the specifications. After eachclient finished, the latencies for each request were re-ported to S tc .The test specifications document described exactlywhat each client should do. It specified whether theclient should authenticate using a username token(user name and password) or X.509 certificate. Italso specified how many messages to send from theclient, to whom they were to be sent, and the size ofthe message body. The specification document alsoindicated the total number of requests to send andthe ratios of the four types of requests.The local server S i was the focus of our test. Itaccepted incoming messages from the clients and S e .It performed the necessary authentication and for-warded external messages to the appropriate desti-nation after performing DNS resolution. If the des-11igure 15: Testbed Architecturetination was local ( i.e. the recipient was on S i ), themessage was stored in S db . If the destination was ex-ternal, the message was forwarded to S e . We allowedthe local and external server to share a database andDNS server since they were not performance bottle-necks in the system. S e played two roles in our test bed. First, it imi-tated the entire external client list, so all emails di-rected to any external client were forwarded to it. Onreceiving a message addressed to one of the clientsthat it simulated, it did not save it to the databaseserver. We did this to prevent S i from experienc-ing extra latency due to S e ’s database transaction.Rather, it performed the required certificate check-ing to verify authenticity and then discarded the mes-sage. Second, it acted as a load generator and sentone message per second addressed to each of the fourclients, T1–T4. The messages were all received by S i ,authenticated, and stored in S db . The test coordinator S tc provided a test specifica-tion document that instructed each client to run oneexecution thread sending 2,000 requests to S i . Theclients chose send, list, retrieve, and delete operationswith 25% chance. In cases where the delete operationwas to be performed on an unpopulated inbox, it wasconsidered a no-op and not counted towards the re-sults. To avoid this condition, each client’s inbox wasprimed with about six messages. To get the most outof each send event, each message was addressed toboth a randomly chosen local client and an external client. The clients were all instructed to authenti-cate to S i using username token authentication. S i and S e authenticated to each other using X.509 cer-tificate signing. The duration of the test was 1830seconds.To get a client-side view of the efficiency of thesystem, we measured the latency of each request. Atimer was started as the client contacted S i with arequest and stopped after the client received the ap-propriate response ( e.g. inbox listing, message re-ceived confirmation). The time difference betweenthe client’s request and the server’s complete responsewas the latency of the operation. The results of thiscalculation were an average of 284 ms per requestwith a variance of 138.9 ms. The minimum and themaximum latencies were 46.876 ms and 4,000 ms (4s) respectively. Note that the message received con-firmation does not mean that the message was deliv-ered to the final recipient, just that the message wasplaced in the delivery queue.The test results in Table 1 show the data volume(in MB) sent between the clients and S i broken downby email operation. The total data sent from theclients to S i was 25.98 MB and from S i to all clients155.22 MB.Since each message was also sent to an externalclient, each send action also sent a message from S i to S e . The data sent from S i to S e are summarizedin Table 2. The total data sent from S i to S e was33.74 MB and from S e to S i was 31.55 MB.The test bed data transfer was recorded usingserver-side network monitor tools run at S i and S e .The TCP sessions were reconstructed using tcpflow12able 1: Data volume sent between clients and S i Operation Send List Retrieve Delete → ServerData (MB) 8.31 5.83 5.99 5.85Server → ClientData (MB) 4.06 127 20.33 3.83Table 2: Data volume sent between S i and S e Server S i S e https://github.com/simsong/tcpflow ) and pro-cessed with awk and Perl. Since S e , acting as aload generator, sent one message per second, 1830messages were sent from S e to S i during the test.The corresponding byte count represents the mes-sages that were sent and the notification messagesthat were received. A best-case test of SMTP with no load on the serveror network and no contention for resources yieldedan average latency of 170 ms to send a message ofabout the same size as the WSEmail messages wesent in our experiment. The average difference in la-tency between WSEmail and the SMTP test is 114ms, which accounts for the additional overhead of theXML parsing and cryptography. In that time spana large number of operations took place: one secretkey signature, one private key signature verification,two public key signatures, and one public key signa-ture verification. Since the entire system uses XML,we conclude that performance is not a barrier to se-cure web services in this type of application. Theextra latency would likely be unnoticeable a typicalclient/server environment.XML and XMLDSIG have drawbacks due to theirverbosity. Our test bed sent 1 KB mail messages thatballooned to 10 KB responses to the retrieve messageaction to make XMLDSIG work. At least 30% ofthose bytes were the Base64 encoded representations of the certificates used for signing messages. Afterthe certificate size, the WS-Security [21] structureswere a significant amount of overhead, accounting forabout 30% of the bytes. The overhead could be re-duced by using an alternative certificate distributionmechanism or via techniques to reduce SOAP’s over-head [24].Our experiments bode well for web service effi-ciency, especially for high volume messaging. Ex-tending our experimental results, WSEmail is theo-retically capable of handling approximately 1787 mes-sages a minute (combination of incoming and outgo-ing). We looked for published benchmarks to com-pare this against and found that the University ofWisconsin-Parkside had a peak usage of 1716 (to-tal of incoming and outgoing) messages per minutein 2005, meaning it should be possible for a singleWSEmail server similar to our test system to handlethe normal load at that institution.
Work related to WSEmail can be divided into threegeneral areas: email improvements, analysis of webservice security, and improved rich internet messagingsystems.
Email Improvements
Improvements to theSMTP messaging system have been motivated bytwo, sometimes overlapping goals: strong messageauthentication and spam prevention. PGP offersauthentication tools that include public/privatekey signing and encryption. Privacy EnhancedMail (PEM) (IETF RFCs 1421–4) has mechanismsfor privacy, integrity, source authentication, andnonrepudiation using public and private key encryp-tion and end-to-end encryption. Zhou et al. [28]use formal tools to verify the properties of PEM.Abadi et al. [1] use a trusted third party to achievemessage and source authentication and formallyprove correctness of their messaging protocol.Changes to the SMTP system aimed at spam re-duction include DomainKeys Identified Mail (DKIM)(IETF RFC 6376) that uses public key cryptogra-phy and an option for server signed (rather thanclient-signed) messages and Petmail [26]( http://petmail.lothar.com/ ). Petmail uses the GPG en-cryption utility for public key encryption and signingof messages. Users are identified by IDRecords, self-13igned binary blobs that include public key, identity,and message routing information. Petmail agents canenforce IDRecord whitelists and policies for contactfrom first time senders. First-time senders may beforced to obtain tickets from a third-party TicketServer that may check to ensure that the sender isa human (using CAPTCHA reverse Turing tests).Messages can be encapsulated and sent using SMTP,Jabber, or another queuing transport protocol. Pat-terns and options for sender anonymity are offered aswell. Our most recent work on extensions of WSE-mail show how to match some of Petmail’s capabil-ities and perform others not supported by Petmailusing WS-Policy [4] negotiations and dynamic plug-ins.
Web Service Security
WS-Security [21] is a set ofprotocols for adding security enhancements to SOAPmessages. Regarding web services security analyses,the Samoa project at Microsoft Research developeda formal semantics for proving web services authen-tication theorems [6] and the TulaFale language forautomating web service security protocol proofs [7].Based on their ideas and others, we performed follow-up work based on WSEmail, including adaptive mid-dleware messaging policy systems [2], attribute-basedmessaging [10], and a secure alert messaging proto-col [13].
Several vendor-specific all-in-one internet messag-ing systems have been developed recently, includingGoogle Talk, Skype, WeChat, Slack, and WhatsApp.All provide security at the expense of openness. Someallow extensions and integrated apps, but only via acentralized service.
Gmail and Hangouts
Google’s Gmail platformevolved from an email system to include a chattingservice called Google Talk in 2005 and a unified plat-form called Hangouts in 2013. The talk applicationhas similarities to WSEmail in that it integrates IMwith email messages (allowing conversion between thetwo) and integrates with other chat protocols such asJabber. Talk differs from WSEmail in that it useshop-by-hop encryption instead of end-to-end [15]. Itis also primarily client-server based (via Google), al-though it will route calls in a peer-to-peer mannerif possible [14]. Talk and Hangouts use proprietary communication protocols, so the platforms are notamenable to third-party extensions.
Skype
Skype integrates voice and chat into oneapp. Chat messages sent to offline users are sent likeemails, stored on the server and delivered to the tar-get at next login. Skype’s security model is similarto WSEmail’s secure chat architecture in that it usespublic key encrypted messages and challenges for au-thentication, establishes a shared key, and then usesthe shared key to create a secure end-to-end chan-nel. It uses proprietary protocols and does not offerintegration with other chat or voice communicationtools [8].
WeChat is a service that provides instantmessaging and chat. Its communication protocol isproprietary, but forensic analyses and protocol anal-yses have found that its communication protocols areserver based and encrypted using a custom combina-tion of a fixed RSA key and derived AES keys [16, 22].WeChat allows integration of miniprograms via itscentral servers.
Slack
Slack is a cloud based tool for team collab-oration that offers chat and document storage. Itssecurity protocols are based on TLS 1.2, SHA2, andAES and support enterprise specific keys [25]. Proto-col details are proprietary, but black box testing andprotocol analysis have shown them to be server basedwith no peer-to-peer or direct connections [17]. Incontrast to others, Slack allows bots , software agentsthat listen to conversations and data and act basedon them.
OTR
The Off the Record (OTR) [11] protocol in-troduces a mechanism for secret, authenticated low-latency communication that preserves the ability forparticipants to repudiate their messages later. OTRhas been installed in a number of operating systemsand secure chat tools such as cryptocat [19].
WhatsApp is a cloud based chat andvideo call service aimed at smartphones. The What-sApp client authentication protocol underwent signif-icant changes between versions. The pre-2016 What-sApp client authentication steps are as follows [3, 18].At installation time, a shared password pw is gen-erated for the user account and stored on the mo-bile device before being transferred to the WhatsApp14ervers. It is used along with a nonce to generate ses-sion keys using a key derivation algorithm at logintime. Since 2016, WhatsApp uses the Signal pro-tocol, an end-to-end encryption scheme based on anelliptical curve public/private key pair generated atinstall time [27]. It uses the Signal ratcheting pro-tocol for instant messaging and voice communica-tion [12]. WhatsApp is a closed source system thatdoes not enable extensions or integration with third-party clients. Email and IM have advanced significantly in thepast decade. Email’s protocols have remained sta-ble, while server side technologies have reduced mis-use ( e.g. spam). IM has improved in terms of secu-rity and privacy, offering stronger authentication thatincreases trust. Modern secure messaging systems,however, have achieved their gains, at the price ofopenness and ability to interact with each other andwith extensions. As WSEmail demonstrates, anotherevolutionary path was possible, one that would haveoffered increased security and privacy while retainingopenness and extensibility.We have detailed WSEmail, including its softwarearchitecture, communication protocols, and dynamicextensions mechanism. It allows for rich internet mes-saging with flexible policy options for routing and de-livery. Its messaging protocols are amenable to for-mal correctness and security verification. Our per-formance measures show reasonable communicationlatency on legacy hardware and operating systems.WSEmail serves as model for how it is possible tounify communication tools such as email and IM in asecure and private way without hindering extensibil-ity and openness. Next generation messaging systemswould do well to take lessons from it.
Acknowledgements
We are grateful for discus-sions of WSEmail that we had with Martin Abadi,Raja Afandi, Noam Arzt, Karthikeyan Bharga-van, Luca Cardelli, Dan Fay, Eric Freudenthal,Cedric Fournet, Andy Gordon, Ari Hershl Gordon-Schlosberg, Munawar Hafiz, Jin Heo, Himanshu Khu-rana, Ralph Johnson, Bjorn Knutsson, Jay Patel,Neelay Shah, Kaijun Tan, and Jianqing Zhang. Weare also grateful to Nayan L. Bhattad for technicalsupport with experiments.
References [1] M. Abadi, N. Glew, B. Horne, and B. Pinkas.Certified email with a light on-line trusted thirdparty: design and implementation. In
Proceed-ings of the Eleventh International Conference onWorld Wide Web , pages 387–395. ACM Press,2002.[2] Raja Afandi, Jianqing Zhang, and Carl A.Gunter. AMPol-Q: Adaptive middleware policyto support QoS. In
Proceedings of the 4th Inter-national Conference on Service-Oriented Com-puting , ICSOC’06, pages 165–178, Berlin, Hei-delberg, 2006. Springer-Verlag.[3] Cosimo Anglano. Forensic analysis of WhatsAppmessenger on Android smartphones.
Digital In-vestigation , 11(3):201–213, 2014. Special Issue:Embedded Forensics.[4] Siddharth Bajaj, Don Box, Dave Chap-pell, Francisco Curbera, Glen Daniels, PhillipHallam-Baker, Maryann Hondo, Chris Kaler,Dave Langworthy, Anthony Nadalin, NatarajNagaratnam, Hemma Prafullchandra, Claus vonRiegen, Daniel Roth, Jeffrey Schlimmer, ChrisSharp, John Shewchuk, Asir Vedamuthu, ¨UmitYal¸cinalp, and David Orchard. Web ServicesPolicy 1.2 - Framework (WS-Policy). W3C mem-ber submission, World Wide Web Consortium,25 April 2006.[5] M. Bartel, J. Boyer, B. Fox, B. LaMacchia, andE. Simon. XML-signature syntax and process-ing. W3C recommendation, World Wide WebConsortium, Feb 2002.[6] K. Bhargavan, C. Fournet, and A. Gordon. A se-mantics for web services authentication. In
Pro-ceedings of the 31st ACM SIGPLAN-SIGACTSymposium on Principles of Programming Lan-guages , pages 198–209, New York, NY, 2004.ACM Press.[7] K. Bhargavan, C. Fournet, A. D. Gordon, andR. Pucella. TulaFale: A security tool forweb services. In
International Symposium onFormal Methods for Components and Objects(FMCO’03) , LNCS. Springer, 2003.[8] Philippe Biondi and Fabrice Desclaux. Silverneedle in the Skype. In
BlackHat Europe 2006 .Black Hat, March 2006.159] B. Blanchet. An efficient cryptographic protocolverifier based on Prolog rules. In
Proceedings ofthe 14th IEEE Workshop on Computer SecurityFoundations , page 82. IEEE Computer Society,2001.[10] R. Bobba, O. Fatemieh, F. Khan, C. A. Gunter,and H. Khurana. Using attribute-based accesscontrol to enable attribute-based messaging. In , pages 403–413,Dec 2006.[11] Nikita Borisov, Ian Goldberg, and Eric Brewer.Off-the-record communication, or, why not touse PGP. In
Proceedings of the 2004 ACMWorkshop on Privacy in the Electronic Society ,pages 77–84, New York, NY, USA, 2004. ACM.[12] Katriel Cohn-Gordon, Cas Cremers, BenjaminDowling, Luke Garratt, and Douglas Stebila. Aformal security analysis of the Signal messag-ing protocol. Cryptology ePrint Archive, Report2016/1013, 2016. eprint.iacr.org/2016/1013.[13] F. Gioachin, R. Shankesi, M. J. May, C. A.Gunter, and W. Shin. Emergency alerts as RSSfeeds with interdomain authorization. In
SecondInternational Conference on Internet Monitor-ing and Protection (ICIMP 2007) , pages 13–13,July 2007.[14] Google. Peer-to-peer calling in Hangouts.Hangouts Help [Online], 2018. last accessed22 Nov 2018. https://support.google.com/hangouts/answer/6334301?hl=en .[15] GoogleTalkGuide. Can my GTalk discussion betracked? Google Talk Help Discussion Archive[Online], 21 Nov 2006.[16] Q. Huang, P. P. C. Lee, C. He, J. Qian,and C. He. Fine-grained dissection of WeChatin cellular networks. In , pages 309–318, June 2015.[17] Yoshimasa Iwase. Is Slack’s WebRTC reallyslacking? webrtcH4cKS, 24 Mar 2016.[18] F. Karpisek, I. Baggili, and F. Breitinger. What-sApp network forensics: Decrypting and under-standing the WhatsApp call signaling messages.
Digital Investigation , 15:110–118, 2015. SpecialIssue: Big Data and Intelligent Data Analysis. [19] Nadim Kobeissi and Arlo Breault. Cryptocat:Adopting accessibility and ease of use as securityproperties.
CoRR , abs/1306.5156, 2013.[20] Kevin D. Lux, Michael J. May, Nayan L. Bhat-tad, and Carl A. Gunter. Wsemail: Secure in-ternet messaging based on web services. In , Orlando, FL, USA, July 2005. IEEE.[21] Anthony Nadalin, Chris Kaler, Ronald Monzillo,and Phillip Hallam-Baker. Web services se-curity: SOAP message security 1.1 (WS-Security 2004). Standard wss-v1.1-spec-os-SOAPMessageSecurity, OASIS, Feb 2006.[22] Roberto Paleari. A look at WeChat security, 17Sept 2013.[23] Cesare Pautasso, Olaf Zimmermann, and FrankLeymann. Restful web services vs. ”big”’ webservices: Making the right architectural decision.In
Proceedings of the 17th International Confer-ence on World Wide Web , WWW ’08, pages805–814, New York, NY, USA, 2008. ACM.[24] Kennedy Mutange Senagi, George Okeyo, Wil-son Cheruiyot, and Michael Kimwele. An ag-gregated technique for optimization of SOAPperformance in communication in web services.
Service Oriented Computing and Applications ,10(3):273–278, Sep 2016.[25] Slack.
Security White Paper: Slack’s Approachto Security , 2019.[26] Brian Warner.
Petmail Design . Petmail, 20 July2005. last accessed 13 Aug 2019.[27] WhatsApp. WhatsApp encryption overview.Technical white paper, WhatsApp, 16 Nov 2016.[28] Dan Zhou, J. C. Kuo, S. Older, and S. K. Chin.Formal development of secure email. In
Proceed-ings of the 32nd Annual Hawaii InternationalConference on Systems Sciences , Jan 1999.