Re: [tor-bugs] #5686 [EFF-HTTPS Everywhere]: Many rules fail to initiate rewrite to https & some that do produce insecure sessions

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#5686: Many rules fail to initiate rewrite to https & some that do produce
insecure sessions
-------------------------------------+--------------------------------------
    Reporter:  torcoascor            |       Owner:  pde     
        Type:  defect                |      Status:  reopened
    Priority:  normal                |   Milestone:          
   Component:  EFF-HTTPS Everywhere  |     Version:          
  Resolution:                        |    Keywords:          
      Parent:                        |      Points:          
Actualpoints:                        |  
-------------------------------------+--------------------------------------
Changes (by torcoascor):

  * status:  closed => reopened
  * resolution:  wontfix =>


Comment:

 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 https://www.symantec.com 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 www.symantec.com or
 symantec.com 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
 https://www.symantec.com. If I enter https://symantec.com 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 https://www.symantec.com
 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 www.ibm.com/us/en 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 https://www.ibm.com/us/en 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5686#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs