Setting up a secure web server and clients on an Intranet Joris Claessens, Mark Vandenwauver, Bart Preneel, Joos Vandewalle Katholieke Universiteit Leuven Dept. Elektrotechniek, ESAT-COSIC Kardinaal Mercierlaan 94 B-3001 Heverlee - BELGIUM Tel. +32 16 32 11 34 - Fax. +32 16 32 19 86 E-mail : joris.claessens@esat.kuleuven.ac.be Abstract This paper discusses the practical issues that arise when securing the access to the World Wide Web (WWW). A brief overview of the different protocols that are proposed to se- cure the WWW is given and the current status of the U.S. export regulations is reviewed. An attack on SSL 2.0 is de- tailed which exploits some of the weaknesses in this proto- col. The setup of a secure server with access control is ex- plained. At the client side, existing solutions to provide ex- port browsers with strong cryptography are evaluated, and we also introduce some improvements. Finally, the perfor- mance of the secure system is evaluated and compared to that of the regular http connection. Keywords: WWW security, access control, export restric- tions, cryptography. 1 Introduction The World Wide Web (WWW) is one of the primary rea- sons for the current success of the Internet. It has been so successful that many users think of them as synonyms. The WWW is a client-server technology: information is avail- able on servers and is accessed by clients. The communica- tion between these two parties is de£ned in the HyperText Transfer Protocol (HTTP) [3]. To be more useful today and in the future, the WWW needs to be secured. Services such as entity authenti- cation, data authentication, data con£dentiality and non- repudiation are essential for applications such as those used in electronic commerce or in an Intranet environment. A lot of effort has already been done to secure the WWW. This paper intends to give an overview of the cur- rent situation with a focus on more practical issues. We start with an overview of the proposed protocols and the current status of the U.S. export regulations. Weaknesses in SSL 2.0 are exploited in an attack. We then focus on set- ting up a secure server and adding strong cryptography to export browsers. Finally, we look at the performance of the system. 2 Protocols There are currently four proposals for providing security services to the WWW: - Netscape’s Secure Sockets Layer (SSL) [9]; - Microsoft’s Private Communication Technology (PCT) [22]; - Secure HyperText Transfer Protocol (S-HTTP) [20], from Enterprise Integration Technologies and Terisa Systems; - Transport Layer Security (TLS) [7], an IETF working group. All four protocols provide entity authentication, data au- thentication and data con£dentiality. In contrary to SSL and PCT, which are both situated in the transport layer, S-HTTP is situated in the application layer, and can thus offer non- repudiation of origin (in a legal sense). Both PCT and S- HTTP have not been a success. SSL has become a de facto standard on the Internet. The current version of SSL is 3.0 and it has a number of improvements [6, 23] over release 2.0 [11] (see 2.2). There are free implementations available such as SSLeay [26] and SSLRef [17]. As a successor to SSL, the IETF has organized a work- ing group TLS (Transport Layer Security) that has adopted SSL 3.0 in its initial release of TLS 1.0. TLS offers the same services as SSL, but there are some minor differences. As the £rst TLS based products are already being implemented, TLS will probably replace SSL in the future. 2.1 Export regulations and limitations The U.S. export policy has serious implications on the level of security that can be obtained by the most popular WWW browsers and servers. Until January 1997, the strongest cryptography that U.S. companies were allowed to export was limited to a 40 bit security level. Thus, the international versions of Netscape Navigator and Internet Explorer (the two most popular browsers) were limited to 40 bit security. ‘40 bit security’ applies to the maximum length of the key used for symmet- ric encryption. Keys used for asymmetric encryption (key management) are limited to 512 bits. Appeared in Proceedings of the Seventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises Stanford, California, June 17-19, 1998, pp 295–300 0-8186-8751-7/98 $10.00 c 1998 IEEE