X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/a759a864f37925e6788980ac53bd8f7c69172635..3f4914b95ba239489bae48f154abed9892e0cbf5:/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn?ds=inline diff --git a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn index cb4c706f0..04ece0ae8 100644 --- a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn +++ b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn @@ -12,6 +12,10 @@ For now, I want to try and resolve the issues with net\_ssl\_test, and run more > ikiwiki) performing any sanity checking of the openid server. All the > security authentication goes on between your web browser and the openid > server. This may involve ssl, or not. +> +>> Note that I'm not an openid expert, and the above may need to be taken +>> with a grain of salt. I also can make no general statements about openid +>> being secure. ;-) --[[Joey]] > > For example, my openid is "http://joey.kitenet.net/". If I log in with > this openid, ikiwiki connects to that http url to determine what openid @@ -34,3 +38,48 @@ For now, I want to try and resolve the issues with net\_ssl\_test, and run more >> for use by ikiwiki and the rest is simple. >> -- 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 +>>> it to ikiwiki itself, which is just a user of those libraries, doesn't +>>> seem right. +>>> +>>> It's not particularly clear to me how a SSL cert can usefully be +>>> checked at this level, where there is no way to do anything but +>>> succeed, or fail; and where the extent of the check that can be done is +>>> 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, . + +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 one 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, see [[!debbug 503440]]. +It still seems to work though, regardless. + +-- Brian May