4WWW95: tutorial:
security, authentication and privacy on the Web

this was voted BEST TUTORIAL of the conference !

author:

adam cain from NCSA

overview:

adam introduced the basics of security related to the Web and listed the potential attacks to WWW servers and clients. he made suggestions how to reduce the risks of attacks and explained the currently available security mechanisms. adam discussed more sophisticated methods to increase security, authentication and privacy on the Web.

the four intertwined components of security:

1. system security
   a secure system shall be free of security holes, e.g. introduced by software bugs.
   
   
2. authentication mechanisms
   authentication may be ensured by passwords, digital signatures, challenge-responses, smart cards and so on.
   
   
3. access control and authorization system
   access to objects (e.g. files) must be controlled by access control lists or similar means.
   
   
4. privacy technologies
   such as data encryption and dedicated links.

system security considerations for using a WWW browser:

"who knows what is on the other side of a hyperlink ?"
Web servers are easy to be set up and therefore a malicious individual may try to invade clients by attracting Websurfers with interesting information. the information may require a special helper application (a software that will be called by the WWW client), which in turn may contain a trojan horse or any other naughty properties. helper applications should be carefully inspected before they are used. an older version of the ghostscript program is one of the well known helper application which included dangerous features, e.g. the capability to delete files on the client's harddisk.

but also the browsers themselves may contain security holes. if the source code is available, one should watch for system calls to external application. also a stack overflow caused by very long URLs may be misused to execute shell commands on stack.
some browsers even allow the execution of shell scripts on the client system, probably one of the most dangerous security threats of all !

a popular method to limit access to clients is the use of a firewall with an HTTP proxy between the trusted network and the Internet. this is generally good, but does not help against the attacks mentioned above !
other promising approaches are portable code languages like Java. they run programs sent by a server in a protected and secure environment.

for more information, see:

• security concerns of executing shell scripts inside Mosaic

system security precautions for using a WWW server:

on of the biggest security threats comes from cgi scripts. an attacker may embed shell commands in string arguments to cgi programs. for example, a malicious client may submit the following string to a cgi script which sends mail to an address specified in an HTML form:

whatever@wherever.com ; rm -rf /

the following precautions may reduce the risk of attacks against the server system:

• run the HTTP daemon as a special user (e.g. "nobody") with limited access rights. never run the httpd as root !!!
• limit write access to the directory which holds the cgi scripts. carefully inspect cgi scripts before using them !
• turn off server-side includes
• if possible, use a separate machine as a WWW server
• beware security holes in WWW server software. e.g. V1.3 of the NCSA httpd allow malicious client to overflow a temporary buffer on certain machines which means, clients can execute shell commands on the server.

security requirements for sophisticated Web use:

• if we want to share sensitive information on the Web with only a particular group of individuals, then we need authentication of entities and access control and authorization.
  
  
• if we want to publish important information in a trustworthy manner, we need authentication of data (signed messages and documents).
  
  
• digital payment, electronically buying and selling goods, services and information, requires authentication in transaction (payment validation).

in ALL these situations, we would like to be able to achieve data privacy and integrity. these abilities require secure communications between authenticated agents.

current state of Web security:

today, the Web is basically a free-for-all service. client identity is usually unknown and irrelevant, server identity is not proven and therefore clients are anonym?? and access control is not easy. access to most documents is not restricted and free. on the other hand, eavesdropping is fairly simple.

the following authentication and access control mechanisms are available today:

1. basic authentication:
   basic authentication is part of the HTTP V1.0 specification. it requires typically a username and a password for authentication. files on the server contain a list of users, passwords and groups, passwords are stored in an encrypted form.
   when the server receives a request for a document that is protected by basic authentication, it sends an "authentication required" message back to the client (message nr 401). the browser then prompts the user for a name and a password in a dialog box. then the client resubmits the request with the username:password in the authentication line.
   • strengths:
     this is a simple method and the server administrator has full control over the access rights.
   • weaknesses:
     passwords are sent "in the clear" (uuencoded only), therefore they are quite simple to be "sniffed". access control is hard to manage on servers with many documents.
   
   
   
2. using network domain for access control:
   the server checks the IP address of the client and use it for authorization.
   • strengths:
     harder to spoof than basic authentication.
   • weaknesses:
     only as secure as the domain name service (DNS), which means, not bulletproof. may be hard to manage because of wrong granularity. this method does neither address data privacy nor agent authentication.
   
   
   
