Amazon product pages giving redirection error

RESOLVED FIXED

Status

Tech Evangelism
Desktop
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Caspy7, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [country-all] [sitewait] [http], URL)

(Reporter)

Description

2 years ago
We've had at least three users reporting that Amazon product pages are giving constant errors.  They appear to be internal Firefox errors that read:
> The page isn't redirecting properly
> Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
> This problem can sometimes be caused by disabling or refusing to accept cookies.

Here are the three reports I know of:
https://support.mozilla.org/en-US/questions/1124338?page=2#answer-884630
https://www.reddit.com/r/firefox/comments/4mrc5l/amazon_product_links_dont_load/
https://www.reddit.com/r/firefox/comments/4mwi6d/amazon_isnt_redirecting_properly/

After extensive troubleshooting the first two were resolved by deleting SiteSecurityServiceState.txt from the profile folder. The third found the amazon line in the file, removed it and the problem went away.  Here is the offending line:

www.amazon.com:HSTS	2	16959	1496378978047,1,1

I'm guessing there are others with this unresolved recurring problem.
(Reporter)

Comment 1

2 years ago
Drew, would you be able to have a look at this?
Flags: needinfo?(stamps)

Comment 2

2 years ago
For helping with the debugging on Amazon side, Caspy7 could you explain what SiteSecurityServiceState.txt does? When it is set. Thanks.
Flags: needinfo?(caspy77)
Whiteboard: [country-all] [sitewait] [http]
(Reporter)

Comment 3

2 years ago
Honestly, this area is not my expertise. I'm mostly just winging my understanding.

As I understand Firefox saves HSTS information in SiteSecurityServiceState.txt. I don't know much more than that.

I'll solicit others and folks in #security to chime in if there's more to say.
Flags: needinfo?(caspy77)
SiteSecurityServiceState.txt is where the browser stores information on the HSTS and HPKP headers sent by the sites
https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security

I'm not sure what we're storing in the first two numbers. The third is the expiration date (based on a header sent to us by the site in the past) and in this case is June 8. Not sure what the next "1" is, but the final one is the value for includeSubDomains -- in this case "true". Possibly something is trying to load an http: url from a sub-domain that doesn't have the same content on https and that's causing the failure.

It is very easy for sites to DOS themselves by sending bad values for either of the HSTS or HPKP headers. We do our best to avoid problems by making sure to honor those headers only if we know it's a working setting for that site. Setting the includeSubDomains option is where sites can get themselves into trouble because we can only test the site you're on, not all possible sub-domain names.

Comment 5

2 years ago
I'll open an internal issue here at Amazon and see if I can route it to an appropriate resolver.
Flags: needinfo?(stamps)

Comment 6

2 years ago
Is there any Firefox logging that would give insight into the request/response that was the source of the header values in SiteSecurityServiceState.txt?

The presence of these state values is unexpected.
Flags: needinfo?(dveditz)
There's no historical logging you can inspect on machines already in that state. It looks like you can turn on debug logging if that helps, although you might need an actual debug build for it (I got no output).

export MOZ_LOG=nsSSService:5
export MOZ_LOG_FILE=/tmp/moz.log
<launch firefox>

keeler: is the above correct? does it require a debug build?
Flags: needinfo?(dveditz) → needinfo?(dkeeler)
Ah, it's MOZ_LOG_MODULES=nsSSService:5 -- the shorter MOZ_LOG only works on recent nightlies but hasn't made it to release yet.
Flags: needinfo?(dkeeler)

Comment 9

2 years ago
Thank you.

My understanding is that the immediate issue that was causing Amazon product pages to be effectively unreachable (infinite redirect) should be resolved.
This seems to be fixed indeed.
Thanks a lot Drew.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.