[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5686 [EFF-HTTPS Everywhere]: Many rules fail to initiate rewrite to https & some that do produce insecure sessions
#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