1873173 - NEUP site gets stuck in redirect loop related to ssl token cache

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P2)

Description

[Kestrel]

STR:

1. Visit neup.inl.gov.

Gets stuck in a redirect loop:

The page isn’t redirecting properly

Also fails when directly visiting destination https://neup.inl.gov/SitePages/Home.aspx.

Works after changing network.ssl_tokens_cache_enabled = false on 2020-03-18 build (pref removed in version 107 by Bug 1720118).

Works with Chromium.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7c83f04c82e9ef6c1d2823a64aedd34a79a90eb9&tochange=737aba43bfa1685fa15a9b542636b959397603a8

Regressed by Bug 1607257.

Comment 1

[Donal Meehan [:dmeehan]]

Adding a ni on :kershaw, since you are the author of the regressor Bug 1607257.

Comment 2

[Kershaw Chang [:kershaw]]

I am not sure how this is related to the token cache. When I enabled the SSLTokensCache logging, I observed that no tokens were stored. The only thing I know is that the redirection loop is caused by the server continually returning 302 for some resources.

Dana, do you probably have an idea here?
Thanks.

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler]]

The behavior difference I'm seeing between Firefox and Chrome is that Firefox uses a new session ID for each client hello, whereas Chrome uses the same one once it has completed a handshake with the server. I don't see anything in the spec that says a client must use a session ID provided by the server, but I imagine what's going on is the server is (intentionally or not) only handing out the actual URL for the resources requested once a client uses a session ID provided by the server.

Comment 4

[Kershaw Chang [:kershaw]]

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #3)

The behavior difference I'm seeing between Firefox and Chrome is that Firefox uses a new session ID for each client hello, whereas Chrome uses the same one once it has completed a handshake with the server. I don't see anything in the spec that says a client must use a session ID provided by the server, but I imagine what's going on is the server is (intentionally or not) only handing out the actual URL for the resources requested once a client uses a session ID provided by the server.

Thanks, Dana. I've observed the same thing: the only difference between Chrome and Firefox is session id.

Since session id is not decided in necko, I'd like to change the component to NSS and let others to investigate.

Comment 5

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

The severity field is not set for this bug.
:beurdouche, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Dennis Jackson]

I investigated this bug, some findings:

Pre-TLS13 there are two distinct resumption methods - via session IDs or via session tickets. The latter is supported by the Session Cache in Firefox. When this work was undertaken back in 2019, NSS was configured to never cache session IDs if a session ticket handler was configured. I believe this was the right choice, since session ID resumption is a strictly optional feature, was removed entirely in TLS1.3 and little used before then.

This particular website appears to be insisting that clients support session ID caching, whether as some kind of misconfigured server, web application firewall or some other unknown purpose. However, this seems to be a webcompat bug rather than any kind of flaw in NSS or in Firefox. I'm going to shift this over to the WebCompat component.

Comment 7

[Bob Hood [:bhood]]

Dennis, can we please get Priority/Severity settings applied to this report?

Comment 8

[Dennis Jackson]

Unless we become aware of further reports, I don't believe this is a priority.

Comment 9

[Dennis Schubert [:denschub]]

It's completely broken in Firefox, and a somewhat popular site, so let's P2 this for now. This is in the WebCompat component, so we should at least try to reach out to them.

By the way, Bob, we're currently going through the backlog of all our issues (and triaging new issues) every Monday, so we'll get to all reports eventually. :)

Comment 10

[Dennis Jackson]

Whoops, name collision there. Sorry for not reading the needinfo more carefully!

Comment 11

[Dennis Schubert [:denschub]]

This seems to work now - they probably fixed their server config.