Four Intertwined Components:

System Security (Integrity)

"nothing bad happens"

Authentication Mechanisms

"you are who you say you are"

Access Control / Authorization Systems

"do you have a license for that monkeyy?"

Privacy Technologies

"for your eyes only"

System Security requires

Authorization policy implementation
Data confidentiality enforced

Authorization requires Authentication

Privacy is somewhat independent

When employed, it is often linked with Authentication
System may be completely secure but no privacy (e.g., 1984)

The Threat:

Beware of vulerabilities in CGI scripts!

Attacker may embed shell commands in string arguments

Example:

CGI script contains

system("/usr/lib/sendmail -t $USER < input_file")

Malicious client submits form with

USER = " foo@bar.com ; rm -rf / "

Best Defense: Don't run CGI scripts

or closely inspect them (see refs below)

We would like to use WWW for....

Sharing sensitive information with particular groups of individuals

==> Authentication of Entities
==> Access Control / Authorization

Exchanging, publish info in a trustworthy manner: proposals, reports, ...

==> Authentication of Data (Signed Messages/Documents)

Digital payment: Buying and selling goods, services, information

==> Authentication in Transactions (payment validation)

Also, in ALL of these situations, we would like to be able to achieve

==> Data Privacy, Integrity

These abilities require secure communications between authenticated agents

Who's Who on the Web? -- WHO KNOWS !?!

On the Web, nobody knows you're a dog

These days, the Web is basically a Free-For-All

• Client identity is usually unknown

• Server identity is not proven

• Authorship and Document Integrity is not verifiable

and thus,

• Client anonymity is easy

• Access control is not easy

• Document forgery and server impersonation is not hard

And of course, eavesdropping is easy

==> So most all documents are "public"

• Part of HTTP 1.0 Spec

• Access Control based on Username/password

• Management required:

Files on server contain lists of

users/passwords

groups of users

Passwords stored in encrypted form

We can restrict access using client's IP address

Example:

Only let clients in the ".dacom.co.kr" domain view certain documents

Strengths:

• Very simple

• Harder to spoof than Basic Authentication

Weaknesses:

• This is only as secure as DNS (not bulletproof)

• Domain-based filtering often not desirable (wrong granularity)

• Data privacy, agent authentication not addressed

Both NCSA, CERN server all combinations of both methods

NCSA httpd:

• .htaccess files for per-directory access control

• specify allowed access by AND, OR equivilents

  satisfy any
allow from .cs.edu.au
require user moe curly schemp

CERN httpd:

• .www_acl files for per-file access control

  "* : get, put : @128.141.*.*"

Symmetric-key Cryptography for Data Privacy and Integrity

• Data encrypted and decrypted with same key

• Classical examples: Caesar cypher, one-time pad, Enigma Machine

• Fast, tested (secure?) algorithms available: DES, RC4, IDEA....

• Strength of scheme largely depends on size of key

Great, but how do the two parties get the shared, secret key?

Public-key Crypto for Spontaneous, Secure Communications

Each user has a keypair, consisting of a public and private key

Anything encrypted with one key may only be decrypted by the other

To make message readable only by B, encrypt message using B's public key.

Slower than symmetric cryptography

Most popular scheme: RSA

What does an encrypted message look like?

• This is difficult because:

Must extend HTTP, HTML and refine other standards

Often requires new browsers and servers with crypto smarts

Large variety of cryptographic algorithms, hardware, software

Network infrastructure requirements

Web security is one part of the larger puzzle: network/system security

Export/import restrictions on cryptographic technology

But everybody's doing it!

Only a few schemes covered here

Most systems geared towards digital payment

it's where the money is.......

Wait a minute....Why again are we doing this?!

Why? Because most of our problems are solved if we can use...

• Digital signatures to authenticate client HTTP requests

• Digitally signed HTTP server responses for authenticating server

• Signed documents to verify author, prevent forgery

• Public and symmetric-key cryptography for privacy (HTTP, documents)

General Form of Application-level WWW Security schemes:

• Sign and/or encrypt HTTP messages, header fields

• This isn't the only way to add crypto to the Web

PGP, PEM are external packages for message encryption, signing, etc.

Mosaic, httpd run PGP, PEM to handle encryption/signing of HTTP messages

Mechanism:

• Server directories protected with "AuthType PGP" or "AuthType PEM"

• Request may be signed/encrypted by client

• Reply may be signed/encrypted by server

GET /docs/protected.html HTTP/1.0
Accept: text/plain
Accept: application/x-html
[other Accepts]
UserAgent: Mosaic/X 2.2