3. basic authentication and IP filtering combined:
   the combination of the two above mentioned methods may increase security somehow, but these mechanisms do not help with data privacy, strong authentication or digital payment. we still need strong authentication and secure communications !

for more information, see:

• how to set up a protected CERN server

cryptography to increase privacy:

there are two basic methods for data encryption:

• symmetric key cryptography
  data is encrypted and decrypted with the same key. the strength of encryption depends on the size of the key: a key with less than 40 bits is to be considered insecure, while a key with more than 128 bits is fairly unbreakable.
  the problem is: how get both parties the secret key in the first place ?
  
  
• public key cryptography
  public key cryptography requires two keys, a secret ("private") key and a well known ("public") key. there are two different scenarios where public key cryptography may be used:
  1. send a secret message that only a particular receiver shall be able to read:
     the sender encrypt the message with the receiver's public key, only the holder of the corresponding private key can decrypt an read the message.
  2. digital signatures:
     the author of a document encrypts the text with his private key. anyone who knows the authors public key can decrypt and read the message, this reliably authenticates the author.

since public key cryptography is much slower than symmetric key cryptography, the former method may be used to safely exchange a symmetric key and use the later method for further data exchange.

one problem with public keys is the question: how can we be sure that a particular public key belongs to a particular person ? this problem might be solved by so called digital certificates. a "certification authority" (CA) issues a data structure containing information such as the user name, the user's public key, the name of the CA and maybe other attributes and signs it with their own private key. to use the certificate, we must trust the CA's private key.

for more information, see

• cryptography: the study of encryption
• ronald l. rivest: cryptography and secure page

adding cryptography to the Web:

however, to add cryptography to the Web has some difficulties:

• HTTP and HTML must be re-defined to include cryptographic capabilities
• WWW browsers and WWW servers have to be modified to include crypto features
• there is a large variety of cryptographic algorithms to choose from
• currently there is no infrastructure to manage key distribution
• US export restrictions on cryptographic technologies disallow world wide distribution !

PGP and PEM authentication, encryption in NCSA Mosaic and HTTP daemon:

• PGP: "Pretty Good Privacy"
• PEM: "Privacy Enhanced Mail"

the basic idea is to use external programs to sign and encrypt HTTP messages rather than adding this capabilities to the WWW servers and browsers. both, PGP and PEM use RSA for public key cryptography and have sophisticated signing and encrypting capabilities. the documents on the server are protected either using PGP or PEM. requests are signed and encrypted by the client, replies are signed and encrypted by the server.

• strengths:
  PGP and PEM are widely used (mainly for mail and news posting) and browsers and servers let external programs handle data encryption/decryption.

• weaknesses:
  as mentioned above, there is no infrastructure to distribute keys and calling external programs may be slow and can introduce security risks.

there is an initial implementation in X-Mosaic and httpd available which basically proofs the concept. a revised implementation is in progress, which involves a PGP CCI (Common Client Interface) application on the client side. this will allow for verification of signed documents to authenticate the author of the document.

for more information, see:

• using PGP/PEM with Mosaic
• CCI-based Web security: a design using PGP

EIT's secure HTTP:

Enterprise Integration Technology (EIT) proposed security extensions to HTTP, called S-HTTP. this new protocol is designed to allow encrypted and/or signed HTTP messages. it supports various cryptographic mechanisms which allows the server and the client to negotiate on the required security scheme.

EIT introduced a new protocol designator in the anchor called shttp and a new protocol method called secure. protected HTTP messages are encapsulated within S-HTTP messages. the S-HTTP headers specify negotiation parameters, e.g. the encryption method to be used. there is an implementation available based on NCSA Mosaic and httpd from a silicon valley consortium called "CommerceNet".

• strengths:
  this is the only serious implementation of a public key crypto aware browser so far. the protocol is flexible enough to allow various encryption algorithms.
  
  
• weaknesses:
  the HTTP extensions need to be redefined and standardized. the new anchor type may cause some backward compatibility problems.

in the future, secure Mosaic and httpd will be distributed free of charge for non-commercial use via NCSA. an S-HTTP module for Spyglass' Security Architecture (SSA) will be created, other WWW servers already support S-HTTP. even NetScape has promised to support S-HTTP ...

