Hi list,
[My apologies, I accidentally tried to send this message to stunnel-announce earlier.]
I have a quick question regarding the use of stunnel with verification against an OCSP responder. I am using stunnel 4.20 and (for testing) 4.23 but I don't see any difference in the behaviour of both.
The main problem is that stunnel accepts and establishes connections from clients even if those clients had their certificates revoked and the OCSP responder correctly informs stunnel about it.
Consider the following configuration:
foreground = yes CAfile = /path/to/cacert.pem cert = /path/to/stunnel_cert.pem key = /path/to/stunnel_key.pem debug = 7
[clientauth] accept = localhost:43434 connect = localhost:43433 verify = 2 OCSP = http://localhost:43435
The OCSP responder runs on localhost:43435 as you can see. Client verification is enabled. Using openssl to manually check against the responder works fine:
openssl ocsp -issuer cacert.pem -CAfile cacert.pem -url \ http://localhost:43435 -cert revoked_cert.pem
Response verify OK /path/to/revoked_cert.pem: revoked This Update: May 15 15:38:46 2008 GMT Next Update: May 15 17:04:32 2008 GMT Revocation Time: May 15 15:38:26 2008 GMT
The relevant portion of stunnel's debug output looks like this:
[...] Starting OCSP verification FD 8 in non-blocking mode connect_wait: waiting 10 seconds connect_wait: connected OCSP server connected FD 8 in blocking mode FD 8 in non-blocking mode OCSP response received OCSP verification passed: status=0, reason=-1208427072 VERIFY OK: depth=1, /CN=The CA/C=AT/ST=SomeState/L=SomeCity/O=The \ Organisation/emailAddress=camaster@the-organisation.invalid Starting OCSP verification FD 8 in non-blocking mode connect_wait: waiting 10 seconds connect_wait: connected OCSP server connected FD 8 in blocking mode FD 8 in non-blocking mode OCSP response received OCSP verification passed: status=1, reason=-1 VERIFY OK: depth=0, /C=AT/ST=SomeState/O=The Organisation/CN=this is a \ revoked cert SSL state (accept): SSLv3 read client certificate A [...]
As far as I can see the OCSP verification works fine here, too, and at depth 0 stunnel finds the certificate to have been revoked (status=1 indicates that, I believe). The connection, however, is not rejected.
Is there any way to have stunnel reject the connection when the client certificate has been revoked? Where would I configure this? The only way I have found yet was to patch src/verify.c but surely there must be a more convenient approach to this?
On a related matter: if stunnel cannot and will not reject the connection upon a negative response from the OCSP, what would be the best way to script stunnel so that it rejects such a connection? I am asking because I am in the process of writing a few Python scripts that incorporate stunnel to aid in testing of some SSL-speaking components. Such a client component without a valid, non-revoked certificate must not be able to connect.
I mean what good is OCSP verification if the result of the process, i.e. the responders answer "the certificate is valid" or "the certificate is no longer valid" doesn't matter to stunnel?
Am I missing the point somewhere?
I'd appreciate any insights on this.
Kind regards,
Andreas
On 2008-05-15, at 20:01, Andreas Ntaflos wrote:
OCSP response received OCSP verification passed: status=1, reason=-1 VERIFY OK: depth=0, /C=AT/ST=SomeState/O=The Organisation/CN=this is a \ revoked cert SSL state (accept): SSLv3 read client certificate A
Looks like a bug in stunnel. Please try the following patch ftp://stunnel.mirt.net/stunnel/ocsp.patch and let me know if it works, so I can this problem in future releases of stunnel.
Thank you very much for the report.
Best regards, Mike
On Sunday 18 May 2008 01:54:55 Michal Trojnara wrote:
On 2008-05-15, at 20:01, Andreas Ntaflos wrote:
OCSP response received OCSP verification passed: status=1, reason=-1 VERIFY OK: depth=0, /C=AT/ST=SomeState/O=The Organisation/CN=this is a \ revoked cert SSL state (accept): SSLv3 read client certificate A
Looks like a bug in stunnel. Please try the following patch ftp://stunnel.mirt.net/stunnel/ocsp.patch and let me know if it works, so I can this problem in future releases of stunnel.
Thank you very much for the report.
Hi Mike,
the patch seems to work just fine. Clients with a revoked certificate are no longer able to connect, getting a handshake failure from Stunnel.
Thanks very much for looking into the matter and providing a fix so quickly!
Andreas