82736 - Secure site sometimes doesn't appear locked

Status: VERIFIED DUPLICATE of bug 85211

(Core Graveyard :: Security: UI, defect, P1)

Description

[Curt Patrick (gone)]

The first time you visit some secure sites no warning dialog is presented and
the lock icon doesn't appear locked.  Shift reload does make the correct
behavior happen, however.  We confirmed this on Windows and Linux but it seemed
to work okay on Mac.  Maybe random?

Comment 1

[Chris Hiner]

dup of bug 80468?

Comment 2

[Curt Patrick (gone)]

This doesn't seem to be the same thing.  The behavior I'm seeing is somewhat 
random and appears to be occurring even after Tracy verified that bug 80468 is 
fixed.

Comment 3

[Mitchell Stoltz (not reading bugmail)]

->Crypto

Comment 4

[lchiang]

This sounds fairly serious.
junruh - are you seeing this on any of your testing?
curt - if you revisit those same sites where you had problems, did the problem
persist?  Wondering if it's random on subsequent runs of the same URL.

I think we should investigate this for 0.9.1.

Comment 5

[selmer (gone)]

We found in the 6.0 release that this matters.  If we don't show the lock item
then people won't use their shopping sites.  The lock item has to be as close to
100% correct as we can make it.

Marking m.9.1 (on behalf of the PDT but without prior consultation :-)

Comment 6

[John G. Myers]

Is there a test case for this bug?  There are numerous lock icon bugs, including 
bugs 64367 76168 and 76364.  There's also a problem with frames and with the 
image cache.  This bug could be a duplicate of any of them.

Comment 7

[lchiang]

thanks, John.

Curt - can you attach the URL of the site you were looking at

Comment 8

[Curt Patrick (gone)]

https://digitalid.verisign.com

Comment 9

[lchiang]

Perhaps this is random?  I loaded https://digitalid.verisign.com
 and got the lock icon displayed.  win32 build 2001052504

Comment 10

[John Unruh]

*** Bug 82437 has been marked as a duplicate of this bug. ***

Comment 11

[John Unruh]

A reproducible testcase is to go down the list on 
http://junruh.mcom.com/ciphers.html . Before long, as you visit these secure 
sites, you will see that the lock is unlocked.

Comment 12

[Stephane Saux]

Using Linux Build ID 2001052908 and junruh's 
http://junruh.mcom.com/ciphers.html
Clicking on any of the links in the "SSL2" and "SSL3" lists, and choosing
"Accept this certificate temporarily for this session only" when prompted
results in icon not being locked.
SSL3 Step Up Cert -> locked.
TLSv1 capable server -> locked.
TLSv1 intolerant server -> (using "Enable TLS" in prefs) Does not load.
TLSv1 intolerant server -> (disabling TLS in prefs) loads, locked.
TLSv1 only server -> TLSv1 only server -> (disabling TLS in prefs) does not
load.  No error dialog. -> (using "Enable TLS" in prefs), accepting cert
temporarily.  not locked.

Comment 13

[Aleksey Nogin]

https://login.yahoo.com/ - both the lock and Page Info act as if it was a
non-secure URL.
Build Id 2001052819 on RedHat Linux 7.1

Comment 14

[David P. Drinan]

Add thayes to cc-list.

The problem is that the nsHttpConnection object is freeing the transport 
(and security) info when the transaction has completed *and* the server has not 
requested keepalive. PSM then asks for the security info on the doc loaded and 
gets back nothing cause necko has thrown away that information. As a result, PSM 
the determines that the doc in not secure.

We must figure out a calling sequence between necko and PSM to in order to fix 
this problem.

The sequence of calls is as follows:

1. nsHttpConnection::CreateTransport()
This create the secure transport and sets mSocketTransport.

2. nsHttpConnection::OnTransactionComplete()
Here is a snippet of code from this method.
    if (!mKeepAlive || NS_FAILED(status)) {
        // if we're not going to be keeping this connection alive...
        mSocketTransport->SetReuseConnection(PR_FALSE);
        mSocketTransport = 0;
    }
If the server does not request keepalive, then mSocketTransport is set to 0.

3. nsHttpConnection::GetSecurityInfo()
Since mSocketTransport is 0, then no security info can be returned and the 
document is regarded as non-secure.

Comment 15

[chris hofmann]

adding some necko guys to the cc list.   is there any help you need from them?

Comment 16

[Aleksey Nogin]

See the (somewhat opposite) example of the security info not being communicated
properly in bug #83193 - ``"Back" button does not clear the "Page Info" security
status''

Comment 17

[John Unruh]

PSM

Comment 18

[lchiang]

ddrinan: do you have an updated status on this?  Thanks.

Comment 19

[David P. Drinan]

Attachment: Patch to fix problem. The fix is for nsHttpConnection to save security info on transaction complete. Need review.

Comment 20

[Ferdinand]

*** Bug 83435 has been marked as a duplicate of this bug. ***

Comment 21

[Darin Fisher]

looks good to me.  sr=darin

Comment 22

[David P. Drinan]

Just found out that my patch still does not work in all cases. I'll keep trying.

Comment 23

[David P. Drinan]

This bug requires some more analysis and work. After discussing this with Phil 
Peterson, Bob Lord and Javi, we decided to move this bug to 0.9.2. If we come up 
with the an acceptable solution early next week, we'll try to get it in for 
0.9.1.

-> mozilla0.9.2.

Comment 24

[lchiang]

In thinking of 0.9.1 release notes (for our users), is there some way for them
to check if the site is secure besides the lock icon? I'd like to ensure the
user that if they come to a secure site/transaction, the secure icon may show
unlocked, but the user can go to a dlg or some place to check for true state.
Thanks.

Comment 25

[John Unruh]

*** Bug 84487 has been marked as a duplicate of this bug. ***

Comment 26

[Stephane Saux]

ddrinan: should we dup this lock icon bug to one of the PDT+ lock icons? Are the
good part of the patch included here part of the patch for the PDT+ bugs?

In any case:
Must be fixed for PSM2.0 / 0.9.2
Target -> 2.0
P1

Comment 27

[David P. Drinan]

This was fixed in necko instead. Marking dup of 85211.

*** This bug has been marked as a duplicate of 85211 ***

Comment 28

[John Unruh]

Verified dupe.