Opened 8 years ago

Last modified 3 years ago

#5686 reopened defect

Many rules fail to initiate rewrite to https & some that do produce insecure sessions

Reported by: torcoascor Owned by: pde
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords:
Cc: auscompgeek@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Navigating to,,,,,,,, among many others results in "This website does not supply identity information". For some the site icon in a larger area appears that would suggest secure occasion occurs briefly. Examples that rewrite to https successfully include,,, Entering full url https://full_host_name will establish a secure session for many of those that otherwise fail to rewrite. For gets rewritten to but doesn't connect in https scheme. Correct rules show in the HTTPS Everywhere control most of time but for some such as the only rule identified is Navigating to does not result in secure scheme but oracle logo appears to left of url. behaves similarly except that it's rule and 12 others including appear in the control list. and both appear at first to have a secure connection which then is replaced by insecure but has been rewritten as

Disabled all addins and navigated to several of the sites where the https rewrite appeared to have happened and the results were as follows: IBM - secured, Oracle - not secured, NPR - not secured, NYTimes - not secured and Lenovo - not secured. Using Chrome without the beta HTTPS Everywhere, IBM - secured; Lenovo, NPR, NYTimes, Symantec - connection secure but other resources partially secured; McAfee - not secured.

Symptoms sound like virus/trojan but have run latest version of Microsoft msert.exe which found no infections. Norton as shown below is always on with real time protection and full scans daily.

Any ideas about what is going on welcome.

Environment: Windows 7 Ultimate SP1 w Norton Internet Security on workstation behind SPI router/firewall; Firefox 12.0 w all Addons disabled except: HTTPS Everywhere 2.0.2, Norton Toolbar 2012.5.3.7, Norton Vulnerability Protection - 3, Secure Login 0.9.9, Following plugins current: Flash, Java, MS Office, Nitro PDF 7.3, Acrobat not current: GoogleUpdate disabled, Silverlight.

Child Tickets

Change History (8)

comment:1 Changed 8 years ago by pde

Resolution: wontfix
Status: newclosed

What you are seeing is that some sites have mixed HTTPS/HTTP content.  The UI is telling you that you are getting less security benefit on those pages:

Sadly, this is almost always something that sites themselves need to fix.

comment:3 Changed 8 years ago by torcoascor

Resolution: wontfix
Status: closedreopened

Sorry - I don't think you read this closely enough. I understand about mixed content. That is not this situation. Clearly sites like symantec and mcafee and even ibm provide support for full encrypted sessions. All you need to do to verify this is to go to and you will see as you would expect that their site is verified by VeriSign with cert issued by VeriSign Class 3 Extended Validation SSL SGC CA blah blah blah. HOWEVER, on my machine in the presence of HTTPS Everywhere something is happening in the rewrite of the url or at least the appearance of it and when the actual connection is made after I enter or the resulting connection is marked "The website does not supply identity information. Your connection to this website is not encrypted." To get a secure session established in the presence of HTTPS Everywhere I must enter the full scheme and host url of If I enter I momentarily see the indication that the connection is secure but then it reverts to a completely unidentified and insecure connection. I cannot believe that this is correct or expected behavior.

According to my reading of the encoded ruleset for Symantec HTTPS Everywhere should have rewritten the url as thereby causing the session to be established under the selected and available security schemes. That is the problem I was reporting and it is occurring with many sites using HTTPS Everywhere but not all. For instance, Schwab, EFF, and Torproject all rewrite correctly and get established under the https regime.

In the presence of HTTPS Everywhere and not, if I enter as the destination url I am unable to establish a secure session in Firefox. Yet in the presence of HTTPS Everywhere and not if I enter the full url as then I get a secure session. What's the value of HTTPS Everywhere if it will not rewrite incomplete entries in the url field into the full https form?
Clearly this is either 1) a defect in HTTPS Everywhere in the context of my environment whether it is caused by conflicts with other visible FF addons (ruled out by my experiments), 2) an actual defect in HTTPS Everywhere in conjunction with FF 12.0, or 3) a possible infection on my machine.

Assuming this is not 2) then can you offer any insight about possibility number 3? Does TOR have knowledge of virus, rootkit or other infections that might produce the described behavior.

comment:4 Changed 8 years ago by gk

There is no rewriting rule for Symantec yet. Feel free to submit one. is correctly rewritten for me using HTTPS Everywhere 2.0.3.

comment:5 Changed 8 years ago by torcoascor

Thanks for your response. I see my HTTPS Everywhere has been updated to 2.0.3. However, when I enter I do not get a rewrite. What appears is the same as what was entered,, and there is no identity verified in the FF Site Identity Button.

With regard to the Symantec Ruleset. I had seen in the projects/https-everywhere.git/blob the following: [https-everywhere.git]/src/chrom/content/rules/Symantec.xml which led me to believe that extensive ruleset was in use. Though I now see the annotation "Fix various convergence integration & self-signing bugs" associated with it and I don't see a recognizable name for it in the HTTPS Everywhere control window.

I ran 21 tests on 18 sites comparing the results between FF with HTTPS Everywhere 2.0.3 to Chrome without the beta HTTPS Everywhere. In addition to I found the following failure on my system to rewrite: or

But in addition, where rewrites did appear to be correct such as to, to and the FF Site Identity Button was greyed out indicating site not identified and no encrypted session established. Yet if I navigate to those rewritten urls using Chrome, the site identify is verified and encryption is present though content is mixed.

I am still researching the possibility I have been infected or that my FF installation is corrupted or compromised. However, I have done a short version of the same tests on another workstation using and Results for ibm and mcafee are the same as on my workstation. However, entering produces with the Site ID Button greyed out. Entering produces the same result with the Site ID Button greyed out. HOWEVER, entering [notice the final forward slash is missing] produces the same result but in this case the Site ID Button is blue and contains verified site and encryption information. I tried removing the final forward slash from the ibm string as and but both continue to fail to rewrite on both workstations and the Site ID Button is greyed out. For both the IBM and the McAfee sites entering the full form https:// url results in verified sites and encryption information using FF.

comment:6 Changed 8 years ago by torcoascor

Stranger and stranger. Entered url text below with the following results on same workstation after FF cache clear, DNS flush, Java cache clear, Norton full disk scan no threats found and FF restart:

  1. rewritten to producing secure connect with Site ID blue
  2. same outcome as 1 above
  3. same outcome as 1 above
  4. same outcome as 1 above (contrast to McAfee same form in 8 below)
  5. resolved to to producing an unidentified insecure connect with Site ID grey
  6. rewritten to producing secure connect with Site ID blue
  7. same outcome as 6 above
  8. or resolved to producing an unidentified insecure connect with Site ID grey
  9. produces a 404 which after 10 seconds redirects to producing secure connect with Site ID blue

Repeated these 3 times each with same outcome. Looks more like a failure to rewrite for simple domain-only url forms. Still seeing initial Site ID of blue or green replaced within a few seconds with grey unidentified but I don't think that has to do with HTTPS Everywhere.

comment:7 Changed 7 years ago by auscompgeek

Cc: auscompgeek@… added

I can at least confirm that HTTPS Everywhere leaks DNS. Upon disabling DNS and setting an HTTPS proxy without a SOCKS or HTTP proxy, HTTPS Everywhere does not rewrite URLs and the load attempt silently fails.

This does not occur with NoScript.

comment:8 Changed 3 years ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.