Voting starts in March for the Drupal Association Board election.
I had to look into this recently while undergoing PCI compliance. It turns out that when ubercart makes requests to PayPal, Authorize.net, and CyberSource it doesn't verify SSL certificates. The curl code has this line in all instances:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
The PHP docs on curl_setopt (http://us2.php.net/manual/en/function.curl-setopt.php) have this say about CURLOPT_SSL_VERIFYPEER: "FALSE to stop cURL from verifying the peer's certificate. Alternate certificates to verify against can be specified with the CURLOPT_CAINFO option or a certificate directory can be specified with the CURLOPT_CAPATH option."
I dug around and discovered than the example code for most payment processors sets CURLOPT_SSL_VERIFYPEER to false. But why? This explains it: http://curl.haxx.se/docs/sslcerts.html
tl;dr is that curl ships with it's own list of root CAs. This CA list used to suck and be way different than the list of CAs that ship with web browsers. Which means that https websites that got ssl certs signed by valid CAs still wouldn't verify in curl in many cases. But curl fixed their CA list and made it much better in version 7.18.0. Debian Squeeze currently ships with libcurl 7.21.0, so this isn't actually a problem anymore (for the most part). But still payment processor code all across the web (including in ubercart) isn't verifying SSL certificates.
Not verifying SSL certificates of payment processors is a security bug. It's pretty hard to exploit (the attacker needs to be sitting between your web server and your payment processor) but if it is exploited then your customer's credit card numbers get compromised.
I've attached a patch that just changes the CURLOPT_SSL_VERIFYPEER from 0 to 1, and this should fix the problem.
This should solve the problem, except that there's one small issue with it. I wrote a php script that makes curl requests to all of the payment processor URLs used in ubercart while verifying the peers (verifypeer_test.php_.txt). The output is:
https://test.authorize.net/gateway/transact.dll ok https://secure.authorize.net/gateway/transact.dll ok https://apitest.authorize.net/xml/v1/request.api ok https://api.authorize.net/xml/v1/request.api ok https://orderpagetest.ic3.com/hop/ProcessOrder.do ok https://orderpage.ic3.com/hop/ProcessOrder.do ok https://api-3t.sandbox.paypal.com/nvp ok https://api-3t.paypal.com/nvp ok https://www.sandbox.paypal.com/cgi-bin/webscr failed SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed https://www.paypal.com/cgi-bin/webscr ok
The connections all get made except for the one to www.sandbox.paypal.com. I'm not sure why, since www.paypal.com works fine and they both seem to use the same root CA and certificate chain. I haven't looked into it enough, but my suspicion is that it's a problem on PayPal's end, like maybe they're not serving the complete CA chain on their sandbox domain name, but they are on their main one, and curl doesn't cache intermediate CAs. Also, it doesn't look like ubercart actually makes requests to that URL, only to https://api-3t.sandbox.paypal.com/nvp and https://api-3t.paypal.com/nvp, though I could be wrong.
In any case, I'm applying this patch to my ubercart store. It makes production stores more secure, even if sandbox payments to PayPal might not work.