1627654 - Padlock in URL bar is sometimes missing when a FPN session is active

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[Fanolian]

Attachment: FPN padlock missing.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
Build ID: 20200406092400

Steps to reproduce

The issue randomly appears when I am surfing the net and it can occur to any website. Here is a fairly reliable way to reproduce it for me:

1. Open Nightly with a new profile.
2. Install Firefox Private Network browser extension (FPN) v21.
3. Log in to FPN. Activate a session.
4. Visit https://www.google.com/ (or any webpage). Let it finish loading.
5. Shift-left-click the reload icon on toolbar to reload the page.

Actual result

The padlock icon in the URL bar is replaced by ⓘ. Please refer to the attached screenshot.

Expected result

A padlock is shown.

Workaround

1. Toggle network.ssl_tokens_cache_enabled to false and reload the page; OR
2. Pause the FPN session and reload the page.

Notes

I have tried FPN v20 and v21. Both of them exhibit the same bug.

Comment 1

[Fanolian]

From Mozregression:
Last good Nightly: 2020-03-17
First bad Nightly: 2020-03-18
pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7c83f04c82e9ef6c1d2823a64aedd34a79a90eb9&tochange=737aba43bfa1685fa15a9b542636b959397603a8

From autoland build
pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8e3cf2cbb2dc2cc4624b65570fffb62c8be164ae&tochange=c5a8b641d9050b73462b24cfea6dd89833e560b6

This should be regressed by bug 1607257.

Comment 2

[Kershaw Chang [:kershaw]]

The problem here is that we only call SSL_SetResumptionTokenCallback when creating a new nsSocketTransport, but the same socket transport would be reused when connecting to https proxy. In this case, we only save the resumption token for the connection of secure proxy and the token for www.google.com is not saved. As a result, the session resumption is failed because the token is missing.
I think we should call SSL_SetResumptionTokenCallback when a new nsNSSSocketInfo is created.

Comment 3

[Kershaw Chang [:kershaw]]

Attachment: Bug 1627654 - Setup resumption callback when nsNSSSocketInfo is created

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1461bdc19026
Setup resumption callback when nsNSSSocketInfo is created r=keeler

Comment 6

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/1461bdc19026

Comment 7

[Valentina Virlics [:vvalentina], Ecosystem QA]

I have verified that this is no longer reproducible on Firefox Nighlty 78.0a1 (Build ID 20200510212656) using Windows 10 x64 and Mac OS 10.14.6 .
The padlock is shown and active. (checked multiple sites)
Attaching postfix screenshot.

Comment 8

[Valentina Virlics [:vvalentina], Ecosystem QA]

Attachment: padlock.png