HTTP/1.0 401 Unauthorized
WWW-Authenticate: PGP entity="paranoid@danger.ncsa.uiuc.edu"
Server: NCSA/1.3

GET / HTTP/1.0
Authorization: PGP entity="acain@ncsa.uiuc.edu"
Content-type: application/x-www-pem-request

-----BEGIN PGP MESSAGE-----  
Version: 2.6.2
	[this is the real request, encrypted and signed]

hGwDl23+9JZcEX0BAv41s2ZP/3VcOdNj8oVKu2h3DP6C+TKdl4IIaQZIp6DBBPlc
mx5GS3ijHk3jP2NYlM1UydxUoShcIIsx1YGlltI/34l4t76oEkkajyvETCiTPYw7
NCdfSXh6P62j9iMKG56mAAAD9kQmeRP2zIhj+6Mm3h5bdSMllfwu8zrYjVocnK+t
jaFPZ6TuzyC2j6MFqfcO5M48ICdUw/KcOv63ffDC1bWYCyop3YeVAApqD/LekSLY
[etc]
-----END PGP MESSAGE-----

HTTP/1.0 200 OK
Content-type: application/x-www-pem-reply

-----BEGIN PGP MESSAGE-----  
Version: 2.6.2
	[this is the real reply, encrypted and signed]

JDqcVMsqo9RT3OGSa6pHDu3+dQm9HAgs56lf6CZqVK+g4PVlxIkA7WhErDJhtw+I
sRC/LPGLi/dF5L6YNg+00HHABgbiowra+OeHhsCRD6AgB2cYv3vg0Jz3uejUDUZo
FiG+va+AHqInZO5OvLHOxtIq5C7Hi2UZZpvITcVjfjb6YLRW+FGT6ekM5XHy3BAM
i95ZQPZsIHh1msScF9r1vIjpbLIIMoentld8eGBeKvRSVPpFHKuMZ6EyuDYgrXIy
[etc]
-----END PGP MESSAGE-----

"S-HTTP" : EIT's proposed security extensions to HTTP

Protocol Designed to

• Allow for HTTP exchanges that are encrypted and/or signed

• Support several cryptographic mechanisms

• Negotiation of modes and options built into protocol

  Examples:

  Client requires that server's response be encrypted

  Server requires that client's request be signed

  Client supports DES, RSA .....

New protocol designator in anchor: "shttp"

New protocol method: "Secure"

Protected HTTP message encapsulated in S-HTTP message

New Headers are added to original HTTP message, specifying:

• Requirements: "reply must be signed and encrypted" (for example)

• Cryptographic algorithms, parameters supported

• Key, certificate exchange/management

New message is signed/encrypted & encapsulated in S-HTTP message

Headers are added to tell receiver how to "unwrap" the message

Example S-HTTP "Get" request:

 
    Secure * Secure-HTTP/1.1   
    Content-Privacy-Domain: PKCS-7  
    Content-Transfer-Encoding: 7BIT 

    BVO5WkJ5hOfh2h0Fif2mAAABb+SLLdZSUMSrLCf3IJpYcts7E9aFHKmWTzT4iqUn
    DD42hvRtOn/TLYtqNdjzttho36gowAh7/wnjY8rBxhoosymZigJKOWwK33EE3H5B
    O4DgkxckGNhH9WjtdDKQ92icIcA/ORPmyl/4O72pscJr186u0xRiyhu04LvRxsFQ
    qzjWJjARaELKVCPwhg/W/QhlH3t7olK83yzEiRu5P/JyxPzReyEc1MAYhLR57rsX

New info in shttp anchors: DN, NONCE, CRYPTOPTS

HTML extensions: CERTS and CRYPTOPTS

Purpose:

Recently proposed as a simple replacement for Basic Authentication

Passwords NOT sent in cleartext

Main Idea:

• Uses Message Digest Functions

• MD5 is in public domain and NOT export-controlled (U.S.)

• Timestamps guard against replay attacks

• Server password files must not be world-readable

• The actual proposal is more complicated

Design:

Security just above the Network layer, so it can be used by NNTP, FTP.....

One-way (and soon two-way) Authentication via RSA and X.509 Certificates

Provides an encrypted channel for sending such data as Credit Card numbers

Easy to add support for SSL via alternate BSD socket calls

Protocol:

