NoScript makes requests to sync-messages.invalid

Using the latest Tor Browser release 9.0.1, my Tor gateway machine's log is full of messages like this:

Nov 19 21:27:11.000 [notice] Have tried resolving or connecting to address 'sync-messages.invalid' at 3 different places. Giving up.

I think this started in 9.0, but I am not sure.

A web search found only that it seems to be an upstream problem in NoScript:

https://forums.informaction.com/viewtopic.php?t=25779

I have not personally verified that NoScript is the culprit. Just reporting what I saw so you can track the issue and make sure to get the patched version from upstream, if/as necessary.

added component::applications/tor browser noscript owner::tbb-team priority::medium severity::normal status::reopened type::defect labels

Hi, cypherpunks! Now that 11.0.9 is out, update and enjoy connections to 255.255.255.255 :) https://forums.informaction.com/viewtopic.php?f=8&t=25801

ma1: are you aware of this one?

Trac:
Keywords: N/A deleted, noscript added
Status: new to needs_information
Cc: N/A to ma1

Replying to pili:

ma1: are you aware of this one?

Of course I am, see https://github.com/hackademix/noscript/blob/11.0.9/src/lib/SyncMessage.js#L3

Even though this is innocuous ( https://en.wikipedia.org/wiki/.invalid ), it shouldn't normally happen, because those requests are intercepted by our webRequest listener and redirected to a data: URL before (pointless) DNS resolution attempts. I suppose a content script is triggering the request before the listener is ready to answer, or we're watching speculative resolution.

Regarding "connections to 255.255.255.255", did you actually see any?

TypeError: aNode is null CustomizableUI.jsm:1984:5

in NoScript Options on Windows.

Replying to cypherpunks:

{{{ TypeError: aNode is null CustomizableUI.jsm:1984:5 }}} in NoScript Options on Windows.

This has nothing to do with this issue, and it's probably related with Tor Browser 9.x hiding NoScript's toolbar button. Please open another bug report, especially if this causes also some visible disruption.

This is an rc2 regression, and NoScript's toolbar button is not hidden. Regarding "connections to 255.255.255.255", there are some only in the form of:

Torbutton INFO: tor SOCKS: https://255.255.255.255/moz-extension://[NoScript's ID]%2Chttps%3A%2F%2Fnoscript.net%2Ffaq%23xss&url=https%3A%2F%2Fnoscript.net%2Ffaq%23xss&top=true&suspend=true via
                       noscript.net:0cec41452469595899f79ad4252b03b5

ma1: #32536 (moved)

Looks like noscript-csp.invalid is still interfering/messing with CSP:

[11-22 09:47:42] Torbutton INFO: tor SOCKS: https://noscript-csp.invalid/__NoScript_Probe__/ via
                       torproject.org:602f1e2c568ce366b5800e14a4383d41
Content Security Policy: The page’s settings blocked the loading of a resource at https://blog.torproject.org/sites/default/files/js/js.js (“script-src”).

Replying to cypherpunks:

Looks like noscript-csp.invalid is still interfering/messing with CSP: {{{ [11-22 09:47:42] Torbutton INFO: tor SOCKS: https://noscript-csp.invalid/NoScript_Probe/ via torproject.org:602f1e2c568ce366b5800e14a4383d41 Content Security Policy: The page’s settings blocked the loading of a resource at https://blog.torproject.org/sites/default/files/js/js.js (“script-src”). }}} No interfering/messing here. That's the intended behavior. It's used to intercept and take note of any CSP violation in order to buy the UI when it's time (and again, these CSP reports won't reach the network anyway). This is likely going to be replaced with a securitypolicyviolation in the content script, now that's available on ESR as well.

What is the intended behavior? That every message about blocked by NoScript script on the Safest level is complemented with the two mentioned above?

Regarding "connections to 255.255.255.255", did you actually see any? Yes, #32536 (moved) is bombarding the tor network at 1/2 sec rate.

I believe we're still waiting for some steps to reproduce the original issue here (requests to sync-messages.invalid)

I think those messages are gone since 11.0.9 (see: https://github.com/hackademix/noscript/commit/53bf224e84f89fd2a66afe6461ef09b555751584).

Trac:
Resolution: N/A to fixed
Status: needs_information to closed

Oh, and while I am at it: the requests to 255.255.255.255 are not reaching tor. In fact the respective channels are suspended and never resumed before http-on-before-connect is called. (I've not verified that but I suspect the channel classifier could be responsible for that as that one is running between the suspension and the resumption). Thus, that's another case where the Torbutton log output might mislead if not treated with care.

I think those messages are gone since 11.0.9 Of course, they are. And that's why it's fixed. Hilarious!

the requests to 255.255.255.255 are not reaching tor Sure? (See #32536 (moved))

Thus, that's another case where the Torbutton log output might mislead if not treated with care. Torbutton log on Tor gateway machine? Even more hilarious!

gk has gone, the bug doesn't.

Trac:
Resolution: fixed to N/A
Status: closed to reopened

Replying to cypherpunks:

gk has gone, the bug doesn't.

I am not gone, no worries. That said, there is no code anymore in 11.0.13 containing sync-messages.invalid and previously it got commented out. So, there seems to be no way to me that you can hit this with a recent NoScript.

For the other case, see comment:14.

Trac:
Resolution: N/A to fixed
Status: reopened to closed

You're gone from fixing TBB bugs ;) sync-messages.invalid was replaced by 255.255.255.255. So, see comment:15.

Trac:
Resolution: fixed to N/A
Status: closed to reopened

moved to tpo/applications/tor-browser#32549 (closed)