We are very glad with this mod, there's only one problem: some of our moderators use Safari as default browser and are unable to login. Every page they visit requires a new IP scan for 4 secs with is at least very annoying...
First of all, I'm surprised you didn't heed to all the warnings in big red as to not use this MOD on a live forum..
Secondly, there was a major bug in this release (and possibly past releases that have been using the auto-installer), see previous posts on this same page, that prevented all users from logging in on the forum. Did you do the manual fix described above on a live forum?
I'm currently committing a LOT of fixes / improvements to the code, see r64, r65, and most notably r66 revision at:
One of the changes described in r66 (if you click on it you will see it):
- Skip scanning if user logs in to forum (or ACP) as an admin or global moderator (before, we only skipped scanning when admin logs in to ACP).
But that gets me wondering why only the moderators using Safari have this problem
(Hopefully someone with safari browser can do some testing in the upcoming release)
I plan on releasing a more stable version (with many new features/improvements) soon.. Just be patient please...
There's one thing I'm working on right now which is delaying progress.. Kind of a mess...
The Java applet we use in this MOD, I had signed it with Thawte Freemail Certification last year (which has always been in Java's Root Signing CA's) so the applet can run as trusted and therefore without restrictions, provided the end-user accepts a (luring) prompt that this applet is trusted, due to a bug in Java Plugin that doesn't allow the applet to connect back to originating host when an HTTP proxy is set in browser.
If it wasn't for this bug in java plugin since JRE 6u2 (which is not a feature but a regression introduced by security fix a long while back), I wouldn't have even needed to sign the applet, and the end user wouldn't even see that security prompt (or any visual indications for that matter) from java plugin..
I reported this java bug last year to Sun Microsystems OVER A YEAR AGO, and still have not been fixed
See: http://bugs.sun.com/bugdatabase/view_bu ... id=6756165
(And for anyone reading this: PLEASE vote for the bug so hopefully it can be fixed sooner, if you can)
Even more unfortunate, the certificate from Thawte that I had signed the applet with last year has expired on 29.9.2009, and Thawte has now discontinued the "Freemail" (including java codesigning) service
They kindly sent me a token in their EOL (End Of Life) email to take advantage of an exclusive offer from Verisign; 1-year "Digital ID" certificate free of charge ($19.99 value). I signed up for it, went on to sign my applet using my new verisign digital ID cert, and was bummed out when jarsigner (from JDK) told me:
"The signer certificate's ExtendedKeyUsage extension doesn't allow code signing"
More on this here:
So I scoured through the list of "Signer CA"s that are installed by default with the latest JRE (from control panel -> Java -> security tab -> certificates -> system tab -> "Signer CA" from the "Certificate type" drop down list). Tried to find any other Signer CA that offers free "Class 1" certificates which allow code signing.
I tried one from comodo (http://www.instantssl.com
), but sadly, it doesn't allow code signing either.
Signed up with trustcenter.de for a email certificate (their only free service), got a notification email yesterday that I will receive instructions there and never got it. I doubt it'll allow code signing either once I do get it..
So now I'm rethinking the whole Java applet technique and the code that we currently use...
One option is to go back to the earliest version we used (before the whole certificate signing thing). At least it works for unmasking some CGI-Proxies (ones that don't filter out or rewrite the applet tag in the html) and doesn't give any alarming popups/prompts to the end user (as with self-signed certs), and it'll still unmask browser-set HTTP Proxies, for forums whose host.domain.tld resolves to and IP that reverse-resolves to the same host.domain.tld, or ones that can use the workaround of putting the server's IP instead of hostname in the codebase to fetch the applet. But this is just too darn hackish, and required a long explanation in the install.xml so people understand why Java applet doesn't work on their virtual host, and why such workaround is needed, and how to do it. And people start complaining to me that they can't run xmlsockd.pl script (for Flash detection to work) because their virtual hosting provider won't allow it (Adobe Flash security policy requires it to authorize connect backs) and complain that they cannot use Java workaround if their setup is affected. What can you do
Well, at least realplayer/realalternative plugin detection and unmasking technique that I developed, as well as XSS techniques that were originally developed by TerraFrost, work (usually) flawlessly..
In the meantime, I need some time to add some newer techniques (particularly itunes detection and itms:// link bypass, quicktime detection and browser proxy settings bypass, and perhaps the MS-word file with image loading from external link trick as well)
By the way, I looked at the decloak.net demo (from metasploit), and it doesn't seem like their idea of a java applet for a decloak engine is any more successful either, heh..