unknown network traffic

[Giorgio Maone]

However I can change the code to use the brackets only with IPv6 addresses in next dev build, maybe it will help.

Done in latest development build.

[Giorgio Maone]

May be you can include an option to specify possible WAN IPs as comma separated list of network/netmask (which gets included in LOCAL).

That's a good idea, indeed.

Done in latest development build

[dinoex]

When no HTTP-server is running on the WAN-IP, noscript 2.0.0 and 2.0.1 does not
handle this well, it forces the browser to use 100% CPU load.

[Giorgio Maone]

When no HTTP-server is running on the WAN-IP, noscript 2.0.0 and 2.0.1 does not
handle this well, it forces the browser to use 100% CPU load.

I tested both with a non-routable IP and with a reachable IP which had no service on port 80, and they're working just fine.
These are fairly common setups, especially if you've got a modem instead of the router, so if they were problematic I should have tons of reports, not just yours.
Is there anything else I should know about your configuration?
Did you try Standard Diagnostic to exclude an extensions conflict?
Could you use a packet sniffer or (easier) the HttpFox add-on for Firefox in order to check whether fast-repeating requests are made by NoScript in your setup?

[GµårÐïåñ]

I am slightly late to the party here but wanted to say a few words if you don't mind.

1) I think the fingerprinting branding of the UA is a great idea to provide more meaningful server log entries and also to continue providing the intended benefit by NoScript.

2) I didn't realize that this would cause a request through svchost and my firewall actually fully blocks all requests made to a GoDaddy server originating from the _OS_ but not in the browser.

So question
A) Does this external ip detection using GoDaddy go through the svchost or through the browser's internal core? Meaning piggy backing on the already allowed traffic of the browser through the firewall.

B) If inside the browser, then I am fine, since that is configured using the Browser rules configuration, but if using svchost (OS level), then there is a 100% chance its being blocked, how will that adversely affect NoScript's ability to properly function and secure if it can't obtain the external ip? and furthermore is there a specific ip for your server (even if hosted by godaddy) that I can specifically open for NoScript usages only whilst blocking the rest of the ranges.

Thanks in advance and again sorry for coming into the discussion late and asking now, but Giorgio you know why. Thanks again.

[Giorgio Maone]

A) Does this external ip detection using GoDaddy go through the svchost or through the browser's internal core? Meaning piggy backing on the already allowed traffic of the browser through the firewall.

The external IP detection does not "use GoDadday". It uses my own dedicated servers (3 at this moment, load balanced through a DNS round robin) which respond to https://secure.informaction.com/ipecho
A GoDaddy server is contacted by Firefox to validate the SSL certificate of secure.informaction.com, like it does for any certificate released by GoDaddy's CA.
This means that both the requests (the primary one to secure.informaction.com and the secondary SSL validating one to oscp.godaddy.com) are made by Firefox and are subject to the same (likely less restrictive) rules of any other web browser request.

B) If inside the browser, then I am fine, since that is configured using the Browser rules configuration, but if using svchost (OS level), then there is a 100% chance its being blocked, how will that adversely affect NoScript's ability to properly function and secure if it can't obtain the external ip? and furthermore is there a specific ip for your server (even if hosted by godaddy) that I can specifically open for NoScript usages only whilst blocking the rest of the ranges.

