[PATCH] fix/loosen peer certificate verification

This is not an ehancement but a design/implementation bug. OpenID is 'open' whereas hierarchical pre-defined 'trust' encoded into x509 chains is IMHO against the basic philosophy of OpenID. Basically, this is building a fixed whitelist directly into the OpenID *library* and leaving the library user no easy/obvious way around the problem.

Possible solutions:

• only do domain checks on the certificate and fail with hard error if no match
• only warn in log if CA can not be checked
• allow to specify the trusted CA-s via library API
• and/OR allow to specify a list of trusted remote certifictaes via library API and fail if no match

The quick fix would be to drop CA checks. I'll check if I can figure out a patch for this.

There used to be a nice sentence 'trust requires identity first' on the openid.net website. This bug implies vague trust before the identity can be established :)

This fixes the problem (does not fail mysteriously any more):

diff -rN -u old-php_openid/Auth/Yadis/ParanoidHTTPFetcher.php new-php_openid/Auth/Yadis/ParanoidHTTPFetcher.php
--- old-php_openid/Auth/Yadis/ParanoidHTTPFetcher.php	2008-06-26 17:43:19.000000000 +0300
+++ new-php_openid/Auth/Yadis/ParanoidHTTPFetcher.php	2008-06-26 17:43:19.000000000 +0300
@@ -129,6 +129,7 @@
             curl_setopt($c, CURLOPT_URL, $url);
             curl_setopt($c, CURLOPT_RANGE, 
                         "0-".(1024 * Auth_OpenID_FETCHER_MAX_RESPONSE_KB));
+            curl_setopt($c, CURLOPT_SSL_VERIFYPEER, false);
 
             curl_exec($c);
 

Martin, it's really confusing when you completely retitle tickets. Yes, the thing you're suggesting and the thing Dag was suggesting when he opened the ticket both deal with SSL, but they're completely different sets of functionality that don't precisely solve the same set of problems.

Okay, with that out of the way,

There are people who believe strongly that DNS, on its own, is not sufficient to secure the identity layer for OpenID. If certificates can be verified, that gives the RP a much stronger assertion that the discovered information actually came from the domain it was supposed to instead of from a MITM or DNS hijacker. If no attempt is made to verify the certificate domain, an HTTPS identifier is not more secure.

Remember, HTTPS is optional for OpenID. You don't need to have a HTTPS identifier. (Although there are those who wish this was not so -- you can go duke this out with Eddgy Niggs sometime.) However, the users who *have* chosen to use HTTPS are doing so because of the extra qualities this provides. The above patch breaks those assumptions by default, and I don't think that's healthful.

I think we need to break this up in to several different issues:

1) Authentication "fails mysteriously" on some platforms for HTTPS identifiers or identifiers with HTTPS server endpoints. Cause of failure should not be mysterious, it should say quite plainly when it does not have the ability to make HTTPS connections, or when it made a HTTPS connection but aborted due to a CA verification failure. Ideally these messages should come back through the library API as distinctly as possible, rather than being buried in a log file that nobody reads.

2) It is not clear at install-time how functional the installation's HTTPS support is. detect.php should check to make sure that HTTPS connections work at against a variety of domains. (I think that's probably what this ticket was originally about.) This way admins can find out this sort of thing early, rather than only after a user comes along who tries to use an HTTPS OP.

3) It is not easy enough to configure the CA list and peer verification behavior through the library API. The fetchers are designed to be a pluggable component, so it's always possible to use a fetcher with the behavior you want, but we could make the process of setting the CA path a lot more streamlined and better documented.

Each of these should have its own ticket, if they don't already.