$ curl -vv 'http://username:[email protected]/
> GET / HTTP/1.1
> Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
dXNlcm5hbWU6cGFzc3dvcmQ= is base64 encoded 'username:password'
The Authorization header is the same one that will be used if your browser prompts you for a username/password.
Also, the Authorization header is also plain text. Whether you pass credentials on the URL or in the Authorization header, it makes little difference in terms of interceptability. They're just different lines in the HTTP request. You need SSL to secure either.
That said, the most common argument that I heard against supporting this stuff is phishing, using the credentials part to push the real address as far as possible to the right/off the screen.
I - don't like that decision. I have basic auth services in internal networks and would like to access them this way.
Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
precisely as you would use HTTP over TCP.
TLS is meant to be transparent to the higher level protocol - in other words, independent of HTTP. The headers should be encrypted also.For a long time, I also believed that the URL would not be encrypted (e.g. GET /example/url.htm), but as it's running as a transparent connection then this is also encrypted. I had to check this to see if GET requests with session IDs would be vulnerable over the wire - I was quite relieved when I realised my assumptions were wrong! Also meant I had to read a few specs :-)