Phorm

[Ian Batten]

On 18 Mar 08, at 0936, Nicholas Bohm wrote:

>
> This will be a technically challenge, if not impossible to achieve.  
> Also, if it is possible, we then enter the territory of Yossarian  
> and Orr: you need to intercept and analyze each transmission in  
> order to classify said transmission as a transmission that must not  
> be intercepted and analyzed.  Seemingly one cannot get around the  
> fact that transmissions must not be intercepted without first  
> gaining the consent of both parties.

I suspect they're simply going to mask off sites that use RFC2617  
basic authorisation.  For those that don't follow these things, HTTP  
authentication works like this:

Client sends request to Server.

Server responds with a 401 `Not authorised' and informs the client  
which authentication domain is involved in a WWW-Authenticate header  
(plus potentially a nonce for Digest authentication, which few sites  
use).

Client re-sends request with an Authorization header containing the  
base64 encoding of the username and password.

The server then respond to valid credentials with the page in  
question, together with an Authentication-Info header if necessary.   
It's not necessary, usually: it provides the next nonce for the next  
request for Digest authentication.

Subsequent requests by the client to the same server can speculatively  
place the Authorization header in the initial request.  It's possible  
to have servers which have multiple authentication domains (I run one  
myself) in which case crossing into another domain will simply get a  
401.

It's worth pointing out that sending an Authorization header into a  
site which doesn't use authorization is harmless, so one could simply  
bosh a fake authorization string into every web request to bypass  
Phorm if this is how they operate.

But of course sites use a zillion other authentication mechanisms.   
There's the ``remember me'' cookie mechanism, used because a lot of  
web browsers don't support saved passwords.  There are sites that  
request usernames and passwords as form entries and process it within  
the cgi-bin (or whatever) rather than as basic auth, often because the  
web server doesn't understand authentication (squirrel mail, for  
example, just passes your username and password straight through to  
the underlying IMAP server).

And, and, and...

ian