|
Last modified on Wednesday, 28 May 2008, at 09:41, but of archaeological interest only.
This host provides both vanilla HTTP service and secure SSL (more accurately but less commonly called TLS) service. SSL is the "secure socket layer" protocol family (the more modern TLS is "transport layer security"). You can click off to this page served by the other service at will.
Why a secure server? So you can use your kerberos password to access web resources without sending your password over the network in cleartext. That would be bad.
SSL service is based upon the concept of a "server certificate." A certificate is simply a public key that has been "signed" by a "certificate authority," or "CA." Typically, such a certificate authority is a commercial outfit such as Verisign or Thawte (now owned by Verisign), which receives a fee for the service of signing your certificate. Browers are pre-configured to recognize when a certificate has been signed by one of the big boys of the CA biz.
Our cerficiate is signed by cheapo CA USERTRUST. You can see that for yourself by using your web browser to examine the certificate. To do that, first visit a page on this server using HTTPS; for example, this document. Then:
We are running an open-source web server called Apache httpd, version 2.2, which is the same server we run on our main web server.
The SSL software we use is called OpenSSL . We use "glue" software called mod_ssl to integrate that into our server.
SSL is relatively expensive: the number of bytes in the browser-server converstation is much larger than for an HTTP conversation, and both sides need to perform a lot of number-crunching to authenticate the partner and to encrypt and decrypt the data stream. So, one doesn't wish to use SSL except when necessary.
The only time we really need SSL is when sensitive data (such as kerberos passwords) are being sent. What we would like would be to authenticate once over a secure channel, then conduct the rest of the session over an HTTP channel.
We know of two classes of approaches to reducing the cost of security.
The callback approach involves running a simple daemon on the client that can respond to authentication queries from the server. For example, the user might obtain a kerberos ticket, start the daemon locally, then start a browser session. When the user accesses a protected resource, the remote server converses directly with the client daemon process to verify that the user has an appropriate ticket.
An advantage of this approach is that it doesn't depend upon an explicit custom authentication action being taken by the user (beyond getting their ticket. Another advantage is that it doesn't require a separate web authentication service; instead, the web authentication is integrated into the web service itself. A big disadvantage is that each user must run a custom daemon on their host.
A second approach uses a secure "web login" step with "cookies" to maintain state.
Secure web login simply means that you visit a particular HTTPS URL to authenticate. At that step, an HTTP cookie is created that is carried forward to non-HTTP resources to prove that the authentication step was successful.
A cookie is a small chunk of data that is passed between the server and browser. The server generates the cookie and passes it to the browser in the response header; if the browser choses to accept it, it returns the cookie to the server each time it requests a document that falls within the "context" of the cookie. That context consists of a path and a domain, where the path is a URL prefix and the domain is a hostname specification. For example, a path of "/homes" and a domain of "cs.washington.edu" would specify that the browser return the cookie on each request for a URL starting with "/homes" from any host in the "cs.washington.edu" domain.
Using cookies this way presents two main challenges:
Jan Sanislo has put together a web login scheme that we call "CSENetID." It's based upon the pubcookie software from UW C&C, but is simpler and lighter weight. Read about it here.
Here are some example resources that require different sets of criterea to be met for access to be granted:
Want to expose your kerberos password to the evil world? Then access a page that requires a kerberos password via HTTP instead of via HTTPS. Oops! We need to
|
You can tell when you are viewing a secure document in two ways:
|
|
 |
 |
 |
 |
