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:[EMAIL PROTECTED]), 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:[EMAIL PROTECTED]
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
