connection not secure message - disabling

[mike]

Been reading the posts on this subject. I don't want firefox telling me
that I am trying to go to an insecure site. For banks etc I always look
for https etc.

Can someone confirm that changing
security.insecure_field_warning.contextual.enabled

in about:config will stop this message appearing ?
Thanks.

Michael

[S. McDuff]

I would if I could but I removed Firefox off my computer. :-)

Not getting the "insecure warning" from: Palemoon, Chrome, IE and Edge.

[WaltS48]

I use the Secure Login (Web extension) 0.1.4. When I click the button to
login, my credentials are filled in and I don't see that warning.

<https://addons.mozilla.org/en-US/firefox/addon/secure-login-webextension/>

Instead of being reactive, be proactive and ask the sites where you see
the warning to support HTTPS.

--
Visit Pittsburgh <http://www.visitpittsburgh.com/>
Coexist <https://www.coexist.org/>
National Popular Vote <http://www.nationalpopularvote.com/>
Ubuntu 16.04LTS

[Mark12547]

In article <mailman.154.1489346088.10544.support-
fir...@lists.mozilla.org>, inv...@invalid.invalid says...

> Not getting the "insecure warning" from: Palemoon, Chrome, IE and Edge.
>
>

Actually, Chrome shows it in the address bar:

(i) Not secure | 10.0.0.1

Then once I am logged in to my router, it shows

(i) http://10.0.0.1/at_a_glance.php

Maybe you, like me, didn't notice because Chrome is just showing an
advisory out of the way; whereas Firefox plasters it right next to where
you will be typing and covering part of the screen that might or might
not be needed to continue the logon process, requiring clicking outside
of name/password fields to see the covered part of the screen.



For Firefox, I have come across these three settings to make from the
about:config screen, all three of these are boolean parameters:

security.insecure_field_warning.contextual.enabled set to False

security.insecure_password.ui.enabled set to False

signon.autofillForms.http change to True

Double-clicking on these fields will flip their settings.

The last one (signon.autofillForms.http) will allow autofilling of forms
for http (unsecured) connections.

[Dave Pyles]

Worked for me.
Dave Pyles

[WaltS48]

You can also direct those websites to <https://letsencrypt.org/>

> Let’s Encrypt is a free, automated, and open certificate authority
> brought to you by the non-profit Internet Security Research Group (ISRG).

[David E. Ross]

On 3/12/2017 1:19 PM, WaltS48 wrote:

> You can also direct those websites to <https://letsencrypt.org/>
>
>> Let’s Encrypt is a free, automated, and open certificate authority
>> brought to you by the non-profit Internet Security Research Group (ISRG).
>

How would that work for local devices such as routers and modems?

--
David E. Ross
<http://www.rossde.com/>

Paraphrasing Mark Twain, who was quoting someone else:
There are three kinds of lies: lies, damned lies, and
alternative truths.

[David E. Ross]

I am using SeaMonkey, which has not yet implemented that "feature".
However, the prior posts on this issue alerted me to include the
following in my user.js file:

user_pref("security.insecure_field_warning.contextual.enabled", false);
// do not warn about logging into http Web sites
// Bugs #1216802 and #1319119

[WaltS48]

On 3/12/17 5:27 PM, David E. Ross wrote:
> On 3/12/2017 1:19 PM, WaltS48 wrote:
>
>> You can also direct those websites to <https://letsencrypt.org/>
>>
>>> Let’s Encrypt is a free, automated, and open certificate authority
>>> brought to you by the non-profit Internet Security Research Group (ISRG).
> How would that work for local devices such as routers and modems?
>

Probably wouldn't.

How often do users access those? I haven't in years.

Tried to yesterday, using Firefox 53.0b1 on Windows 10, and because I
have the Secure Login extension didn't see that warning message.

YMMV

[VanguardLH]

https://bugzilla.mozilla.org/show_bug.cgi?id=1217162

Looks like that setting affects a contextual message that appears when
you select an input field for login credentials but the page is not
secured. However, I have to wonder if they also check if the form
submit points at an HTTPS page or just HTTP. I've seen many sites where
you visit an HTTP page for the login but the credentials are not sent
unencrypted. The form's submit action says where to submit the data and
that can point to an HTTPS page. So you see an HTTP page for login but
your credentials are transferred over an HTTPS connection to where the
form's submit points. It would be stupid and show incomplete experience
regarding login pages to not check to WHERE the login credentials are
sent, not just that the page presenting the input fields happens to not
be secured itself.

