So in the process of applying the new SSL cert here at work, I discovered an issue with the reCAPTCHA service.
The problem was that I was getting errors saying that my forms were only partially encrypted. This was due to my use of the reCAPTCHA library, which by default doesn’t use an SSL connection to grab the challenge HTML.
The documentation at the reCaptcha site has a section on this. Specifically it says:
In order to avoid getting browser warnings, if you use reCAPTCHA on an SSL site, you should replace http://api.recaptcha.net with https://api-secure.recaptcha.net.
Ref: http://recaptcha.net/apidocs/captcha/client.html
The example it uses shows how to change the Javascript itself. While this was nice to know it really didn’t help too much in my particular case. To solve this when using the reCAPTCHA PHP library, all you need to do is change the value of a single variable. In the file recaptchalib.php look for the function recaptcha_get_html then change the declaration to read as follows:
function recaptcha_get_html ($pubkey, $error = null, $use_ssl = true)
This will force all calls to be transmitted over an SSL connection, thus eliminating the dialog box in Internet Explorer and the slashed-lock in Firefox.
However since I am not encrypting the entire site by default, yet due to an issue with our website editing/management system, Adobe Contribute, I had to do a bit more than just updating the boolean variable. Since some of my forms are encrypted and some are not, I added the following code to the function referenced above:
if ($_SERVER['SERVER_PORT'] = 443) { $use_ssl = true;
}
This needs to be added just above the check for the value of the variable use_ssl in the function recaptcha_get_html. Once you do this you can use the same copy of the recpatchalib.php file for both secure and non-secure forms.
So, a friend of mine was setting up a Linksys WRE54G Range Extender on her wireless network to eliminate a dead spot in her house.
She had issues with the Windows-based setup utility because it hardcodes the TCP/IP settings on the computer due to the fact it assumes that your network won’t be setup to work with the device out of the box. After that failed, and spending a while on the phone with a hapless Linksys tech support person, we finally got it configured via the web interface.
So everything is going fine until she notices that the MAC filter that was configured on the WRT54G was no longer effective.
It turns out that when you setup the WRE54G to work it invalidates the purpose of your MAC filtering. All traffic sent through the range extender is automatically flagged as OK.
From a Linksys forum post:
As a result, Wireless MAC Filtering on the main wireless router or access point will have no effect on clients connecting through a WRE54G Range Expander.
You have to wonder who makes the decisions on options with stuff like this. The Linksys tech I was chatting with online about this said that the best solution would be to enable WPA security, but their user guide for device specifically recommends doing MAC address filtering in addition to the encryption, except for the fact that you can’t.
Good game Linksys.
At work we run the WebCT Vista course management system by Blackboard.
Recently I was requested to figure out how to import the security certificate from the command line so that we could add this to the login script used for our campus computers. The main reason behind this was to eliminate the need for the user to have to manually agree to the security certificate when browsing to the CMS.
Normally when you want to create a Java keystore, you would use the keytool program located in $JAVA_HOME/bin. If you run this program to import a certificate without specifying a location for the keystore it tries to create one named .keystore in the user profile home directory.
However, when the JRE actually imports a certificate it doesn’t put it in this file. After some investigation, it turns out that the JRE imports certificates into a file named trusted.certs which is located in the following directory
C:\Documents and Settings\USERNAME\Application Data\Sun\Java\Deployment\security\
In order to import a certificate into a keystore you need to vital pieces of information:
- the keystore name
- the keystore password
The problem here is that this keystore is being automatically created by the JRE. It turns out that this keystore has a password that is an empty string. What this means is that when you import a certificate you have to specify the password by using the storepass parameter with a value “”.
For example if the certificate that you want to import has a name and path of
c:\Blackboard.cer
the command to import the certificate for the user jdoe would be
keytool.exe -import -noprompt -keystore C:\Documents and Settings\jdoe\Application Data\Sun\Java\Deployment\security\trusted.certs -storepass "" -file c:\Blackboard.cer
Update 2008-04-09:
I have also found how to do this on Mac OS X. According to the developer documents, the JVM on Mac OS X uses the user’s default keychain to store this type of certificate instead of using a file-based keystore like the other OS.
In order to store the certificate in the user’s login keychain you can import it via the command line tool certtool that is installed on the OS.
The command to import this certificate from the command line is
certtool i path/to/cert/file k=~/Library/Keychains/login.keychain
If you want to have this happen at login for each user who might login, then you could implement this via a login hook. For more on this, take a gander at the article 301446 in the Apple knowledgebase.
So, PayPal has thrown down the gauntlet on the safe browser war. According to an InfoWorld article, they have declined to add Apple’s Safari browser to their list of safe browsers due to the lack of native anti-phishing technology.
I find it interesting that one of the features they explicitly mention in the InfoWorld article as being a reason behind this is the use (or lack thereof) of the Extended Validation Certificate (EV).
Firefox 2 does not currently support this, however the possibility of having the browser warn you to a possible phishing attack is apparently enough for PayPal. According to the Mozilla developer’s, FireFox 3 will support the EV technology.
Personally I think that the automated protection schemes are great, when they work. One of the first things I did when installing IE7 on my virtual machine was to disable the anti-phishing filter. It is nice to have the automated systems, but there is nothing like a little user education to make the world a safer place. According to a NetworkWorld article:
In one study, three groups of 14 participants each received e-mail messages that included spam and phishing attacks as well as legitimate mail. Two of the groups were presented with educational material about how to prevent being phished; but only one group received the material after having fallen for the phishing e-mails and entered personal information into a fraudulent Web site.
The group that was given educational materials but hadn’t been phished were no better at spotting phishing attacks that the third group, which received no educational materials at all, researchers say.
Besides, who is to be the arbiter of whether or not the site really deserves being declared a phishing site? Sure sometimes it is patently obvious, like when the site is dressed up to look like Citibank, but the URL is really something like “www.citibank.secure.orangecrush.cz”. However, there is no such thing as a perfect system, and we don’t need to train the users to rely completely on the built-in safeguards.
I you have read my previous post, GPG Best Practices, you will know that I am a fan of setting expiration dates on my GPG keys.
This has not always been the case. As with many computer users I tend towards the lazy, and if I can keep from having to re-learn a password by never changing it, then I have been guilty of doing so.
Recently, however, I have decided that this is not the best thing to do when it comes to computer security. So while restoring my computer this weekend after a rebuild of the OS to get rid of some cruft that had built up, I decided I needed to add expiration dates to all of my GPG keys.
Now I had already established one for my work e-mail at the time I created the key, but now I needed to go back and add ones to my personal keys. After reading the man page on GPG, it looked pretty easy. Just go into edit mode for the key I wanted to change, the add an expiration date. Simple enough, right? Wrong.
Turns out the what I wanted to do was feasible, just not readily apparent. I didn’t just want to set a date relative to the current date in day, months, weeks, or years. What I wanted to do was use a specific date.
Well, after some diligent searching on Google, I found the following in a post on the gnupg-users list:
>>Is it possible to set an explicit date (e.g. 31 Dec) rather than a >>duration? I suppose I could compute the number of days, but that’s
>>annoying.
Problem solved, mission accomplished.
Next Page »