There’s certainly nothing in the HTTPS protocol itself stopping browsers like Chrome from reporting every URL you visit to Google.
–
TimwiApr 4 '13 at 14:21

1

@Timwi nor is there anything in the HTTPS protocol preventing Chrome hosting a remote desktop server and uploading all your passwords to a third party; that's not the point :)
–
romkynsApr 4 '13 at 14:22

notpron was a very well-known 'browser-game' back in the day, and it relied almost entirely on secret URLs.
–
lynksApr 4 '13 at 14:25

3 Answers
3

In HTTPS, the actual URL is sent only after the SSL handshake has been performed. What outsiders can observe is:

The server name (which is given plainly in the server certificate).

The length of the request from your browser, from which the length of the URL can usually be inferred to some extent.

One potential trouble with "secret URL" is that they can be bookmarked or copied by the user (e.g. sent by email), and are also displayed on the user screen (in the URL bar), thus potentially vulnerable to shoulder surfers. For passwords and also for secure cookies (cookies sent by servers with the "secure" flag), the involved applications (namely browsers) are supposed to be a bit more cautious than with URL. Human users are also a bit less careful with URL than with passwords. On the whole, secret URL are a valid security mechanism, but you have to remain aware of the details.

Do any known browsers send HTTPS URLs to third parties, ever? For example, Firefox crash reporter, or Chrome search-as-you-type, or IE's malware protection service?
–
romkynsApr 4 '13 at 14:41

Also the duration of the request may allow the attacker to determine if the user is reading cached content, or writing new content, ... or even running a long running SQL query for example.
–
LamonteCristoApr 4 '13 at 14:55

What level of security does this offer, compared to, say, a traditional HTTPS login form using a username/password that's saved in the browser?

As you've gathered from other answers, HTTPS hides the actual request itself. The full URL is not sent when connecting to the server - the document part of the url is set as a request that looks something like this:

GET /login/reallysecure/thisismypassword

or more traditionally:

POST /login

with the POST parameters sent later on in the HTTP request either in plain form or as part of a multipart mime body.

One consideration you have probably not thought of is that url access is typically logged by webservers, meaning at any point in time you'll have say 3 days' (adjust for your log retention policy) worth of username logins one grep away from your systems administrators. Whilst this is arguably immaterial since a modification to the application itself could dump out ordinary login credentials without much difficulty, there is now an added protection factor - do you back up your logs? What happens if these are stolen?

Worse, what happens if there is a way to manipulate your server to return the logs to an external client? This is a massive breach of security, but unlike returning a database of passwords which hopefully use good hashing technique to mitigate (and it is very much mitigate) the impact of this, a URL doesn't have the same protection - it is simply instant access to the account in question.

This is the server-side end of the client-side risk Thomas has already highlighted.

The plaintext URL will likely be stored in the browser's history and cache files, but the URLs themselves will not be transmitted in the clear over the network, since the SSL session begins before any HTTP traffic is sent.

One other side-channel is that any non-HTTPS content in the HTTPS page might cause the URL of the main page to be leaked via the referrer header.Turns out the previous is false. Referer is not sent from HTTPS pages to HTTP pages.

@ThomasPornin - any idea if all browsers follow that standard? Sure they shouldn't, but standards don't always happen. It's probably still worth mentioning that a poorly implemented browser may still send the referrer, though it is cool to know that they are not supposed to. I also learned something there.
–
AJ HendersonApr 4 '13 at 14:55

@ThomasPornin However, browsers still send the URL in the Referer when going from an HTTPS page to another HTTPS page in general, even if that other HTTPS page is on a completely different host.
–
BrunoFeb 18 at 23:32

@Bruno Are you sure about that? I was under the impression that modern browsers don't leak the referrer between entities as per the Same Origin Policy (SOP).
–
PolynomialFeb 19 at 20:28