1394752 - NTLM/Negotiate Auth hangs browser

Status: NEW

(Core :: Networking: HTTP, defect, P3)

Description

[Florian Bender]

I'm in a corporate environment (with a rather loose proxy). I set up Firefox to automatically login for the intranet pages at intranet.company.tld (address redacted) with the following settings:

- network.automatic-ntlm-auth.trusted-uris;.company.tld
- network.negotiate-auth.delegation-uris;.company.tld
- network.negotiate-auth.trusted-uris;.company.tld

When I visit the intranet pages, I experience multiple and multi-second hangs of the browser (including chrome). Maybe it's some synchronous IPC?

Interestingly, when I reset network.negotiate-auth.trusted-uris to an empty value, the hangs disappear reproducibly.

Fx 55.0.3, e10s running well (5/5 windows, 1/1 content processes). Issue was visible in previous Firefox versions as well.

Happy to help you out with logs etc. (esp. of the login process) if you guide me how to acquire them.

Comment 1

[Honza Bambas (:mayhemer)]

Thanks for this report and an offer to help.  I will then ask you for logs according https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging.  

Please set the log modules (MOZ_LOG) as: sync,timestamp,nsHttp:5,negotiateauth:5,NTLM:5

Then start Firefox, reproduce the problem only and close it again.  It's better to send the log file to my bugzilla email directly than to expose it here.  There might be cookies exposed in the log.

Thanks!

Comment 2

[Honza Bambas (:mayhemer)]

And yes, this could be a duplicate of bug 791008, let's verify.

Comment 3

[Daniel Holbert [:dholbert]]

This sounds worth fixing, but doesn't sound like a QF bug. --> marking as [qf-]

(The QF effort is focused on high-usage websites and high-value benchmarks, and it can't cover all performance problems in Firefox.)

Comment 4

[Florian Bender]

Honza, I'm off for the next two seeks so it'll take a while before I can profile. Ni? me as reminder.

Comment 5

[Firefox Bug Husbandry Bot]

Bulk priority update: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 6

[Honza Bambas (:mayhemer)]

Florian, still there?  To move forward it would be great to obtain the log as state in comment 1.  W/o it we can only guess what to do and hence de-prioritize this bug.

I suspect we need to implement async credentials processing also for the NTLM module (impl nsHttpNTLMAuth::GenerateCredentialsAsync.)  But I don't want to shoot into darkness.

Thanks!

Comment 7

[Florian Bender]

Yes, sorry, I did not forget about this bug, but was derailed by higher priority work. Plus, my computer crashed, so I need to wait to get it back. I hope to provide the logs by the end of this month.

Keeping ni?.

Comment 8

[Honza Bambas (:mayhemer)]

No time to work on this soon.

Comment 9

[Valentin Gosu [:valentin] (he/him)]

This is blocking socket process, being the last consumer of DeprecatedSyncResolve.

Comment 10

[Valentin Gosu [:valentin] (he/him)]

I need to look into how difficult it is to refactor this.

Comment 11

[Valentin Gosu [:valentin] (he/him)]

It's not very clear why this bug was happening, but there are two possibilities:

1. It was happening because of the call to DeprecatedSyncResolve on the main thread.
2. It was happening because of the call to AcquireCredentialsHandleW was taking too long (also on the main thread)

For both of these, the solution would be to implement GenerateCredentialsAsync for nsHttpNTLMAuth.
The simple way to implement it would be to dispatch a task to the background thread that resolves the cname for the host, then calls nsAuthSSPI::Init on the same background thread.

The main problem with this is there is no code coverage for this.
Since this is using the windows SSPI functions, can't really hit this in automation. I've looked into creating a kerberos server in a VM, but it's not trivial. Another approach would be to have a dummy shim for the SecurityFunctionTableW structure for testing.

Comment 12

[Valentin Gosu [:valentin] (he/him)]

Attachment: WIP: Bug 1394752 - Add nsIAuthModule::AsyncInit method r=#necko

Comment 13

[Valentin Gosu [:valentin] (he/him)]

Attachment: WIP: Bug 1394752 - make pref static r=#necko

Depends on D142161

Comment 14

[Florian Bender]

Do you still need logs from me?

Comment 15

[Kershaw Chang [:kershaw]]

(In reply to Florian Bender from comment #14)

Do you still need logs from me?

Yes, I think so. Could you send the log to necko at mozilla dot com?
Thanks.

Comment 16

[Florian Bender]

Copy I'll see what I can do, will take a few days.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.