[RESOLVED] ABE blocks paid wifi hotspot access

[xheralt]

A local coffee shop I frequent uses the webbeams.com wifi access service; ABE objects when my normal homepage request is redirected to the webbeams login by the hotspot's access server. I'm a fairly ordinary user, I've never written a firewall rule, so the exhortation "It's just like that, it's simple!" is meaningless to me. How do I write an ABE rule to allow said redirect? The ABE manual is like a Linux manual -- it has all the facts neatly laid out, and tells non-gurus absolutely nothing. And given the sheer number of non-gurus like me who use NoScript out of security-consciousness, ABE represents a major complication to NoScript's former "It Just Works" mode.

[dhouwn]

The best way would be to temporally deactivate the ABE rule "SYSTEM" temporally since there is the rule blocking the redirect.

In the Noscript options:
Advanced tab → ABE tab → select SYSTEM in the listbox Rulesets → click Disable
after you authenticated successfully, do the same process again but this time click Enable

/update:
http://forums.informaction.com/viewtopi ... 408#p21408

[GµårÐïåñ]

Better way would be to setup a specific filter for this wifi hotspot. That's of course if you use it regularly enough to warrant it or if you know how to do it. If you post the authentication url, we can come up with a syntax for you and that's always preferable to messing with the system rule like that.

[someguy]

I'm not the OP but could somebody give a generic example of this kind of code? I have been temporarily disabling it when i use the free wifi at panera bread.

