ad_secure_token
is a session-level cookie from the browser's standpoint
its signature expires in SessionLifetime seconds
contains random garbage (ns_time) to prevent attack against the +
is a session-level cookie from the browser's standpoint
its signature expires in SessionLifetime seconds
contains random garbage (ns_time) to prevent attack against the secure hash
user_id is extraneous
ad_secure_conn_p is
used to determine whether or not the URL being accessed is requires
a secure login. The function simply checks if the location begins
-with "https". (This is safe because the location is set during the
-server initialization.)If secure authentication is required, the ad_secure_token cookie is checked to make
+with "https". (This is safe because the location is set
+during the server initialization.)
If secure authentication is required, the ad_secure_token cookie is checked to make
sure its data matches the data stored in ad_session_id. This is true for all pages
except those that are part of the login process. On these pages,
the user can not yet have received the appropriate ad_secure_token cookie, so no check against
@@ -305,16 +305,17 @@
of the value and the signature. In addition to the expiration of
the digital signature, RFC 2109 specifies an optional max age that
is returned to the client. For most cookies, this max age matches
-the expiration date of the cookie's signature. The standard
+the expiration date of the cookie's signature. The standard
specifies that when the max age is not included, the cookie should
-be "discarded when the user agent exits." Because we can not trust
-the client to do this, we must specify a timeout for the signature.
-The SessionLifetime parameter is used for this purpose, as it
-represents the maximum possible lifetime of a single session.
RFC 2109 specifies this optional "secure" parameter which -mandates that the user-agent use "secure means" to contact the -server when transmitting the cookie. If a secure cookie is returned -to the client over https, then the cookie will never be transmitted -over insecure means.
RFC 2109 specifies this optional "secure" parameter +which mandates that the user-agent use "secure means" to +contact the server when transmitting the cookie. If a secure cookie +is returned to the client over https, then the cookie will never be +transmitted over insecure means.
Performance is a key goal of this implementation of signed cookies. To maximize performance, we will use the following @@ -347,19 +348,19 @@
Storing information on a client always presents an additional security risk.
Since we are only validating the information and not trying to -protect it as a secret, we don't use salt. Cryptographic salt is -useful if you are trying to protect information from being read +protect it as a secret, we don't use salt. Cryptographic salt +is useful if you are trying to protect information from being read (e.g., hashing passwords).
External SSL mechanisms (firewall, dedicated hardware, etc.) can be used by creating two pools of AOLservers. In one pool the servers should be configured with the location parameter of nssock -module set to "https://yourservername". The servers in the other -pool are configured as normal. The external SSL agent should direct -SSL queries to the pool of secure servers, and it should direct -non-SSL queries to the insecure servers.
+module set to "https://yourservername". The servers in +the other pool are configured as normal. The external SSL agent +should direct SSL queries to the pool of secure servers, and it +should direct non-SSL queries to the insecure servers.