view release on metacpan or  search on metacpan

README  view on Meta::CPAN

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 
far more likely to find a target such as hopkins to exploit in issue (3).  
For a variety of reasons (sometimes legal and political), the larger the 
DNS domain (in number or geography) the greater the likelihood of there 
being one host which supports SSLv2 and 40-bits, or a newer SSL/TLS but 
only 40-bits.

Solution: Same as issue (3).


Issue 5:  Persistent Cookies are Often Stored in Filesystem

If a cookie is ever set with a future expiration date, browsers will copy 
it, in the clear, to the filesystem for use upon next invocation of the 
browser.  Such filesystems often shared across networks and so are
available to a wide variety of users.

Solution:  The fundamental session cookies in secure system should be
ephemeral.  This does not preclude the use of persistent cookies as an
initial user identity token if the threat model is appropriate (perhaps
on a single-user laptop).


5.  Security Architecture
-------------------------

5.1  The Authentication Processes
---------------------------------

There are three notions of 'authentication' in Apache::SecSess.

    User Authentication: This serves to identify the user and to provide
        a suitable proof of that identity.  This is typically a login form,
        which interrupts the user, but it might transparently use other 
        credentials which are already available electronically like an X.509
        client certificate or a persistent cookie.

    Session Authentication: This is Apache's notion of authentication as
        carried out by PerlAuthenHandler.  Here, an actual resource, like an 
        HTML doc, will be delivered if all is successful.

    Chaining Authentication:  In this type of authentication, credentials
        suitable for session authentication are interpreted instead as user
        authentication in order to issue another type of credential.  In the 
        demo for example, single sign-on across DNS domains is accomplished 
        by double chaining.  Local cookies are used to the identify user and 
        issue URL credentials during a redirect across the domain, where
        the URL credentials are used to identify/authenticate the user again
        in order to issue cookies within the *new* domain.


5.2  The Security Mechanism
---------------------------

The fundamental security mechanism of Apache::SecSess is the issuance
of simple cryptographic proofs of identity explicitly constructed to
return to the system's various servers via HTTP(S) sessions which are 
protected with sufficient strength, despite the malicious behavior by an 
adversary.  This is achieved in a rather mundane way, namely by avoiding
all the pitfalls of the enumerated issues in Sect. 3.  

In the case of URL credentials, the current implementation requires all
URL's to be explicitly configured.  All redirects are automatic, occurring
under SSL of a specified strength.  There should be no surprises here; if
URL credentials were stolen, the adversary would have had to crack one of
a small number of SSL connections under the complete control of the security 
administrator.

In the case of Cookie credentials, *multiple* cookies are issued, one for 
each anticipated security level.  For example, a user who logs in with an 
X.509 client certificate might be issued 3 cookies: one cleartext cookie 
intended for non-sensitive data, one SSL (secure flag) cookie broadly 
distributed to .acme.com with 40-bit crypto possible, and finally one SSL 
cookie intended only for the 128-bit originating host.  An adversary who 
manages to steal either the cleartext or the 40-bit cookie cannot use it to 
acquire 128-bit level resources, because the cookies themselves have 
unforgeable assertions of security level which are checked during session 
authentication as described in the next section.


5.3  Credential Format
----------------------

Credentials in Apache::SecSess have a similar format:

    URL Credentials:
        realm=E_k(md5(hash),hash)

    Cookie Credentials: 
        realm:qop,authqop=E_k(md5(hash),hash)

(The only difference is that the quality of protection parameters 
discussed below, qop and authqop, are repeated in the clear for cookie
credentials in order to ease processing.)