As I said above, those requests are unlikely to be blocked (otherwise your browser would probably be disfunctional and you couldn't install any XPI from the noscript.net direct links).
You can easily verify whether this feature is working by opening NoScript Options|Advanced|ABE and checking the detected IP on the top right.
Anyway the secure.informaction.com IPs (which are not hosted by GoDaddy, see above) are 82.103.140.42, 82.103.139.52 and 82.103.140.40.

[GµårÐïåñ]

The external IP detection does not "use GoDadday". It uses my own dedicated servers (3 at this moment, load balanced through a DNS round robin) which respond to https://secure.informaction.com/ipecho
A GoDaddy server is contacted by Firefox to validate the SSL certificate of secure.informaction.com, like it does for any certificate released by GoDaddy's CA.
This means that both the requests (the primary one to secure.informaction.com and the secondary SSL validating one to oscp.godaddy.com) are made by Firefox and are subject to the same (likely less restrictive) rules of any other web browser request.

Thanks for that clarification, I did misunderstand a couple of things (like the fact that your server is hosted with GoDaddy when in fact its just the CA being certified by them) and (the fact that Fx is initiating the contact to GoDaddy and not NS) thanks for those clarifications. It seems consistent with my initial feeling that as long as they are being initiated through Fx, they are functioning and not being blocked by OS level rules. Can you just verify for me something, IF, and I mean IF, the fingerprinting if you will fails, what would happen with NS? Meaning, will it produce an error or something and give the user a warning that it failed to contact the server to get the information needed?

As I said above, those requests are unlikely to be blocked (otherwise your browser would probably be disfunctional and you couldn't install any XPI from the noscript.net direct links).
You can easily verify whether this feature is working by opening NoScript Options|Advanced|ABE and checking the detected IP on the top right.
Anyway the secure.informaction.com IPs (which are not hosted by GoDaddy, see above) are 82.103.140.42, 82.103.139.52 and 82.103.140.40.

Yes you made that clear, thank you very much. Thank you sir, for the time to give me a response, that is appreciated.

[ammdispose]

Thank you for quick updates!

I have disabled WAN IP LOCAL option but added my subnet as 1.2.0.0/16 3.4.0.0/16 in noscript.ABE.localExtras.

Now how do I actually know that I am safe from those attacks? Is there any test page?

Thanks in advance.

[dinoex]

When no HTTP-server is running on the WAN-IP, noscript 2.0.0 and 2.0.1 does not
handle this well, it forces the browser to use 100% CPU load.

I tested both with a non-routable IP and with a reachable IP which had no service on port 80, and they're working just fine.
These are fairly common setups, especially if you've got a modem instead of the router, so if they were problematic I should have tons of reports, not just yours.
Is there anything else I should know about your configuration?
Did you try Standard Diagnostic to exclude an extensions conflict?
Could you use a packet sniffer or (easier) the HttpFox add-on for Firefox in order to check whether fast-repeating requests are made by NoScript in your setup?

I verified this with tcpdump, an plain HTTP GET request to http://<ipadd>/ is made every couple of minutes, disabling noscript made it vanish.
With noscript enabled and the disabling "WAN-IP LOCAL"everything works fine.

"WAN-IP LOCAL" enabled, the HTTP GET request are made,
No problem if an HTTP services is responding.
When I stop HTTP services, Firefox will go to 100% CPU load, slowing down till its almost unusable.
Special: the PC has multiple IPv4 addresses on the WAN interface and IPV6 addresses too.

[dinoex]

It is a bug in FireFix itself.
It does happens with ervery connection to localhost that is closed.

See:

https://bugzilla.mozilla.org/show_bug.cgi?id=595823

[Arne]

I have this problem, at least it seems very likely.

and now: Enable noscript = 100% cpu load
Disable noscript, 2-4 % cpu load

It may be a firefox bug, but noscript certainly triggers it

[Giorgio Maone]

It may be a firefox bug, but noscript certainly triggers it

You can work-around by unchecking the WAN IP box in NoScript Options|Advanced|ABE as explained above.
BTW, could anybody check whether it's fixed on trunk or on a recent Firefox 4 beta?

[Arne]

Works like a charm!

Oh Joy

Thank you for the very swift reply

[InitD]

Having an issue tied into NoScript with a 302 redirect certs being downloaded from other than Maone's.
I have included the packets. Discussion began at Wilder's.
http://www.wilderssecurity.com/showthre ... ost1824129

Do these, 69.195.141.179,69.195.141.178, belong to you?

Code: Select all

Noscript TLSv1 conversation.

Now,

HTTP/1.1
    Host: xx.xxx.xxx.xx\r\n
    User-Agent: Mozilla/5.0 (ABE, http://noscript.net/abe/wan)\r\n
    Pragma: no-cache\r\n
    Cache-Control: no-cache\r\n
    \r\n

HTTP/1.0 302 Redirect\r\n
        [Expert Info (Chat/Sequence): HTTP/1.0 302 Redirect\r\n]
            [Message: HTTP/1.0 302 Redirect\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Version: HTTP/1.0
        Response Code: 302
    Server: GoAhead-Webs\r\n
    Date: Mon Jan 31 13:28:19 2011\r\n
    Pragma: no-cache\r\n
    Cache-Control: no-cache\r\n
    Content-Type: text/html\r\n
    Location: http://xx.xxx.xxx.xx/htmlV/welcomeMain.htm\r\n
    \r\n
Line-based text data: text/html
    <html><head></head><body>\r\n
    \t\tThis document has moved to a new <a href="http://xx.xxx.xxx.xx/htmlV/welcomeMain.htm">location</a>.\r\n
    \t\tPlease update your documents to reflect the new location.\r\n
    \t\t</body></html>\r\n
    \r\n

GET /htmlV/welcomeMain.htm HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): GET /htmlV/welcomeMain.htm HTTP/1.1\r\n]
            [Message: GET /htmlV/welcomeMain.htm HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: GET
        Request URI: /htmlV/welcomeMain.htm
        Request Version: HTTP/1.1
    Host: xx.xxx.xxx.xx\r\n
    User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102814 Ubuntu/8.10 (intrepid) Firefox/3.0.15\r\n
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
    Accept-Language: en-us,en;q=0.5\r\n
    Accept-Encoding: gzip,deflate\r\n
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
    Keep-Alive: 300\r\n
    Connection: keep-alive\r\n
    Pragma: no-cache\r\n
    Cache-Control: no-cache\r\n
    \r\n

Hypertext Transfer Protocol
    HTTP/1.0 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.0 200 OK\r\n]
            [Message: HTTP/1.0 200 OK\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Version: HTTP/1.0
        Response Code: 200
    Date: Mon Jan 31 13:28:19 2011\r\n
    Server: GoAhead-Webs\r\n
    Last-modified: Fri Oct 24 16:24:45 2008\r\n
    Content-length: 650\r\n
        [Content length: 650]
    Content-type: text/html\r\n
    \r\n
Line-based text data: text/html
    <HTML>\n
    <HEAD>\n
    <TITLE>Vendor name was here</TITLE>\n
    <META http-equiv="PRAGMA" content="NO-CACHE"></META>\n
    </HEAD>\n
    <script language="JavaScript">\n
    function resizeFix()\n
    {\n
    if(document.layers)\n
    {\n
    if(window.innerWidth!=origWidth||window.innerHeight!=origHeight)\n
    {\n
    window.view_frame.location.reload();\n
    }\n
    }\n
    }\n
    var showWacp=-1\n
    var theSearch=document.location.search;\n
    var theTag="?wacp=true";\n
    showWacp=theSearch.indexOf(theTag);\n
    </SCRIPT>\n
    <FRAMESET ROWS="*,0" border=0 onResize="resizeFix();">\n
    <FRAME SRC="index.asp" name="view_frame">\n
    <FRAME SRC="indexHidden.asp" name="hidden_frame" scrolling="no" noresize>\n
    </FRAMESET>\n
    <!-- Copyright (c)1999 - 2002 Router Device, Inc. -->\n
    </HTML>\n

Cert addresses retrieved from DNS:

Code: Select all

A 69.195.141.179
   A 82.103.140.42
   A 82.103.139.52
   A 82.103.140.40
   A 69.195.141.178
..............
Source: 192.168.1.10 (192.168.1.10)
    Destination: 69.195.141.179 (69.195.141.179)
Transmission Control Protocol, Src Port: 43315 (43315), Dst Port: https (443)

Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 163
            Version: TLS 1.0 (0x0301)

Source: 69.195.141.179 (69.195.141.179)
    Destination: 192.168.1.10 (192.168.1.10)
ource port: https (443)
    Destination port: 43315 (43315)

00e0  41 72 69 7a 6f 6e 61 31 13 30 11 06 03 55 04 07   Arizona1.0...U..
00f0  13 0a 53 63 6f 74 74 73 64 61 6c 65 31 1a 30 18   ..Scottsdale1.0.
0100  06 03 55 04 0a 13 11 47 6f 44 61 64 64 79 2e 63   ..U....GoDaddy.c
0110  6f 6d 2c 20 49 6e 63 2e 31 33 30 31 06 03 55 04   om, Inc.1301..U.
0120  0b 13 2a 68 74 74 70 3a 2f 2f 63 65 72 74 69 66   ..*http://certif
0130  69 63 61 74 65 73 2e 67 6f 64 61 64 64 79 2e 63   icates.godaddy.c
0140  6f 6d 2f 72 65 70 6f 73 69 74 6f 72 79 31 30 30   om/repository100

[Giorgio Maone]

Do these, 69.195.141.179,69.195.141.178, belong to you?

Yes, they do.