minor change

[ikiwiki.git] / doc / bugs / ssl_certificates_not_checked_with_openid.mdwn

diff --git a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn
index e3bd56cfdf81bb0e369911d607600e7a1a0e8626..2e71ab0315a5a7c553dd9abd7370c5d57a839117 100644 (file)
--- a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn
+++ b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn
@@ -40,7 +40,7 @@ For now, I want to try and resolve the issues with net\_ssl\_test, and run more
 >> -- Brian May
 
 >>> I guess that the place to add SSL cert checking would be in either
->>> [[cpan LWPx::ParanoidAgent]] or [[cpan Net::OpenID::Consumer]]. Adding
+>>> [[!cpan LWPx::ParanoidAgent]] or [[!cpan Net::OpenID::Consumer]]. Adding
 >>> it to ikiwiki itself, which is just a user of those libraries, doesn't
 >>> seem right.
 >>> 
@@ -50,3 +50,63 @@ For now, I want to try and resolve the issues with net\_ssl\_test, and run more
 >>> that the SSL cert is issued by a trusted party and matches the domain name
 >>> of the site being connected to. I also don't personally think that SSL
 >>> certs are the right fix for DNS poisoning issues. --[[Joey]]
+
+I was a bit vague myself on the details on openid. So I looked up the standard.
+I was surprised to note that they have already considered these issues, in
+section 15.1.2, <http://openid.net/specs/openid-authentication-2_0.html#anchor41>.
+
+It says:
+
+"Using SSL with certificates signed by a trusted authority prevents these kinds of
+attacks by verifying the results of the DNS look-up against the certificate. Once
+the validity of the certificate has been established, tampering is not possible.
+Impersonating an SSL server requires forging or stealing a certificate, which is
+significantly harder than the network based attacks."
+
+With regards to implementation, I am surprised that the libraries don't seem to
+do this checking, already, and by default. Unfortunately, I am not sure how to test
+this adequately, see [[!debbug 466055]]. -- Brian May
+
+--- 
+
+I think [[!cpan Crypt::SSLeay]] already supports checking the certificate. The trick
+is to get [[!cpan LWP::UserAgent]], which is used by [[!cpan LWPx::ParanoidAgent]] to
+enable this checking.
+
+I think the trick is to set on of the the following environment variables before retrieving
+the data:
+
+$ENV{HTTPS\_CA\_DIR} = "/etc/ssl/certs/";  
+$ENV{HTTPS\_CA\_FILE} = "/etc/ssl/certs/file.pem";  
+
+Unfortunately I get weird results if the certificate verification fails, tshark shows the following communications with my proxy server:
+
+HTTP CONNECT db.debian.org:443 HTTP/1.0  
+[tls stuff]  
+HTTP CONNECT proxy.pri:3128 HTTP/1.0  
+HTTP HTTP/1.0 403 Forbidden (text/html)  
+
+Why it is trying to connect to the proxy server via the proxy server is beyond me. This only happens if the certificate verification fails (I think). I will continue investigating. My test code is:
+
+
+#!/usr/bin/perl -w
+use strict;
+#require LWPx::ParanoidAgent;
+#my $ua = LWPx::ParanoidAgent->new;
+
+require LWP::UserAgent;
+my $ua = LWP::UserAgent->new;
+
+$ua->proxy(['http'], 'http://proxy.pri:3128');
+$ENV{HTTPS_PROXY} = "http://proxy.pri:3128";
+$ENV{HTTPS_CA_DIR} = "/etc/ssl/certs/";
+
+
+my $response = $ua->get("https://db.debian.org/");
+
+if ($response->is_success) {
+    print $response->content;  # or whatever
+} else {
+    die $response->status_line;
+}
+