Hello,
I'm using stunnel in client mode to provide an SSL connection for offlineimap[1] which does not support verification of SSL certificates.
As I've read stunnel does not compare the name of the server offering the certificate to the server name mentioned in the certificate (in the CN field for example). So if I used the following section in my stunnel.conf
client=yes
[imaps] accept = 127.0.0.1:4322 connect = imap.gmail.com:993 CAfile = /usr/share/ca-certificates/mozilla/Equifax_Secure_CA.crt verify = 2
stunnel would happily accept any certificate signed by Equifax for an arbitrary website. Is this correct?
So I've switched to using the verify=3 option and I just want to make sure I configured it correctly.
I'm now using the following section
client=yes
[imaps] accept = 127.0.0.1:4322 connect = imap.gmail.com:993 CAfile= /home/ph/.certs/imaps.pem verify = 3
imaps.pem is a file containing two certificates, namely the first and the last certificate in the certificate chain of imap.gmail.com, that is the Equifax CA certificate and the server certificate itself.
I then use offlineimap to establish an unencrypted connection to 127.0.0.1:4322.
My understanding is that stunnel will now exclusively accept the server certificate stored in the imaps.pem file rendering all MITM attacks impossible.
I'd be grateful if someone could confirm that this setup makes sense. Is this the way the verify=3 option is supposed to use? First I thought that it should be enough to just provide the server certificate in the imaps.pem file, but then openssl would complain about a self-signed certificate, so I included the CA certificate as well.
Regards, Philipp
Philipp Hartwig wrote:
My understanding is that stunnel will now exclusively accept the server certificate stored in the imaps.pem file rendering all MITM attacks impossible.
I'd be grateful if someone could confirm that this setup makes sense. Is this the way the verify=3 option is supposed to use?
Yes, this is exactly the way "verify = 3" is supposed to be used.
Mike
On Sat, Jan 15, 2011 at 08:50:02PM +0100, Michal Trojnara wrote:
Philipp Hartwig wrote:
My understanding is that stunnel will now exclusively accept the server certificate stored in the imaps.pem file rendering all MITM attacks impossible.
I'd be grateful if someone could confirm that this setup makes sense. Is this the way the verify=3 option is supposed to use?
Yes, this is exactly the way "verify = 3" is supposed to be used.
I've just played around a bit and I'm a bit worried now that I still got the whole concept of "verify = 3" in client mode wrong.
I have created a CA and two different keys/certs for 127.0.0.1 signed by that CA. I've taken the CA cert and the first(!) of the two server certs and plugged them into a file "test.pem". Then I have created a section
[test] accept = 127.0.0.1:4432 connect = 127.0.0.1:4433 CAfile = /home/ph/test.pem verify = 3
in my stunnel.conf and I've started a dummy s_server instance on 127.0.0.1:4433 using the second(!) of the two server certificates.
My expectation was that a $ telnet 127.0.0.1 4332 would fail because the server certificate in test.pem does NOT match the server certificate offered by the server. But to my surprise stunnel will happily establish the connection.
I'd be very grateful if someone could explain this to me. What did I get wrong?
After looking at the source code I think I understand it: Stunnel does not really compare the peer's certificate with the locally installed certificate but it only compares their subjects.
If my interpretation is correct maybe the documentation of the "verify" option
level 3 - verify peer with locally installed certificate
should state this? At least I was expecting a stricter form of verification.
-
Michal Trojnara -
Philipp Hartwig