Merge commit 'origin/master' into tova
[ikiwiki.git] / doc / bugs / ssl_certificates_not_checked_with_openid.mdwn
1 As far as I can tell, ikiwiki is not checking the SSL certificate of the remote host when using openid authentication. If so, this would allow for man-in-the-middle type attacks. Alternatively, maybe I am getting myself confused.
2
3 Test #1: Enter URL as openid server that cannot be verified (either because the certificate is self signed or signed by an unknown CA). I get no SSL errors.
4
5 Test #2: Download net\_ssl\_test from dodgy source (it uses the same SSL perl library, and test again. It seems to complain (on same site ikiwiki worked with) when it can't verify the signature. Although there is other breakage with the version I managed to download (eg. argument parsing is broken; also if I try to connect to a proxy server, it instructs the proxy server to connect to itself for some weird reason).
6
7 For now, I want to try and resolve the issues with net\_ssl\_test, and run more tests. However, in the meantime, I thought I would document the issue here.
8
9 -- Brian May
10
11 > Openid's security model does not rely on the openid consumer (ie,
12 > ikiwiki) performing any sanity checking of the openid server. All the
13 > security authentication goes on between your web browser and the openid
14 > server. This may involve ssl, or not.
15
16 > For example, my openid is "http://joey.kitenet.net/". If I log in with
17 > this openid, ikiwiki connects to that http url to determine what openid
18 > server it uses, and then redirects my browser to the server
19 > (https://www.myopenid.com/server), which validates the user and redirects
20 > the browser back to ikiwiki with a flag set indicating that the openid
21 > was validated. At no point does ikiwiki need to verify that the https url
22 > is good.
23 > --[[Joey]]
24
25 >> Ok, so I guess the worst that could happen when ikiwiki talks to the http
26 >> address is that it gets intercepted, and ikiwiki gets the wrong address.
27 >> ikiwiki will then redirect the browser to the wrong address. An attacker could
28 >> trick ikiwiki to redirect to their site which always validates the user
29 >> and then redirects back to ikiwiki. The legitimate user may not even notice.
30 >> That doesn't so seem secure to me...
31
32 >> All the attacker needs is access to the network somewhere between ikiwiki
33 >> and http://joey.kitenet.net/ or the ability to inject false DNS host names
34 >> for use by ikiwiki and the rest is simple.
35
36 >> -- Brian May