view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        Apache::SecSess - README
        ========================


0.  Installation and other Documentation
----------------------------------------

In addition to this README file, which hopefully serves as a WHYTO, other 
instructions and information can be found:

./INSTALL                       Installation instructions.
perldoc ./SecSess.pm            man page before installation.
man Apache::SecSess             man page after installation.
./rfc/*.txt                     Related IETF RFC's describing cookies.
./COPYING,./LICENSE             Copyright and license info.


1.  What Problems are We Trying to Solve?
-----------------------------------------

Problem 1: No Secure Single Sign-On.

There is not as far as we know, an Apache module which will securely transfer 
credentials from a login on one trusted host to multiple cooperating hosts, 
across multiple DNS domains and across a range of SSL capabilities.

Problem 2: HTTP Cookie Weaknesses.

Not implicit from problem (1), is the subtle fact that considerable
care must be taken to securely share credentials within a single DNS
domain using HTTP state management (aka Netscape Cookies) as described
in [RFC2109] and [RFC2965].  In fact, the traps and pitfalls are so numerous 
that [RFC2964] generally forbids the use of cookies for any kind of security 
authentication.
  One way to look at this package is as a very simple cryptographic 
protocol designed to defend against attacks which exploit known cookie 
vulnerabilities.


2.  Summary of Features
-----------------------

   * Secure sharing of multi-level credentials within and across DNS domains.
   * Support for different representations of credentials with the ability to 
     chain and interoperate between them.
   * Built-in defense against on-line guessing attacks.
   * Built-in session timeout, both idle and hard-limit.
   * Built-in SU-type function for admins to switch user ID's.
   * Encapsulated database interface.


3.  Known Security Issues with HTTP Cookies
-------------------------------------------

Issue 1: The Caching Problem

Even if no passive or active adversary is sitting between the client
and server, an unauthorized user might still see the wrong data because
any web-caching device along the way might cough up a request such
as http://www.acme.com/creditcards.txt without ever referring it to
the server, if a previous authorized user made the same request.  This
is a no-no for the web-cache to do, but it happens anyway.

Solution: There is no real solution, and RFC2964 is correct to discourage
plaintext cookie-based authentication even over secure networks (like on an 
intranet).  On the other hand, this really is a bug (what if web-caches 
ignored POST arguments).


Issue 2:  Wildcard Cookies Don't Always Go Where Intended

Suppose in a heterogeneous environment with many .acme.com hosts, an
authentication system is setup to share cookies between bruce.acme.com
and wendel.acme.com.  Upon successful login, bruce issues an .acme.com
cookie to a user who can then request resources from wendel.  Even
if you don't admit either passive or active adversaries on the network, the 
user's identity might still be compromised.  If hopkins.acme.com is
compromised and the user visits *any* other compromised site, say
www.fantasyland.org, a trojan .html document with a malicious image
tag <img src="http://hopkins.acme.com">, will send the identity cookies 
directly to hopkins who is waiting for them.  (This is the old 3rd-party
cookie bugaboo exploited by *click.com.)

Solution: Regardless of the mechanism used for representing user 
credentials (cookies, URL's, etc), there will be some set of hosts
included in the system (whether spanned by wildcard matches or server
side redirects).  No untrusted host should be in that set.  This is 
just classic host security.


Issue 3:  Secure Wildcard Cookies Don't Always Have Intended Protection

The underlying weakness in issue (2) is perhaps more relevant for so-called 
secure cookies (with secure flag is set).  Even where host security can be 
assumed across a large heterogeneous environment, there might be one
host which only supports 40-bit SSL, say hopkins.acme.org again.  Supposed 
bruce and wendel were properly configured for only 128-bit cipher suites 
and issued only secure cookies for the .acme.com domain.  Then a malicious 
image tag <img src="https://hopkins.acme.com"> will force a connection
to hopkins.  If 40-bit encryption is negotiated (see next issue), the user's
credentials are reduced from 128-bits to 40-bits.
   Unlike issue (2), we cannot pass this off as a matter of host security, 
because hopkins is not compromised.  A passive adversary who obtains
a 40-bit encrypted copy of the credentials.  He can then do an offline crack 
in order to assume the users identity.  Naively, bruce and wendel might
think an implausible work factor of 2^128 would be necessary.

Solution: A cookie-based authentication module must be configurable
to treat a wildcard .acme.com domain as essentially weak.  Cookies
used for strong authentication must be either confined to a single
host, or to a more restrictive wildcard like '.secure.acme.com'.  The 
demo software shows examples of both.


Issue 4: SSLv2 Rollback Vulnerability

An active adversary can force an SSL client and server to negotiate the
*weakest* cipher suite which they share in common [SSL].  Recall that the 
SSL cipher negotiation was intended to negotiate the *strongest* cipher 
suite.  Thus under the stronger threat model of an active adversary, we are