Hello everyone,
I'm doing a few tests on a dockerized service for stunnel under Alpine.
stunnel -version
stunnel 5.60 on x86_64-alpine-linux-musl platform Compiled with OpenSSL 1.1.1k 25 Mar 2021 Running with OpenSSL 1.1.1l 24 Aug 2021 Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,OCSP,PSK,SNI
If I set a wrong certificate on client side, my server logs get spammed with these lines :
2021.09.28 07:43:52 LOG5[66]: Service [***] accepted connection from *** 2021.09.28 07:43:52 LOG4[66]: CERT: Pre-verification error: unable to get local issuer certificate 2021.09.28 07:43:52 LOG4[66]: Rejected by CERT at depth=2: C=***, O=***, CN=*** 2021.09.28 07:43:52 LOG3[66]: SSL_accept: ssl/statem/statem_srvr.c:3711: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed 2021.09.28 07:43:52 LOG5[66]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
The cpu usage goes up to 35% and it seems there is no way to set a timeout before trying to reconnect on client side (which is not the perfect fix by the way).
On server side, I don't know if we are supposed to be able to do something about that (for example rate limiting the requests ?).
Even the fail2ban filter doesn't seem to support this case. And anyway it seems it requires manual patching on stunnel source code for the logs.
Would it be possible to put on the same line the client IP and a message about the connection which has been rejected ?
fail2ban filter : https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/stunnel.con...
What would be appreciated -> a log line in this format :
2021.09.28 07:43:52 LOG4[66]: HOST has been rejected by CERT at depth=2: C=***, O=***, CN=***
Of course, I don't have in mind the other possible cases (missing cert, etc...).
Thank you in advance,
Robin KERDILES
On 28.09.21 10:07, robin.kerdiles@emanrisk.fr wrote:
If I set a wrong certificate on client side, my server logs get spammed
[...]
The cpu usage goes up to 35% and it seems there is no way to set a timeout before trying to reconnect on client side (which is not the perfect fix by the way).
On server side, I don't know if we are supposed to be able to do something about that (for example rate limiting the requests ?).
Yeah, I've pretty much given up on CRLing ex-clients from various OpenVPN servers for similar reasons - they don't handle outright rejects in a server-friendly (backing off) way, either. Cutting the worst of them off by other means, like iptables, is the way to go IMHO ...
Regards,