Also, could somebody give the code to create an exception for the opensource software Mediacoder? (see: http://www.mediacoderhq.com)

Thanks!

[GµårÐïåñ]

I am personally not going to write a generic anything, Giorgio can take a stab at that, but most of the time they are done differently and without URLs showing how they hook and authenticate, there is not going to be a generic filter that will be that good across the board. Also, personally I found mediacoder to not be that good and therefore don't have it installed anymore, so I can't help you with the exceptions for it without re-installing it. Maybe someone who has it installed can provide the XUL/local paths and we can come up with something. I found the dependence on the browser quite irritating.

[xheralt]

Sorry, I haven't managed to get both myself and my laptop into said coffeehouse until now. The redirect takes the form of:
https://rap.nnu.com/login?dst=http%3a%2f%2fyour_home_page.*

Would this be a SYSTEM or USER rule?

[GµårÐïåñ]

Neither. Since this is not using any kind of locally authenticated address, there would be no need for a system rule and since you can simply temp allow or permanent allow rap.nnu.com, no user rule needed either. I think some of the users are missing the point of ABE and making this more complicated than it needs to be. Even if you had a rule, you still would have to whitelist it permanently for the rule to take effect and unless rap.nnu.com is being accessed by other sites, having that one site whitelisted doesn't pose any issue that would need to be regulated by ABE since it only comes to play when you are in the cafe and need to authenticate to the wifi service.

[xheralt]

It is NOT a case of NoScript as-a-whole blocking this website, I'd be posting in a different thread otherwise; in spite of the gaps in my tech skill, I can distinguish at least that much. Javascript white- or black-listed for webbeams.com|rap.nnu.com MAKES NO DIFFERENCE.

The specific Firefox warning pop-up I'm getting, when I first attempt to connect to the cafe's wifi router is "GET{https://rap.nnu.com/login?dst=http%3a%2f%2fmy_home_page.} filtered by ABE <LOCAL>Deny". With ABE disable, the redirect occurs, I enter my purchase code and authenticate to the cafe's webbeams host, then ABE no longer cares. I could re-enable it, but usually don't bother, because I have to re-authenticate every hour on site.

It is the redirect action itself that ABE seems to be objecting to, not the specific address. Therefore, the problem is in the ruleset, which I don't know how to correct, and ABE does not appear to have a simple click-to-whitelist option! But on the other hand, I don't want to grant a blanket exception. Otherwise, I might as well leave ABE off and derive no benefit from it -- as I'm doing now. Which means the work spent developing ABE is going to waste, at least for me. And maybe for others who are encountering similar problems.

I have only the default SYSTEM rules and no USER rules (as I said, I don't know how to write them). If I write something like "ACCEPT from https://rap.nnu.com", at a wild guess, do I make it a SYSTEM rule? If I put it in as a USER rule, will the default SYSTEM settings override it? Or do the USER rule(s) take priority?

[GµårÐïåñ]

Ok, I see what's going on, it is then accessing a local resource or document to complete the setup. If you could please recreate the situation which prompts this error and then provide the full content of the error that is logged the in error console for it, which will give us more of the resources interaction, that way we can go ahead and setup a filter for you which would alleviate your problem.

In the meantime, not seeing the details, placing this rule in the beginning of the system ABE ruleset will resolve your issue:

Modify the existing rule:
Site LOCAL
Accept from LOCAL
Deny

To this:
Site LOCAL
Accept from LOCAL rap.nnu.com
Deny

this should fix your problem, but if you give more details we might be able to provide a more tailored rule for it. Let us know how it goes.

[Dikaiopolis]

I have been having the almost idential problem with that same URL used for authentication in a different coffee shop. But after the ABE failure, I keep getting other failures, even though I never connected, to wit:

api.del.icio.us:443 uses an invalid security certificate. The
certificate is only valid for rap.nnu.com

(Error_code: ssl_error_bad_cert_domain).

This sounds like a bug, but I have to admit: I do not understand how
such redirection is supposed to work, so I have to defer to some
expert's opinion (e.g. Maone's). But I do know that ever since ABE was
added, I have been unable to use WiFi in a great many coffee shops
without a sneaking suspicion, in shops where before I had no trouble.

Then again, there are some, like Peet's Coffee, where I have been
unable to establish a connection using Firefox ever since starting to
use NoScript.

But back to this specific problem: I suspect that the real problem is the way Tully's Coffee has decided
to do the redirection, and the problem is similar at many hot
spots. NoScript is calling many of their redirects security violations
(I get similar errors at Peet's Coffee, I have got into the habit of
establishing the connetion w/ Safari and only then using Firefox at
Peet's).

But this exact error is new.

The cert itself has: CN=O="rap.nnu.com", and, to my surprise,
Extenstion>Certificate Basic Constraints = "Critical\nIs not a
Certificate Authority".

What this could mean when Certificate>Issuer>CN = "Equifax Secure
Global eBusiness CA-1" is a mystery to me.

Now normally, I would just go ahead and fire up Safari and try to
establish the connection that way (then closing Safari and using
FFox): but the name "rap.nnu.com" does not sound familiar at all (
used to connect here regularly), nor does it sound suggestive of a
name Tully's would use. So I am going to forego connectivity this
time.

Of course, the big question, the meta question, is: how is the naive
user, the user who is not so technically savvy, supposed to know what
to do when such messages pop up? I see no guidance on the NoScript
website to help me make this decision, and I know more about HTML,
Javascript, DOM and the HTTP protocols than the average user.

[therube]

If you uninstall NoScript, do you still get the cert error?
If so, then that is not a NoScript issue.

[Dikaiopolis]

If you uninstall NoScript, do you still get the cert error?
If so, then that is not a NoScript issue.

Rube, who are you talking to? If to me, then my answer has to be: your conclusion is a non sequitur. It is a NoScript issue, because NoScript prevented me from establishing an IP address and connection. Then, when all those irritating little background tasks like Yahoo! Toolbar tried to get content, they could not.

Now that the browser reported this problem as a bad cert sounds like a browser bug rather than a NoScript bug. For it looks like it was the browser that got confused about which server/URL the cert is for. It wasn't for the URL the Toolbar was trying to get to, it was for an authentication server (presumably) named in the URL I gave. However, the reason it got confused is that NoScript prevented the authentication server from completing authentication and then getting out of the way. This, though, is why I still have doubt that we can call this a browser bug: it wasn't the browser that caused this bizarre state, in which the Yahoo! Toolbar is trying to get content from an autentication server: NoScript did this.

But again, the real question is: how is the average user in the intended market for NoScript supposed to figure out what to do when messages like this pop up? It really does appear to me that the design of ABE is fundamentally flawed to the point of being unusable in many WiFi hot spots -- specifically because ABE is incompatible with the commonly chosen methods of authentication in said hot spots. Yet at the same time I am very relucant to turn it off completely, and suspicious of the URL I gave, which has no obvious relation to Tully's Coffee: part of the problem may very well be Tully's poor choice of how to do authentication.

But I do not claim to know this for certain, and would be glad to be proved wrong (about the alleged design flaw in ABE).

[xheralt]

I had completely forgotten about this post, not to mention my registration to this forum, because, well, I'd used the (potentially dangerous but simple) workaround of simply disabling ABE. No more problem, no need to check back. Had to reset my password to reply to this! What reminded me was that Russian-language PM spam that many of you out there probably also got.

A belated thank-you for the answer, even if I never find out whether or not it actually works. If I can test it, and get the additional info, I will, but it's not practical. I spend almost no time at that coffee shop now. In the last couple of years, they reduced their hours of operation; I'm not inclined to take a cross-town bus ride after work to get to the place maybe an hour before it closes; when I want to sit and surf, I want a good couple of hours at least. I've taken my business to other coffee shops with longer hours (and different internet gatekeeping mechanisms). I still pop in there for a to-go cuppa now and then, but never sit and stay.

rap.nnu.com does seem to be directly connected with webbeams.com, a company that occupies the niche of "hotspot-providing coffee shops"; no need to be suspicious of it.

[Thrawn]

Good to hear things are working out for you . If you do get further ABE problems, just ask.

[GµårÐïåñ]

I was wondering if you ever got a chance to try it and if it worked for you or not but glad that you got it resolved and came back to check it out. Good luck.