Ability to reject invalid client certificate at TLS handshake time
Hi,
After a bit of struggling I've been able to set up TLS client certificate authentication with Dovecot for both IMAP and Submission. Users are required to present a valid certificate, cool so far!
What I noticed however on non-StartTLS listeners IMAPS (993) and SMTPS (465), is that during the TLS handhake presenting a valid client certificate is seemingly optional and is only checked later at time of protocol-level login (external auth in my case). I'd like to change that for security purposes and also a bit of obscurity. Not having the ability to interact with Dovecot on protocol level lowers the attack vector as well as the ease of checking my network security. Also, it would prevent (anonymous) network scanners to easily detect what kind of service is running on the port as they can see the IMAP/SMTP banner without presenting a valid TLS client certificate currently.
Is it possible in any version of Dovecot to configure it to set up a TLS server listening context that requires a handshake with a valid client certificate?
I'm using Dovecot 2.3.4.1 (actual Debian Buster version 2.3.4.1-5+deb10u6), but willing to upgrade to any newer version when this is offered. Going through some newer revisions changelog this seems not the case, so I didn't spend time on upgrading yet.
Relevant config snippets for IMAP authenticating proxy that I use (something similar for Submission):
# Opens 143 on StartTLS and 993 in wrapped TLS-only mode. # Only 993 is exposed to the internet. protocols = imap passdb { driver = static args = proxy=y host=10.1.2.3 port=1143 pass=masterpass nopassword=y } auth_username_format = %n ssl = required ssl_cert =
Current behaviour from a client when deliberately not presenting a client certificate shows the IMAP banner: $ openssl s_client -connect myserver:993 CONNECTED(00000003)
Certificate chain 0 [...]
Server certificate -----BEGIN CERTIFICATE----- [...]
Acceptable client certificate CA names C = NL, O = Gert van Dijk, [...]
SSL handshake has read 1096 bytes and written 413 bytes Verification: OK
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 384 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)
- OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ LOGINDISABLED AUTH=EXTERNAL] Dovecot (Debian) ready.
Expected: TLS alert during handshake, e.g. on my Apache TLS client certificate required configured instance: $ openssl s_client -connect myserver:443 139676785239360:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1543:SSL alert number 40
IOW, I was hoping for something like this to exist: ssl_verify_client_cert = required OR service imap-login { inet_listener imaps { port = 993 ssl = client-cert-required } }
Thanks,
Gert
Hi,
Client certificate authentication simply replaces username/password authentication within the IMAP protocol. Before starting authentication, the client still needs to talk to the server, and the server still needs to announce that it is ready to accept your certificate.
On this website you'll find a nice picture of the global auth flow: https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-do...
Wouldn't it be much easier to just change the banner to something less obvious than the default? Unauthenticated connections will still be able to see you have an IMAP server, but the fact that you're using Dovecot might be invisible. Switching to a non-standard port might also help to mislead network scanners.
However IMHO the fact that you're running a public network service will never change due to the fact that Dovecot is simply that: a public network service. Your focus should be on useful protection based on the assumption that an external attacker already knows that your server is there, not on trying to hide it.
Kind regards, Tom
On 01-05-2021 14:04, Gert van Dijk wrote:
Hi,
After a bit of struggling I've been able to set up TLS client certificate authentication with Dovecot for both IMAP and Submission. Users are required to present a valid certificate, cool so far!
What I noticed however on non-StartTLS listeners IMAPS (993) and SMTPS (465), is that during the TLS handhake presenting a valid client certificate is seemingly optional and is only checked later at time of protocol-level login (external auth in my case). I'd like to change that for security purposes and also a bit of obscurity. Not having the ability to interact with Dovecot on protocol level lowers the attack vector as well as the ease of checking my network security. Also, it would prevent (anonymous) network scanners to easily detect what kind of service is running on the port as they can see the IMAP/SMTP banner without presenting a valid TLS client certificate currently.
Is it possible in any version of Dovecot to configure it to set up a TLS server listening context that requires a handshake with a valid client certificate?
I'm using Dovecot 2.3.4.1 (actual Debian Buster version 2.3.4.1-5+deb10u6), but willing to upgrade to any newer version when this is offered. Going through some newer revisions changelog this seems not the case, so I didn't spend time on upgrading yet.
Relevant config snippets for IMAP authenticating proxy that I use (something similar for Submission):
# Opens 143 on StartTLS and 993 in wrapped TLS-only mode. # Only 993 is exposed to the internet. protocols = imap passdb { driver = static args = proxy=y host=10.1.2.3 port=1143 pass=masterpass nopassword=y } auth_username_format = %n ssl = required ssl_cert =
Current behaviour from a client when deliberately not presenting a client certificate shows the IMAP banner: $ openssl s_client -connect myserver:993 CONNECTED(00000003)
Certificate chain 0 [...]
Server certificate -----BEGIN CERTIFICATE----- [...]
Acceptable client certificate CA names C = NL, O = Gert van Dijk, [...]
SSL handshake has read 1096 bytes and written 413 bytes Verification: OK
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 384 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)
- OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ LOGINDISABLED AUTH=EXTERNAL] Dovecot (Debian) ready.
Expected: TLS alert during handshake, e.g. on my Apache TLS client certificate required configured instance: $ openssl s_client -connect myserver:443 139676785239360:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1543:SSL alert number 40
IOW, I was hoping for something like this to exist: ssl_verify_client_cert = required OR service imap-login { inet_listener imaps { port = 993 ssl = client-cert-required } }
Thanks,
Gert
Hi Tom,
I agree that hiding a banner is obscurity rather than security (I haven't claimed otherwise) and I share your views on where the focus should be. However, my point reaches a bit further than those. I believe it's of general good practice to deny access as soon as possible in the chain of events in authentication. I believe I have described my reasoning in my initial post for why I think these are actual security benefits.
The link you provided (Comodo) explains exactly what I propose; the requirement of the client certificate in the *handshake*, so it's not supporting your view at all, but mine, really. And besides, it does not explain why IMAPS/SMTPS should behave differently.
By the way, I believe your statement "Client certificate authentication simply replaces username/password authentication within the IMAP protocol" is not really true; it depends on the configuration. In this example I have chosen to have passwordless authentication and 'borrow' the authentication provided by the TLS layer, but I could have left in a regular userdb configuration (or configured by upstream proxy to require LOGIN). The security benefits for evaluation at TLS handshake time can be beneficial for any configuration having the requirement for presenting a valid client certificate.
Kind regards,
Gert
On Sat, May 1, 2021 at 5:46 PM Tom Hendrikx tom@whyscream.net wrote:
Hi,
Client certificate authentication simply replaces username/password authentication within the IMAP protocol. Before starting authentication, the client still needs to talk to the server, and the server still needs to announce that it is ready to accept your certificate.
On this website you'll find a nice picture of the global auth flow: https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-do...
Wouldn't it be much easier to just change the banner to something less obvious than the default? Unauthenticated connections will still be able to see you have an IMAP server, but the fact that you're using Dovecot might be invisible. Switching to a non-standard port might also help to mislead network scanners.
However IMHO the fact that you're running a public network service will never change due to the fact that Dovecot is simply that: a public network service. Your focus should be on useful protection based on the assumption that an external attacker already knows that your server is there, not on trying to hide it.
Kind regards, Tom
On 01-05-2021 14:04, Gert van Dijk wrote:
Hi,
After a bit of struggling I've been able to set up TLS client certificate authentication with Dovecot for both IMAP and Submission. Users are required to present a valid certificate, cool so far!
What I noticed however on non-StartTLS listeners IMAPS (993) and SMTPS (465), is that during the TLS handhake presenting a valid client certificate is seemingly optional and is only checked later at time of protocol-level login (external auth in my case). I'd like to change that for security purposes and also a bit of obscurity. Not having the ability to interact with Dovecot on protocol level lowers the attack vector as well as the ease of checking my network security. Also, it would prevent (anonymous) network scanners to easily detect what kind of service is running on the port as they can see the IMAP/SMTP banner without presenting a valid TLS client certificate currently.
Is it possible in any version of Dovecot to configure it to set up a TLS server listening context that requires a handshake with a valid client certificate?
I'm using Dovecot 2.3.4.1 (actual Debian Buster version 2.3.4.1-5+deb10u6), but willing to upgrade to any newer version when this is offered. Going through some newer revisions changelog this seems not the case, so I didn't spend time on upgrading yet.
Relevant config snippets for IMAP authenticating proxy that I use (something similar for Submission):
# Opens 143 on StartTLS and 993 in wrapped TLS-only mode. # Only 993 is exposed to the internet. protocols = imap passdb { driver = static args = proxy=y host=10.1.2.3 port=1143 pass=masterpass nopassword=y } auth_username_format = %n ssl = required ssl_cert =
Current behaviour from a client when deliberately not presenting a client certificate shows the IMAP banner: $ openssl s_client -connect myserver:993 CONNECTED(00000003)
Certificate chain 0 [...]
Server certificate -----BEGIN CERTIFICATE----- [...]
Acceptable client certificate CA names C = NL, O = Gert van Dijk, [...]
SSL handshake has read 1096 bytes and written 413 bytes Verification: OK
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 384 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)
- OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ LOGINDISABLED AUTH=EXTERNAL] Dovecot (Debian) ready.
Expected: TLS alert during handshake, e.g. on my Apache TLS client certificate required configured instance: $ openssl s_client -connect myserver:443 139676785239360:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1543:SSL alert number 40
IOW, I was hoping for something like this to exist: ssl_verify_client_cert = required OR service imap-login { inet_listener imaps { port = 993 ssl = client-cert-required } }
Thanks,
Gert
participants (2)
-
Gert van Dijk
-
Tom Hendrikx