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:


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:


security requirements for sophisticated Web use:

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.

  2. using network domain for access control:
    the server checks the IP address of the client and use it for authorization.

  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:


cryptography to increase privacy:

there are two basic methods for data encryption:

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


adding cryptography to the Web:

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


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

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.

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:


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".

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:

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.


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.


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:

for more information, see


digital payment and the Web:

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

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


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.


4WWW95 tutorial H / 28-jan-1999 (ra) / reto ambühler