[innoying]

I think you're misunderstanding the attack scenario here:

> Anyway, if the browser is connecting via port 80, the MITM can just use a transparent http->https proxy to rewrite the referrer, and forward the request to the https server, so you've already lost.

That wouldn't actually work since the user's active session cookie has the "Secure" flag set (i.e. isn't sent over HTTP). Sure if the user logged-in again on the HTTP page you could exploit this with a transparent proxy but there's very little outside of implementing HPKP that BitBucket could do to prevent that attack.

[berdario]

Exactly

But even shutting down access to port 80 on the server wouldn't be enough: the attacker only needs the victim to send the request, it doesn't need for the plaintext request to actually reach the server

(did you mean HSTS instead of HPKP, btw? The scenario I described didn't involve MITM of a HTTPS connection, and thus HPKP wouldn't be strictly needed )

also, I agree that the condition under which this check might be useful are quite convoluted... since Security is often in tension with Usability there is a case to be made for less defense-in-depth, and removing (potentially?) redundant checks... but I think we should be wary of making simplistic arguments for it, due to how delicate web app security is

[hedora]

Agreed; killing port 80 just decreases the chances the browser makes subsequent port 80 requests.

I still think the referrer is only helping paper over a deeper design flaw (using cookies to carry post state) at the expense of getting some users to trade privacy for availability, and decreasing performance/opening up attacks for people that install extensions as a workaround.