I'm willing to bet that it gets sent even if the second HTTPS connection provides no effective security.

(If this is the protocol we're building economies on these days, I feel computer security is going to get much worse before it gets better...)

If your browser is communicating on the second HTTPS connection, that pretty much implies that you are happy with its security levels, right? After all, if you weren't (e.g. bad certificates, etc), your browser wouldn't have established & confirmed the secure connection, HTTP referrer headers or not.

You're right, of course.

Let me expand my argument a little.

We have two security domains, associated with the first and second server. The first server has sensitive URLs, the second receives these in the referrer header.

In making the first connection, the client and first server get to make some security policy decisions: the crypto used in securing the connection, the availability of countermeasures against known TLS protocol vulnerabilities, client and server authentication methods, etc. These parameters are complex, and you end up with a connection with some security level given some attacker model. If you think about it really hard, you can come up with a quantitive estimate of what security you might get from the connection in terms of attacker work -- anywhere from zero (trivially broken) to 256-bit security (very good).

Assume our first connection has a 128-bit security level and has countermeasures for TLS vulnerabilities. This is good going. Now we serve over this connection a https link, which the user clicks.

Unfortunately the client and/or second server is poorly configured and we only manage (for the sake of argument) a 40-bit security level and no TLS vulnerability countermeasures. Now we've reduced portions of the first connection to the security level offerred by the second connection. This is really very surprising.

If you are unhappy about using 40 bits, you can configure your browser to reject sending requests to such sites. When the connection with the second site is negotiated, it will ultimately get rejected, long before HTTP or any referrer headers are sent to it.

I see what you mean about dropping the security level, but generally SSL is seen as a binary 'good enough/not good enough' choice. I don't know of any browser that gives a graduated measure of a site's security. Either it flags up a warning or it doesn't.

You may trust both of the websites you visit, but you may not trust them to know about each other.

That is a fair argument, but could equally be used for the non-HTTPS versions as well. The answer is the same in both cases: If you are not happy sharing such information, configure your browser not to use the referrer header.

I consider it incredibly rude to default to a lack of privacy, especially for visits to HTTPS sites, and especially because most users don't realize what's going on behind the scenes.

That may be, but it really shouldn't be. You cannot have sufficient trust in all parties involved to be certain that no sensitive data is going to a third party (the website you're going to) that is malicious.