Opened 16 months ago

Closed 6 weeks ago

Last modified 5 weeks ago

#27307 closed defect (fixed)

NoScript marks HTTP Onion as insecure

Reported by: cypherpunks3 Owned by: tbb-team
Priority: Low Milestone:
Component: Applications/Tor Browser Version:
Severity: Minor Keywords: noscript, TorBrowserTeam201910
Cc: gk, pospeselr, ma1, micahlee Actual Points:
Parent ID: #21728 Points:
Reviewer: Sponsor:

Description

  1. Open Tor Browser 8.0a9 or higher.
  1. Go to some HTTP Onion like http://yjuwkcxlgo7f7o6s.onion/ (archive.tp, see onion.tp)
  1. Click on the NoScript icon, the popup will show you yjuwkcxlgo7f7o6s.onion in red (contrary to some HTTPS Onion like https://3g2upl4pq6kufc4m.onion/ (DDG Onion))

(Not sure if there's something needed on the browser side so that's why I'm setting the component as TB though this is probably entirely a NoScript issue)

Child Tickets

Change History (16)

comment:1 Changed 16 months ago by cypherpunks3

PS: Just to be clear, I'm not calling for JS to be enabled for HTTP onions on Safer security setting in this ticket, only that ALL onions should be marked as secure in the NoScript UI.

comment:2 in reply to:  1 ; Changed 16 months ago by gk

Resolution: wontfix
Status: newclosed

Replying to cypherpunks3:

PS: Just to be clear, I'm not calling for JS to be enabled for HTTP onions on Safer security setting in this ticket, only that ALL onions should be marked as secure in the NoScript UI.

That's a good thing to bring up with the NoScript dev but it is nothing we'll fix in Tor Browser ourselves.

comment:3 Changed 16 months ago by traumschule

Keywords: noscript added

comment:4 in reply to:  2 ; Changed 16 months ago by ma1

Replying to gk:

Replying to cypherpunks3:

PS: Just to be clear, I'm not calling for JS to be enabled for HTTP onions on Safer security setting in this ticket, only that ALL onions should be marked as secure in the NoScript UI.

That's a good thing to bring up with the NoScript dev but it is nothing we'll fix in Tor Browser ourselves.

I think it might be a good idea, but only if I've got a sure-fire way to tell NoScript is running inside the Tor browser.

> console.log(await browser.runtime.getBrowserInfo())

Object { name: "Firefox", vendor: "Mozilla", version: "60.1.0", buildID: "20180204020101" }

Maybe you could send an "isTorBrowser: true" additional property within your updateSettings messages.

Any better suggestion?

comment:5 in reply to:  4 Changed 16 months ago by gk

Replying to ma1:

Replying to gk:

Replying to cypherpunks3:

PS: Just to be clear, I'm not calling for JS to be enabled for HTTP onions on Safer security setting in this ticket, only that ALL onions should be marked as secure in the NoScript UI.

That's a good thing to bring up with the NoScript dev but it is nothing we'll fix in Tor Browser ourselves.

I think it might be a good idea, but only if I've got a sure-fire way to tell NoScript is running inside the Tor browser.

> console.log(await browser.runtime.getBrowserInfo())

Object { name: "Firefox", vendor: "Mozilla", version: "60.1.0", buildID: "20180204020101" }

Maybe you could send an "isTorBrowser: true" additional property within your updateSettings messages.

Any better suggestion?

Not sure yet, but I filed #27313 to help with that.

comment:6 Changed 2 months ago by ma1

It should have been fixed in NoScript 11.0.4rc11 :)

comment:7 in reply to:  6 ; Changed 2 months ago by gk

Replying to ma1:

It should have been fixed in NoScript 11.0.4rc11 :)

Thanks, that's better. There is still the scary http: in red which should not be relevant for .onions either. Additionally, the expectation here is that onions over http:// on medium level security can actually run JavaScript etc. because http:// is secure for .onion domains They should get treated as loaded over https://. Could you address those two items for Tor Browser users? (I am fine opening a new bug for the latter if you like)

A general note, while testing rc11:

1) After installing it in the browser I needed to click twice on the NoScript icon until the page related info showed up. On first click only a small empty menu was visible.
2) After restarting the browser it takes like 5-10 second until the NoScript icon gets clickable at all and CPU of my laptop gets eaten meanwhile. There is something computationally heavy going on in the background here...

comment:8 in reply to:  7 ; Changed 7 weeks ago by ma1

Replying to gk:

There is still the scary http: in red which should not be relevant for .onions either. Additionally, the expectation here is that onions over http:// on medium level security can actually run JavaScript etc. because http:// is secure for .onion domains They should get treated as loaded over https://. Could you address those two items for Tor Browser users? (I am fine opening a new bug for the latter if you like)

Not sure if you opened another bug (if you did, sorry for the cross-posting): I've addressed this in https://github.com/hackademix/noscript/releases/tag/11.0.4rc15

comment:9 in reply to:  8 Changed 7 weeks ago by gk

Keywords: TorBrowserTeam201910R added
Resolution: wontfix
Status: closedreopened

Replying to ma1:

Replying to gk:

There is still the scary http: in red which should not be relevant for .onions either. Additionally, the expectation here is that onions over http:// on medium level security can actually run JavaScript etc. because http:// is secure for .onion domains They should get treated as loaded over https://. Could you address those two items for Tor Browser users? (I am fine opening a new bug for the latter if you like)

Not sure if you opened another bug (if you did, sorry for the cross-posting): I've addressed this in https://github.com/hackademix/noscript/releases/tag/11.0.4rc15

No, I did not as I actually found an already open ticket for that: #21004.

comment:10 Changed 7 weeks ago by gk

Cc: micahlee added
Parent ID: #21728

