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 , 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 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.) The string 'realm' is any symbol (without obvious special characters ':', '=', etc) which is used to identify cooperating security services, thus providing a way to put credentials into their own namespace. The 'hash' is a string representation of a Perl hash of the form: hash = { uid => string: user ID timestamp => integer: time stamp from time(), qop => integer: session quality of protection, authqop => integer: user authentication quality of protection } See the source code of Wrapper.pm for details of how the hash is converted into a string. The encryption function E_k is currently not very configurable. It is Rijndael (AES) in CBC mode with IV=0. It is well known that CBC mode is vulnerable to forgeries, so a cryptographic checksum is prepended to the plaintext, as indicated. The secret key k must be shared by all host or web servers which use the same realm. Without the secret key, it should be cryptographically infeasible to produce credentials in which the hash and checksum match. It should therefore be cryptographically infeasible for anyone to forge credentials or alter them in any way. References ---------- [RFC2109] D. Kristol, L. Montulli, HTTP State Management Mechanism, RFC 2109, 1997. [RFC2964] K. Moore and N. Freed, Use of HTTP State Management RFC 2964, BCP 44, October 2000. [RFC2965] D. Kristol, L. Montulli, HTTP State Management Mechanism, RFC 2965 (Obsoletes 2109), October 2000. [W3C] World Wide Web Consortium Security FAQ, URL: http://www.w3.org/Security/Faq/. [SSL] D. Wagner, B. Schneier, "Analysis of the SSL 3.0 Protocol", 1996, URL: http://www.counterpane.com/ssl.html.