ws-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Taft <a...@hydroblaster.com>
Subject Re: HTTP Authentication again
Date Tue, 09 May 2006 19:02:34 GMT
Olive,

I think that's Firefox's implementation.  It saw the username:password, 
took it out of the URI, sent the request for the page, saw the 401 and 
then resent the username and password using traditional basic 
authentication.

So, I guess I'm a bit off here and you're right, since reading up it 
seems that this is the way it worked all along.  I guess I had in mind 
it was supported by the server (Apache, etc.), not strictly a client 
thing.  I think you'll find IE will do the same thing.

And while I'm debunking myself, additionally I just read this quote:

"Secure Socket Layer (SSL) is a Netscape-developed protocol submitted to 
the W3C working group on security for consideration as a standard 
security approach for World Wide Web browsers and servers on the 
Internet. SSL provides a security "handshake" that is used to initiate 
the TCP/IP connection. This handshake results in the client and server 
agreeing on the level of security they will use and fulfills any 
authentication requirements for the connection. Thereafter, SSL's only 
role is to encrypt and decrypt the byte stream of the application 
protocol being used (for example, HTTP). This means that all the 
information in both the HTTP request and the HTTP response are fully 
encrypted, including the URL the client is requesting, any submitted 
form contents (such as credit card numbers), any HTTP access 
authorization information (usernames and passwords), and all the data 
returned from the server to the client."

Note the "including the URL the client is requesting" part.

So, I guess I'm wrong on two counts.  The URL itself will be encrypted 
as part of the total request in an SSL session.

I'll just go crawl back into my hole now.   :)

Adam




Oliver Cole wrote:
> On Tue, 2006-05-09 at 10:30 -0600, Adam Taft wrote:
>> Just as a point of clarification...
>>
>> When you embed a password into the URL (as discussed in this thread like 
>> https://username:password@example.com), the username and password won't 
>> be encrypted even if you're using SSL (https).  That's obvious, right?
>>
>> Whereas, with basic authentication (via http headers), the credentials 
>> will be encrypted when using SSL.  This is because the credentials are 
>> part of the message header, not part of the resource locator itself.
>>
>> This is ultimately why the form first form for authentication 
>> (credentials in the URL) is strongly discouraged.
> 
> Um, I just sniffed Firefox against Apache, with a user:password@host
> URL, and it first got back a 401, then sent the password in the
> Authorization header. At no point did the password travel alongside any
> form of resource location.
> 
> Either you're wrong, or I misunderstand?
> 
> Regards,
> 
> Oli
> 
> 

Mime
View raw message