comment:11 in reply to:  8 Changed 6 weeks ago by gk

Replying to ma1:

Replying to gk:

There is still the scary http: in red which should not be relevant for .onions either. Additionally, the expectation here is that onions over http:// on medium level security can actually run JavaScript etc. because http:// is secure for .onion domains They should get treated as loaded over https://. Could you address those two items for Tor Browser users? (I am fine opening a new bug for the latter if you like)

Not sure if you opened another bug (if you did, sorry for the cross-posting): I've addressed this in https://github.com/hackademix/noscript/releases/tag/11.0.4rc15

Seems to work nicely, thanks! FWIW: I can still see the problem mentioned in comment:9:ticket:27313 that the NoScript settings show only up every other time after updating the NoScript version in the browser. Pasting here my STR for convenience:

Here is what I did
1) Take a Tor Browser 9.5a1 (​https://www.torproject.org/download/alpha/) (I took a sv-SE one).
2) Open this ticket
3) Open in a new tab the link to rc15
4) Install rc15 into Tor Browser
5) Add the NoScript button to the toolbar
6) The bug as described is visible: the NoScript menu contents are shown only every other click on the icon (otherwise the menu is empty). A restart seems to fix that, though.

Last edited 6 weeks ago by gk (previous) (diff)

comment:12 Changed 6 weeks ago by gk

Keywords: TorBrowserTeam201910 added; TorBrowserTeam201910R removed
Status: reopenedneeds_information

Okay, I managed to reproduce my other issue as well: the start-up of rc15 is extremely slow on higher security levels. E.g. on my machine there is a gap of almost 10 seconds between the first two messages:

[10-29 14:15:22] Torbutton INFO: Message received from NoScript: [{"__meta":{"name":"collect","recipientInfo":{"tabId":1,"frameId":0}},"_messageName":"collect"},{"id":"{73a6fe31-595d-460b-a920-fcc0f8843232}","url":"moz-extension://07d31867-b62c-4014-aa90-56981c414124/_generated_background_page.html","envType":"addon_child","extensionId":"{73a6fe31-595d-460b-a920-fcc0f8843232}","contextId":274877906946},null]

and

[10-29 14:15:31] Torbutton INFO: Message received from NoScript: [{"__meta":{"name":"started","recipientInfo":null},"_messageName":"started"},{"id":"{73a6fe31-595d-460b-a920-fcc0f8843232}","url":"moz-extension://07d31867-b62c-4014-aa90-56981c414124/_generated_background_page.html","envType":"addon_child","extensionId":"{73a6fe31-595d-460b-a920-fcc0f8843232}","contextId":274877906946},null]

which makes me a bit nervous given that the user can meanwhile surf the web but the security settings are set only after the started or pageshow` one.

I suspect that's because of #23719, actually. I wonder whether stable users would be hitting the bug on the standard mode, too, given that WASM is disabled there as well. ma1: What kind of JIT/WASM parts are you using for the initial loading of NoScript's state that could cause this?

comment:13 Changed 6 weeks ago by gk

Resolution: fixed
Status: needs_informationclosed

Fixed with the bump to 11.0.4 (commit 6cbbd55840577c4d3ab5581e76cffde26a5f5ff6 and 8623975e60c99b2a526bbda133168d7de5f8d329 on tor-browser-build's maint-9.0 and master branches), thanks!

The issues mentioned in my two previous comments are still visible, though.

comment:14 in reply to:  13 ; Changed 6 weeks ago by ma1

Replying to gk:

The issues mentioned in my two previous comments are still visible, though.

Can you still reproduce them with 11.0.6 (current stable)?

comment:15 in reply to:  14 Changed 6 weeks ago by gk

Replying to ma1:

Replying to gk:

The issues mentioned in my two previous comments are still visible, though.

Can you still reproduce them with 11.0.6 (current stable)?

In fact with 11.0.7rc1, yes, although the one in comment:12 seems to have gotten a bit better (i.e. the started message seems to arrive earlier now).

comment:16 in reply to:  12 Changed 5 weeks ago by gk

Replying to gk:

Okay, I managed to reproduce my other issue as well: the start-up of rc15 is extremely slow on higher security levels. E.g. on my machine there is a gap of almost 10 seconds between the first two messages:

[10-29 14:15:22] Torbutton INFO: Message received from NoScript: [{"__meta":{"name":"collect","recipientInfo":{"tabId":1,"frameId":0}},"_messageName":"collect"},{"id":"{73a6fe31-595d-460b-a920-fcc0f8843232}","url":"moz-extension://07d31867-b62c-4014-aa90-56981c414124/_generated_background_page.html","envType":"addon_child","extensionId":"{73a6fe31-595d-460b-a920-fcc0f8843232}","contextId":274877906946},null]

and

[10-29 14:15:31] Torbutton INFO: Message received from NoScript: [{"__meta":{"name":"started","recipientInfo":null},"_messageName":"started"},{"id":"{73a6fe31-595d-460b-a920-fcc0f8843232}","url":"moz-extension://07d31867-b62c-4014-aa90-56981c414124/_generated_background_page.html","envType":"addon_child","extensionId":"{73a6fe31-595d-460b-a920-fcc0f8843232}","contextId":274877906946},null]

which makes me a bit nervous given that the user can meanwhile surf the web but the security settings are set only after the started or pageshow` one.

I suspect that's because of #23719, actually. I wonder whether stable users would be hitting the bug on the standard mode, too, given that WASM is disabled there as well. ma1: What kind of JIT/WASM parts are you using for the initial loading of NoScript's state that could cause this?

Actually that issue is solved with 11.0.7 for me. However, the options button is still behaving funky. Part of that is #23719 but other parts not. I've opened #32403 for the latter.

Note: See TracTickets for help on using tickets.