GNOME Bugzilla – Bug 733039
Do not send referer headers from HTTPS sites to HTTPS sites which fail certificate validation
Last modified: 2014-10-02 04:25:54 UTC
From Daniel Gillmore in Bug #726288: "modern browsers do not send https referer headers to http sites. epiphany should also refuse to send https referer headers to authentication-failed HTTPS connections." A couple of questions here: * Should it really matter whether authentication succeeded or failed? * Are you sure modern browsers actually do this? Firefox seems to send the full referer, while Chromium sends the referer but truncates the URL at the domain so you can't see what page was visited. Easy to test by Googling "what is my referer" -- the top results include both an HTTP and an HTTPS result. (You'll have to manually switch from HTTPS Google to HTTP Google to see the difference. Chromium also has a --no-referer switch you can use.)
It's Daniel Gillmor, not Daniel Gillmore :) Thanks for breaking this out as a separate issue, Michael. I think it's more accurately characterized with a different subject line, though. Instead of "Do not send referer headers from HTTPS sites to HTTP sites", it should be "Do not send referer headers from HTTPS sites to HTTPS sites which fail certificate validation" To answer your questions: * yes, if epiphany is going to proceed to connect to servers whose authentication failed, it should treat those connections as cleartext connections, since they could be MITM'ed. The followthrough connection (which no other browser does that i've seen) is better than cleartext (because it defends against passive eavesdroppers), but it is not secured against active attacks. So the connections should be treated as cleartext. * Yes, modern browsers actually do this when they connect to http web sites. Even epiphany does this (tested with version 3.8.2). I am testing using iceweasel (firefox) 31 beta. I'm looking in my web server logs for an HTTP site i control, based on two pages i set up on two other domains i already control (one https, one http). Reviewing the web server logs shows me that the inbound link from the HTTPS site produces no referer info, while the inbound link from the HTTP site produces a full referer. I've also tried it with http://whatismyreferer.com/ here are two sources that point to whatismyreferer: http://cmrg.fifthhorseman.net/wiki/testing https://dkg.fifthhorseman.net/test.html
(In reply to comment #1) > * yes, if epiphany is going to proceed to connect to servers whose > authentication failed, it should treat those connections as cleartext > connections, since they could be MITM'ed. OK; I was wondering if the referer should be dropped whenever the referer is an HTTPS page, which was a misunderstanding of the issue. > * Yes, modern browsers actually do this when they connect to http web sites. > Even epiphany does this (tested with version 3.8.2). I am testing using > iceweasel (firefox) 31 beta. I was testing this using Firefox 30.0 on Google to access whatismyreferer.com, but now I notice that the referer is set to an HTTP address even though the Google page was HTTPS. I don't understand what's going on there. It works fine with Epiphany, though. > here are two sources that point to whatismyreferer: > > http://cmrg.fifthhorseman.net/wiki/testing > https://dkg.fifthhorseman.net/test.html Thanks!
(In reply to comment #1) > * yes, if epiphany is going to proceed to connect to servers whose > authentication failed, it should treat those connections as cleartext > connections, since they could be MITM'ed. Hi Daniel, since we don't do this anymore, we don't need to change anything, correct? I was thinking about adding a check to make sure the certificate has been accepted before sending the referrer, but it occurred to me that the check will always pass, since we wouldn't be loading the site anymore unless authentication succeeded or the user added an exception (in which case, if the host is malicious, he has much bigger problems than leaking his referrer).
When you say "we don't do this any more", what does "any more" mean? can you give a specific version where you expect this behavior to change? I'm testing right now with debian unstable, epiphany-browser version 3.12.1-1 and it still just connects to servers whose authentication fails (i just tried with https://xml.resource.org).
Created attachment 287548 [details] screenshot With 3.13.90 or higher, you should get a warning page instead.
I tested 3.13.90-1 from debian experimental, and i got a segfault when trying to visit https://xml.resource.org Then i upgraded to 3.14.0-1 from debian experimental, and i got the warning page you describe, so i do think that this bug report is moot as of 3.14.0. thanks for following up on it, Michael!