https://support.mozilla.org/t5/Firefox/Disable-quot-login-information-might-be-compromised-quot-warning/td-p/1374089
https://support.mozilla.org/t5/Protect-your-privacy/Insecure-password-warning-in-Firefox/ta-p/27861

That shows an screen capture showing the contextual (popup) warning that
appears for a login field in an HTTP page. Since this appears before
the user has even entered the string and before they have submitted the
string, it looks like they don't bother to check to WHERE the form data
gets submitted. So, on some sites, this warning is not only bogus but
misleading. They are only checking if the login fields are presented
when visiting a non-secure HTTP web page. I see nothing to indicate if
they decipher to *where* your login credentials actually get submitted.
Someone didn't think this through or they don't understand how forms
work in HTML pages. security.insecure_field_warning.contextual.enabled
is disabled (False) in my Firefox because it is not a valid indicator of
whether my login credentials will be *sent* via HTTP or HTTPS.

So the setting you mentioned is not about the address bar showing a red
slash through a padlock icon. Sites don't need to bother with HTTPS if
the content they deliver is public: it's there for everyone to see.
Perhaps the site doesn't care to prove the site you intended to visit is
the site where you landed. Go to intel.com and you get the red slashed
padlock icon in the address bar. Instead of providing positive
notification that a page is secure, which is how it worked before and
how it works in other web browsers, Mozilla decided to change tracks and
provide negative notification that a page is insecure.

https://securingtomorrow.mcafee.com/business/safeguard-data/a-new-firefox-feature-will-help-you-keep-your-passwords-safe/

I would like to see Mozilla's statistics on how many users missed or
ignored checking for the green padlock in the address bar to verify they
did indeed visit a secured page. Instead of showing green locked for
secure and gray unlocked for insecure (which really is a single flag
showing only for secure), they now show both states and made it more
obvious when you are in the insecure state. They made it more
noticeable. I have not yet found a setting that reverts back to the
less noticable simple gray unlocked padlock when visiting HTTP sites.
Since is likely a GUI element change (a different icon replaces the old
one), I'm guessing it cannot be changed via setting. I don't use
customized style sheets to know if it could be altered that way.

http://news.thewindowsclub.com/firefox-to-warn-you-about-insecure-logins-88656/

That article says "web pages which collect passwords but don’t use HTTPS
will display a gray lock icon with a red strike-through in the address
bar of the Firefox browser." Not true. As mentioned, visit intel.com.
You get the red slashed padlock. There is no login fields in that page.
Their signin uses a different page and that one does use HTTPS.

Yet, by default, Firefox allows mixed content (HTTP content delivered by
an HTTPS page) for images while blocking mixed content for data. They
think that images cannot reveal sensitive information, like a bank
putting an overlay on an image showing your bank account number would be
impossible or a thumbnail gets sent showing a summary of your account
transactions. So they allow a somewhat secure (hence somewhat insecure)
page to get represented as a wholly secure web page. To me, the page is
either secure or insecure, not something between. See the following
settings:

security.mixed_content.block.active_content
security.mixed_content.block.display_content <-- images

They made that decision (to allow insecure sourced images within secure
pages) because so many sites violate the precept of using HTTPS for
securing a web page. Since so many sites do it, bend to their
sloppiness so you don't break so many sites. Yeah, I know that sites
come up with their own reasons for delivering insecure images to their
secure web pages (probably so they can show ads from off-domain
resources, like CDNs [content delivery networks]).

[Mark12547]

In article <mailman.339.1489678367.10544.support-
fir...@lists.mozilla.org>, V...@nguard.LH says...

> I've seen many sites where
> you visit an HTTP page for the login but the credentials are not sent
> unencrypted.
>

That was considered in bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1337246
in the last paragraph of comment 5.

Briefly, if the page is not secure, it is possible that a non-local
script included in that page could steal the password.

But as of today, if one googles for the error message that Firefox
produces, one can find that a number of forums do what you said: the
page is not encrypted, but the password is sent encrypted (or hashed).

Another trick I have seen done is for the page to be unencrypted (HTTP),
but it contains an encrypted frame (HTTPS) where one enters one's
credentials. Browsers typically report only if the outermost page is
encrypted (which in this example would be NO). The concern would then be
that a man-in-the-middle could alter the URL of the embedded frame to
another site.