1. Client sends server a "hello" message
2. Server sends over certificate (includes server's public key)
3. Client creates session key, sends it encrypted in server's public key
4. Session is encrypted using RC4 with the session key
thereafter, HTTP is spoken as usual

How is this different from S-HTTP?

Current Implementation (1.1) :

• SSL web server running on different port (443)

• "https" protocol in anchors indicates SSL should be used

• In Netscape client, security status indicated by:

Key icon at lower left:
Security status bar
Document Information in File menu

Certificate chain one level deep

("trusted" public keys embedded in client)

The Salient Points:

• A "trusted third party" system using symmetric cryptography (DES)

• Allows authentication of clients and servers in an untrusted network

• Clients obtain "tickets" for services from a Ticket Granting Service

• Ticket sent by client contains a session key
  ==> encrypted channel may be established between client and server

• Comes in two major flavors: V4, V5 (which aren't very compatible)

• Widely used and extensively tested

There are so many Web Security Mechanisms.......

Basic Authentication ... PGP/PEM ... S-HTTP ... Kerberos ... SSL ... MD-5 Authentication ... SmartCard Systems ... Web Security System X (on the way) ...

............How are we going to deal with all this?!?

Consolidation Efforts:

Enhanced Mosaic Security Framework:

• Emphasizes modularity, open standard, linkable security libraries

• Multiple, user-selectable security modules

• Suggests a particular menu interface to security module

• Passes off stated protocol responsibility to security modules

• Module may use smartcards or open their own network connections

Spyglass' "Ehanced Mosaic" supports a few schemes now:

Basic Authentication
MD5 Message Digest Authentication
Electronic Business Co-op Payment scheme
First Virtual (quasi-secure credit card transactions)

Other security mechanisms to be made into modules:

Secure HTTP, with and without signatures
SmartCards: DoD "Fortezza" card system, V-One's "SmartCAT"
OpenMarkets Digital Payment system
Kerberos-based schemes

None of the schemes covered so far is well suited for Digital Payment

Payment systems have diverse requirements

For low-cost items (information):

Transaction must be quick and easy
Strong security is less important

For higher-cost items (hard goods):

Non-repudiation is important (vendor-signed receipts)
Off-line payment aproval may be necessary

Other Issues:

Which comes first? The payment or the goods?

How much new software/hardware is required to use a payment scheme?

Who manages the accounts?

What allowances for privacy are made?

Categories of Digital Payment Schemes

Secure Credit Card transactions

examples: S-HTTP, SSL, First Virtual, CyberCash, Secure Courier
short-term solutions (CC's fundamentally costly, inefficient, insecure)
decreased personal privacy

Credit/Debit Systems

examples: NetCheques, NetBill, smartcards
auditability can be desirable
utility depends on conversion to/from "real" currency

Electronic Currency

examples: ecash (Digicash), NetCash
can be made "untraceable" just like paper cash (increased privacy)
can be implemented in software or hardware
might not have corresponance to "real" currency

Prediction: we will see many of each type (no one dominant system)

• Third party payment system designed for low transaction costs ("micropayment")

• NetBill server maintains accounts for both customers and merchants

• Accounts are linked to conventional financial institutions

• MoneyTool runs on client (external application)

• ProductServer runs on server (launched by CGI script)

• ProductServer and MoneyTool communicate on separate connection

Netbill Protocol

Seven-step process

Client receives goods encrypted before payment is processed

Client receives decryption key after payment is processed

Support for micro-payments, customized pricing, 4-th party approval

What is it?

A truly virtual currency -- no exchange for paper money

An untraceable digital payment scheme -- just like cash

Ecash may reside in a "software" wallet, or in a hardware "smartcard"

Consists of individual tokens of various value, individually signed

How does it work?

Uses novel crypto algorithms based on public-key schemes: Blind Signatures

Analogous to bank signing bill enclosed in a carbon-lined envelope

Current Status:

Beta test, Digicash as the bank
Clients (wallet software) are being distributed
Several shops accepting ecash are online

What does it look like?

---

There is no single answer to Web Security

But if you thought this was bad....Digital Payment is much worse

NetCash, NetChex, NetBill, NetCheques, NetPlay, NetBank, CyberCash, Digicash, Microsoft/Visa STT, First Virtual, OpenMarkets, NetMarkets, MarketNet, Secure Courier, Electronic Business Co-op, Alfred the Butler, Mondex, IBM iKP, HP Vishnu, AT&T anonymous credit cards, CAFE, Millicent, CheckFree

Don't believe everything you read about Web Security, Payment systems

Convergence will be slow, Single-system domination unlikely

We can at least hope for peaceful coexistence

Within a couple years, the "Home (page) Shopping Network" will be upon us