User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36

Steps to reproduce:

We have a customer which has a fortigate with a transparent proxy and they use session based authentication (because they have terminalservers). When they want to update firefox over the browser, this will not work.

Actual results:

The reason why this is not working is the dns resolving. When they resolve for example ftp.mozilla.org, they receive for every usage another IP address. Another problem is the session based authentication, with IP based, it works.

Expected results:

Is it possible to implement in kerberos authentication with the firefox updater, this will solve the problem.

Doesn't look like this is a security issue that needs to be hidden from the public.

Adam, could you triage this bug to see if it is related to / might be fixed by your work on bug 1563790? Thanks!

Luca, could you check if the problem still exists when the app.update.BITS.enabled preference is enabled? Thanks!

Hi Robert

Sorry, this setting doesnt solve the issue, we tested it. As fortinet told us, it would be fixed, when firefox is able to use kerberos authentication also in the updater.

Best regards
Luca Bortoletto

Do you have to authenticate to view web pages as well? If so, does this work with that pref set after authenticating to view web pages?

Could you also check with fortigate regarding if a Windows BITS download?

Hello Luca,

I think Robert meant to suggest testing with app.update.BITS.enabled set to false, that will disable the new BITS support, which might be unable to authenticate with the proxy properly.

If you install a version of Firefox older than 68.0 (I suggest testing 67.0.4), does it still fail to update? If it worked before, then the new BITS download might be the problem, but it sounds like it might not be related.

If BITS is the problem, then the upcoming change in bug 1563790 should fix it. That allows updates to skip using BITS more quickly if they are unable to download (otherwise BITS will continue to retry for two weeks!)

If BITS is not the problem, though, then I'm not sure what additional work would be needed to support Kerberos. The update download should use the same proxy settings as any other web access within Firefox.

Hi Adam

No, the problem still exists on older versions as 68.00, the oldest version, which I know is 57.00 where the issue exists. We know the problem which affects the issue.

The problem is when we use a fortigate transparent proxy with session based authentication and citrix terminalservers. Problem is that everytime the resolved IP address behind your updatedomain changes. We are currently trying to bypass all updateurls which goes over the proxy, this is not possible when the IP address changes everytime, because there is a mismatch between the DNS cache of the client and the fortigate. As a result, connections dont get bypassed and get routet througt the transparent proxy, on which we have authentication issues.

The suggestion from fortinet is that the problem will be solved, if firefox uses kerberos authentication during the update process.
Currently the update process seems to ignore kerberos.

Best regards

Luca Bortoletto

Thanks for the explanation Luca, I think I understand better now. It's my understanding that authentication with Kerberos should work for updates, though I don't have a way of testing it myself. The following information should help us debug the issue, please run with app.update.BITS.enabled = false so that BITS doesn't hide any errors:

1. If Firefox is already set up to use Kerberos as described in the Integrated Authentication documentation, updates should use the same authentication. Can you confirm that Firefox is able to access public web sites without being interrupted with a captive portal?

2. It may be helpful to collect an update log, you can enable this by setting the pref app.update.log.file to true. You can then attempt the update and attach the update_messages.log file from the profile directory to this bug. The profile directory can be found by going to about:profiles and clicking the "Open Folder" button for the Root Directory of the active profile.

3. Another source of information would be an HTTP log, this will contain a lot of information about the network accesses being attempted. Please follow the instructions for enabling HTTP logging, add ,negotiateauth:5 to the list of modules. We should only need the log.txt-main.<PID> file; this can be fairly large so you may want to zip it first.

Honza, does the above suggestion of HTTP logging make sense, and can you provide any further pointers for debugging this?

Yes, thank you! This is exactly what I would ask myself. Let's see what the log will say, that is the best and quickest way to figure this out and possibly fix. Note that kerberos is not something I would be deeply familiar with, tho...

Thank you for the explanation. I will check this next week with the customer, I will answer back to this ticket.

Best regards

Luca