At least Chrome doesn't overlay the web page when it detects a password
field on an unsecured page, but rather puts it in the address bar.
Unfortunately, it's too easy to miss the warning there. (If they made it
bold or red, it would be easier to spot than being a light gray.)

Firefox, alas, overlays part of the page. If that part of the page
contains critical information you must see while typing in the password,
the only option seems to be to set the focus outside the password field
(click elsewhere on the page or tab out of the field).

[WaltS48]

On 3/16/17 3:03 PM, Mark12547 wrote:
> Firefox, alas, overlays part of the page. If that part of the page
> contains critical information you must see while typing in the password,
> the only option seems to be to set the focus outside the password field
> (click elsewhere on the page or tab out of the field).

What critical information might that be, and won't it appear after the
user has logged in?

I don't see the warning in Firefox because of the login extension I use.

[VanguardLH]

Mark12547 wrote:

> V...@nguard.LH says...
>
>> I've seen many sites where you visit an HTTP page for the login but
>> the credentials are not sent unencrypted.
>
> That was considered in bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=1337246
> in the last paragraph of comment 5.
>
> Briefly, if the page is not secure, it is possible that a non-local
> script included in that page could steal the password.

But HTTPS encryption is employed only during *transmission* of the data.
Why couldn't a local script still steal the login credentials while the
page is rendered in the local client? It isn't encrypted on your end;
else, you wouldn't be able to read the page. The local script would
have unencrypted content to peruse at the client end.

> Firefox, alas, overlays part of the page. If that part of the page
> contains critical information you must see while typing in the password,
> the only option seems to be to set the focus outside the password field
> (click elsewhere on the page or tab out of the field).

Maybe they should consider showing the popup for a short time, like 5
seconds maximum, while flashing its border to draw attention to the
popup alert. Then the alert goes away so the user can see what is in
the page that would otherwise be obliterated by the popup alert.

[VanguardLH]

WaltS48 wrote:

> Mark12547 wrote:
>
>> Firefox, alas, overlays part of the page. If that part of the page
>> contains critical information you must see while typing in the password,
>> the only option seems to be to set the focus outside the password field
>> (click elsewhere on the page or tab out of the field).
>
> What critical information might that be, and won't it appear after the
> user has logged in?

Say the login field doesn't ask for a username or password but instead a
CAPTCHA-like query, like what is 2+7-1? Before you can even enter your
username or password in the input field, you have to qualify that a
human is using their login page. If the correct answer is presented
then they wipe that input element and reuse it for your username or
password. You won't be able to see that if the hint is right under the
input field because the popup obliterates that part of the page.

Some sites are not including images as part of the login. You upload a
picture or pick on from their gallery that is associated to your
account. During the login, the image is presented and you must okay
that image as valid for your account. Well, you won't see [all of] it
if a popup alert is oblitering that portion of the page. One of my
banks does that. I uploaded a photo of my pet and that is a 3rd "field"
for the login page. Luckily the image is to the side of the input field
instead of underneath, but they could change their layout (which was
designed long before Mozilla added the security popup alert).

> I don't see the warning in Firefox because of the login extension I use.

Which does what? Try to connect to an HTTPS version of the page? And
what if there is no HTTPS version of that page?

I used the HTTPSeverywhere add-on at one time. Seemed handy to get it
to use an HTTPS version of a web page -- *if* there was one. However,
too often it screwed up because, for example, a site may leave up their
HTTP page but use a meta tag or script to redirect to another page that
does use HTTPS. Since the lookup was not in HTTPSeverywhere's lookup
table, the add-on prevented the proper redirect, I ended up back at the
HTTP page, and couldn't login. This happened many times for different
sites over the course of a month that I gave up on that add-on. Yes, I
could created and maintain my own rules in the add-on but I wasn't
interested in the extra work. The add-on was supposed to do that for
me. Instead of all that work, I'd just add "s" to "http" to get to the
secured version of the page (and change my bookmarks, too).

https://addons.mozilla.org/en-US/firefox/addon/secure-login-webextension

Isn't that yet another password manager add-on? It appears to have some
other protections regarding logins. Doesn't seem to handle multi-page
logins (another issue submitted in a separate thread here by me). I
can't even see that it guarantees the page is HTTPS or, more accurately,
that the *transmission* of login credentials is via a secured connection
at the time of transmit.