SSL and PCT, a security layer between the application and the network layer:

• SSL: NetScape's Secure Sockets Layer
• PCT: Microsoft's Private Communication Technology

a security layer (SL) adds security just above the network layer, so it can be used by any protocol, such as SMTP, FTP, NNTP, HTTP and so on. it supports one-way and two-way authentication via RSA and X.509 certificates and provides an encrypted channel to exchange sensitive information. it is easy to add SL support to applications via alternate BSD socket calls.

SL uses public key crypto to exchange a session key which is used to encrypt/decrypt data and involves the following steps:

1. the client sends a "hello" message to the server
2. the server sends a certificate, including its public key
3. the client creates a session key and sends it encrypted using the server's public key
4. further messages between the client and the server are encrypted using the session key
5. HTTP is spoken as usual over the encrypted channel

in the current implementation in NetScape's client, the security status is indicated by a key graph at the lower left corner of the window. the "https" protocol in the anchor indicates that SSL should be used when contacting a server.

• strengths:
  SSL is available now in a client with wide deployment. it can be used with other protocols as well and it is easy to add support for SSL in applications.
  
  
• weaknesses:
  authentication is needed at the application level in the long-term. SSL requires a new proxy protocol. the current implementation (V 1.1) has a weak routine for seeding random number generator which creates session keys that are not unguessable.
  also, there are several other network layer security proposals around.

message digest authentication:

this is a simple replacement for basic authentication, but passwords are not sent in clear text. the digest function computes an authorization string and passes it to the server for verification. on the server, username and the encrypted password are stored in one or several files. the authorization string is computed from the username, password, URL and a timestamp and is a one-way function to ensure that a potential attacker cannot deduce the password from the authorization string. the timestamp guards against replay attacks.

• strengths:
  this is a simple method and easy to support. to the user, it looks just like basic authentication.
  digest functions are public domain and therefore there are no export restrictions !
  
  
• weaknesses:
  like with basic authentication, it may be hard to manage a large number of user password files. unlike basic authentication, password files must be protected, even if they don't contain passwords in cleartext, because anyone who can read them can masquerade as a user.

kerberized Mosaic and httpd:

Kerberos as a trusted third party system using symmetric cryptography allows authentication of clients and servers in an untrusted network. a client obtains a so called "ticket" for network services from a ticket granting service. the ticket sent by the client to the server contains a session key which allows to establish an encrypted channel between the client and the server. Kerberos systems are widely used and extensively tested.

a kerberized Mosaic and httpd allow mutual authentication between a Web client and a Web server. the server can use the client's authentication for access control and the session key allows data encryption.

NCSA httpd V1.5 supports Kerberos V4 and V5 for authentication, the same is true for most new releases of Mosaic clients. other WWW clients and servers support Kerberos as well but in a different implementation.

consolidation efforts:

with so many Web security mechanisms ...

1. basic authentication
2. message digest authentication
3. Kerberos
4. PGP and PEM
5. S-HTTP
6. SSL and PCT
7. DCE-Web from OSF (not mentioned in this tutorial)
8. and many others also not mentioned above

... how are we going to deal with all this ?

the W3C security protocol development follows the following paths:

• application layered security (same spirit as S-HTTP)
• borrows from Spyglass' open security architecture
• might use extension headers proposed as part of HTTP V1.1

for more information, see

• HTTP security group of W3C

digital payment and the Web:

none of the schemes covered so far is well suited for digital payment. such payment systems have diverse requirements:

• for low-cost items, transactions must be quick and easy, but strong security is less important
• for higher-cost items, non-repudiation is important and off-line payment approval may be necessary.

many new Web payment schemes use external applications to be browser/server independent. in this case, no special security features of HTTP are utilized. instead, payment processing usually involves a third party in transaction protocol, a so called "payment processor".

two examples of such implementations are STT by Microsoft and Visa and SEPP by Mastercard.

for more information, see

• digital commerce on the Web
• requirements for network payment: the NetCheque perspective

my comment:

adam gave a very interesting and at the same time, a very entertaining talk. his explanations were clear and extremely helpful. security is a complex but important topic, not only in commercial environments. the reliable authentication of the author of a (scientific) publication might be as important as privacy in commercial transaction. i have heard a lot of new terms and there is a lot to explore in this area of the Web ...

the slides used in this tutorial are available on the Web.

back to 4WWW95 main document.