User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071603 Minefield/3.1a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071603 Minefield/3.1a1pre I am experiencing this problem since the begin of Firefox 3 and older releases too. I have tested the newest Minefield version to see if the bug still existed. We run a (Bluecoat) Proxy. The authentication is handled with NTLM. This works fine so far but it seems that on https sites there is a problem with authentication. I found out, that the https site gets loaded fine until a second (or multiple other) https sites are loaded in the background. Then a authentication prompt popup appears. In the proxy log it shows the following information: TCP_ACCELERATED/200 39 CONNECT tcp://mail.google.com:443/ - NONE/- - TCP_ACCELERATED/200 39 CONNECT tcp://mail.google.com:443/ - NONE/- - ***At this point the authentication popup appears. And then:*** TCP_DENIED/407 322 CONNECT tcp://ssl.google-analytics.com:443/ - NONE/- - TCP_DENIED/407 579 CONNECT tcp://ssl.google-analytics.com:443/ - NONE/- - TCP_ACCELERATED/200 39 CONNECT tcp://ssl.google-analytics.com:443/ SG01\a.username NONE/- - TCP_DENIED/407 268 CONNECT tcp://ssl.google-analytics.com:443/ - NONE/- - TCP_DENIED/407 322 CONNECT tcp://www.blogger.com:443/ - NONE/- - TCP_DENIED/407 579 CONNECT tcp://www.blogger.com:443/ - NONE/- - TCP_ACCELERATED/200 39 CONNECT tcp://www.blogger.com:443/ SG01\a.username NONE/- - My guess is that there Firefox does not forward the already known NTLM data when a https site is loaded within a https site. Check the source code on gmail.com, you will see the google-analytics and blogger inputs. Reproducible: Always Steps to Reproduce: 1. Use a (Bluecoat) Proxy server with NTLM authentication 2. Surf to a https website which includes other https pages Actual Results: A popup window for proxy authentication appears with the following content and two input fields for username and password: "The proxy xxx.xxx.xxx.xxx:8080 is requesting a user name and password. The site says: "" Expected Results: Firefox should already know the NTLM user data and access the other https sites without asking for username and password again. - The user/password information you type into this authentication popup are not saved. The next time you reproduce this bug, the popup still appears (although with your already given informations). - I have openened a support case in the Mozilla Forums before: http://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&forumId=1&comments_parentId=105582

Made a snapshot of the screen when this bug occurred.

We are experiencing the same issue with NetApp Netcache proxy appliances.

Seems to be the same as bug 439463

Just to confirm that you're not the only one experiencing this. I think this is the same as bug 366562 We're running a Squid proxy server (2.6 Stable 20) running on 2003 Server SP1 using ntlm auth for clients and frequently when accessing ssl enabled sites, this bugzilla site for example) we get the authentication prompts. We've confirmed this in FF3.0.3 & 3.0.4. If I can provide any diagnostic information, please let me know. I'll be happy to help

Unable to reproduce this after update from 3.0.7 to 3.0.8 Can anyone confirm?

This is a mass search for bugs which are in the Firefox General component, are UNCO, have not been changed for 500 days and have an unspecified version. Reporter, can you please update to Firefox 3.6.10 or later, create a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles, and test again. If you still see the issue, please update this bug. If the issue is gone, please set the status to RESOLVED > WORKSFORME.

Thanks for checking, Tyler. Since I opened this ticket, my environment has changed drastically. But in the new environment we also use a Proxy (Squid in this case) and I haven't seen any problems whatsoever concerning loading https pages within an https website. So I guess this was resolved in one of the later versions. I have set it to RESOLVED->FIXED although I don't know in which version exactly the fix came.