Since the new Firefox popup alert triggers based on the outer page being
delivered via HTTPS, does this add-on actually attempt to find an HTTPS
equivalent of an HTTP page? This add-on may indeed eliminate the popup
but you sure that isn't a side effect rather than a deliberate action?

Have you checked the security.insecure_field_warning.contextual.enabled
in your Firefox? Some add-ons will change the default settings in
Firefox. For example, I use uMatrix which changes the pre-fetching
setting (network.dns.disablePrefetch from false to true). Maybe your
add-on makes a settings change in Firefox. See what value you have for
the security.insecure_field_warning.contextual.enabled setting while
that add-on is enabled and active.

[WaltS48]

I see. Fortunately I haven't had to deal with any sites like that.

>
>> I don't see the warning in Firefox because of the login extension I use.
> Which does what? Try to connect to an HTTPS version of the page? And
> what if there is no HTTPS version of that page?

Enters the login information without me seeing the warning when I click
the extensions button located on my toolbar. Nope, connects to the HTTP
version because it is the only one. It connects to the HTTP version.

>
> I used the HTTPSeverywhere add-on at one time. Seemed handy to get it
> to use an HTTPS version of a web page -- *if* there was one. However,
> too often it screwed up because, for example, a site may leave up their
> HTTP page but use a meta tag or script to redirect to another page that
> does use HTTPS. Since the lookup was not in HTTPSeverywhere's lookup
> table, the add-on prevented the proper redirect, I ended up back at the
> HTTP page, and couldn't login. This happened many times for different
> sites over the course of a month that I gave up on that add-on. Yes, I
> could created and maintain my own rules in the add-on but I wasn't
> interested in the extra work. The add-on was supposed to do that for
> me. Instead of all that work, I'd just add "s" to "http" to get to the
> secured version of the page (and change my bookmarks, too).
>
> https://addons.mozilla.org/en-US/firefox/addon/secure-login-webextension
>
> Isn't that yet another password manager add-on?

Yes, all a user needs to disable the warning. :)

> It appears to have some
> other protections regarding logins. Doesn't seem to handle multi-page
> logins (another issue submitted in a separate thread here by me). I
> can't even see that it guarantees the page is HTTPS or, more accurately,
> that the *transmission* of login credentials is via a secured connection
> at the time of transmit.
>
> Since the new Firefox popup alert triggers based on the outer page being
> delivered via HTTPS, does this add-on actually attempt to find an HTTPS
> equivalent of an HTTP page? This add-on may indeed eliminate the popup
> but you sure that isn't a side effect rather than a deliberate action?

No.

>
> Have you checked the security.insecure_field_warning.contextual.enabled
> in your Firefox? Some add-ons will change the default settings in
> Firefox. For example, I use uMatrix which changes the pre-fetching
> setting (network.dns.disablePrefetch from false to true). Maybe your
> add-on makes a settings change in Firefox. See what value you have for
> the security.insecure_field_warning.contextual.enabled setting while
> that add-on is enabled and active.

No

The only site I go to where I would see the warning, if I wasn't using
the extension is <http://forums.mozillazine.org/>

[Mark12547]

In article <mailman.393.1489751973.10544.support-
fir...@lists.mozilla.org>, V...@nguard.LH says...

> But HTTPS encryption is employed only during *transmission* of the data.
> Why couldn't a local script still steal the login credentials while the
> page is rendered in the local client? It isn't encrypted on your end;
> else, you wouldn't be able to read the page. The local script would
> have unencrypted content to peruse at the client end.
>
>

At least by enforcing HTTPS encryption when receiving the page, along
with no mixed (non-HTTPS) content, at least the "man in the middle"
alterations of the page can't be done between the site and the browser,
and presumably the site sending the encrypted logon page trusts the
other sites it may be fetching content from. (Personally, I think that a
logon page should have content only from that site, but some sites host
part of the content, such as images, on another server. But a logon page
with links to advertising aggregators is just begging for compromising
their customers' credentials.)

That would eliminate one possibility of attack, though not all
possibilities (such as malware infecting the browser).

> Maybe they should consider showing the popup for a short time, like 5
> seconds maximum, while flashing its border to draw attention to the
> popup alert. Then the alert goes away so the user can see what is in
> the page that would otherwise be obliterated by the popup alert.
>
>

Actually, that is a very good idea!