I've been experimenting with OpenID, and have set up a sample web page to access using my OpenID account. I'm using the Php OpenID Library by Janrain and it wasn't working with my Google Account. A little research led me to this question, which suggests the problem is that Google uses https and...
... it's likely the setup for making HTTPS requests is borked on your PHP server. Check to make sure you have the ca-certificates package installed.
In the same thread, someone links to their hacked version of the library which I deployed and have used with my Google Account successfully. Other questions have other customizations to get around similar problems (Janrain’s PHP-OpenID and Google/Yahoo, php-openID doesn’t work with Yahoo!, Example usage of AX in PHP OpenID...)
I'm not too hot on security, so I ask; does anyone know of a reason to not use these hacked versions?
Does the original library have whatever shortcoming these hacks fix by design, and therefore the hack is a potential security vulnerability?
Is there a qualified crypto-ifier out there who has looked at any of these solutions and gone "By David Chaum's beard! NO!!"
If so - and I therefore shouldn't use any of these hacks - how would I check that I "have the ca-certificates package installed"?
Here's what the author of one of those "hacked" versions wrote:
In particular CURLOPT_SSL_VERIFYPEER
and CURLOPT_SSL_VERIFYHOST are true by
default: I set them to false and it
worked for the test page!
The effect that has is to pretty much negate any security advantage offered by using HTTPS. The primary reason HTTPS is useful in OpenID is that it guards against a man-in-the-middle attack, i.e. some bad guy poisons your DNS cache to send all google.com requests to bad-guys.example. With properly configured HTTPS, you'd verify the certificate on the connection, find out it wasn't from Google, and say "I'm not going to believe anything you say, bad-guys!"
Unless, of course, you don't verify any certificates (you set all the SSL_VERIFY options to false), in which case your server will believe everything bad-guys says as if it were the real Google provider. You can imagine how that might be bad.
Now, frankly, this isn't the worst choice you could make, because it's no worse than just using HTTP, which a lot of people do anyway. You're just lying to your users if you imply that you're providing HTTPS-level security when you're not.
And there's a lot of information out there about how easy it is or isn't to do a dns-based attack, or how easy it is to forge SSL certificates. Either way, it does require someone to attack the connection between your server and Google, which is generally harder than attacking the connection between the user's laptop in the coffee shop and your server.
But still, much better to actually fix your PHP or CURL SSL configuration. Or if you don't, warn your users of that when they sign up with HTTPS identifiers, so they can choose if they really want to use that OpenID with your site.
Which leads to your second question. I think, not knowing anything about which server platform you're using, the best thing I can do is to link you to the Curl docs on SSL certificates; see the section that says "Get a better/different/newer CA cert bundle!"
From the Wikipedia article on Certificate Authority:
A CA issues digital certificates that contain a public key and the identity of the owner. When an end-user tries to access an unknown URL, the web browser (e.g. Mozilla Firefox and Microsoft Internet Explorer) will contact the CA to confirm the public key of the URL.
... so the CA Certificate is a Public Key Certificate used to communicate over https://. Your server should have CA Certificates on the file system somewhere. If not, you'll have to download the CA Certificate yourself and set the CURLOPT_CAINFO constant to point to its location. See this article.
http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/
[...] does anyone know of a reason to not
use these hacked versions?
Besides the fact that they're hacked versions, which are most likely undocumented and have no guarantee as to their behavior?
I can't answer specifically, but it there should be some warning lights flashing when you work with modules that have had quick fixes and workarounds applied, especially when you're dealing with authorization and security.. I think the best advice would be "Use at own risk!"
I'm sure someone with more knowledge on the topic will arrive soon enough with a more informed answer.
