Re: Sending SSL/TLS state to Dovecot auth
On Thu, 2009-04-16 at 20:53 -0400, Wietse Venema wrote: Postfix 2.6 will pass the TLS is active flag. I have changed the API so that we no longer need to make code changes in every SASL plugin when another attribute is added. It works with smtps but doesn't work with STARTTLS, because tls_context isn't set yet at smtpd_sasl_activate() stage. My original patch also had this problem.. signature.asc Description: This is a digitally signed message part
Re: Sending SSL/TLS state to Dovecot auth
Postfix 2.6 will pass the TLS is active flag. I have changed the
API so that we no longer need to make code changes in every SASL
plugin when another attribute is added.
Wietse
On Mon, Feb 23, 2009 at 02:18:01PM -0500, Timo Sirainen wrote:
In some setups it's useful for authentication handling to know if the
connection is SSL/TLS secured. The patch below should tell this to
Dovecot. It compiles, but other than that I haven't yet tested it.
It anyway looks like sending the SSL/TLS state requires an additional
parameter to xsasl_server_create(). Wietse, how do you think the API
should be changed to support this functionality? I guess the choices
are:
- int tls parameter as in the patch
- a more generic int flags bitmask
- secprops-like string
- replace all the existing parameters with a pointer to struct
xsasl_parameters so more stuff can easily be added to it later.
I guess I'd prefer the last one, especially because other people also
want to tell the local/remote IP addresses to SASL.
diff -ru postfix-2.5.6/src/smtpd/smtpd_sasl_glue.c
postfix-2.5.6-dovecot/src/smtpd/smtpd_sasl_glue.c
--- postfix-2.5.6/src/smtpd/smtpd_sasl_glue.c 2007-10-05 18:56:34.0
-0400
+++ postfix-2.5.6-dovecot/src/smtpd/smtpd_sasl_glue.c 2009-02-23
13:59:28.0 -0500
@@ -151,6 +151,7 @@
const char *sasl_opts_val)
{
const char *mechanism_list;
+int tls;
/*
* Initialize SASL-specific state variables. Use long-lived storage for
@@ -169,11 +170,16 @@
*/
#define SMTPD_SASL_SERVICE smtp
+#ifdef USE_TLS
+tls = state-tls_context != 0;
+#else
+tls = 0;
+#endif
if ((state-sasl_server =
xsasl_server_create(smtpd_sasl_impl, state-client,
SMTPD_SASL_SERVICE, *var_smtpd_sasl_realm ?
var_smtpd_sasl_realm : (char *) 0,
- sasl_opts_val)) == 0)
+ sasl_opts_val, tls)) == 0)
msg_fatal(SASL per-connection initialization failed);
/*
diff -ru postfix-2.5.6/src/xsasl/xsasl_cyrus_server.c
postfix-2.5.6-dovecot/src/xsasl/xsasl_cyrus_server.c
--- postfix-2.5.6/src/xsasl/xsasl_cyrus_server.c 2007-05-25
12:42:17.0 -0400
+++ postfix-2.5.6-dovecot/src/xsasl/xsasl_cyrus_server.c 2009-02-23
14:03:21.0 -0500
@@ -157,7 +157,8 @@
VSTREAM *,
const char *,
const char *,
-const char *);
+const char *,
+int);
static void xsasl_cyrus_server_free(XSASL_SERVER *);
static int xsasl_cyrus_server_first(XSASL_SERVER *, const char *,
const char *, VSTRING *);
@@ -262,7 +263,8 @@
VSTREAM *stream,
const char *service,
const char *realm,
-const char *sec_props)
+const char *sec_props,
+int unused_tls)
{
const char *myname = xsasl_cyrus_server_create;
char *server_address;
diff -ru postfix-2.5.6/src/xsasl/xsasl_dovecot_server.c
postfix-2.5.6-dovecot/src/xsasl/xsasl_dovecot_server.c
--- postfix-2.5.6/src/xsasl/xsasl_dovecot_server.c2008-03-16
19:09:04.0 -0400
+++ postfix-2.5.6-dovecot/src/xsasl/xsasl_dovecot_server.c2009-02-23
14:02:49.0 -0500
@@ -160,6 +160,7 @@
char *username;/* authenticated user */
VSTRING *sasl_line;
unsigned int sec_props; /* Postfix mechanism filter */
+int tls;/* TLS enabled in this session */
char *mechanism_list; /* filtered mechanism list */
ARGV *mechanism_argv; /* ditto */
} XSASL_DOVECOT_SERVER;
@@ -172,7 +173,8 @@
VSTREAM *,
const char *,
const char *,
- const char *);
+ const char *,
+ int);
static void xsasl_dovecot_server_free(XSASL_SERVER *);
static int xsasl_dovecot_server_first(XSASL_SERVER *, const char *,
const char *, VSTRING *);
@@ -382,7 +384,8 @@
VSTREAM
Re: Sending SSL/TLS state to Dovecot auth
On Mon, Feb 23, 2009 at 02:18:01PM -0500, Timo Sirainen wrote: In some setups it's useful for authentication handling to know if the connection is SSL/TLS secured. The patch below should tell this to Dovecot. It compiles, but other than that I haven't yet tested it. How is this useful? It seems to me that a SASL implementation should validate the credentials and leave policy questions to the MTA. The MTA can decide whether SASL without TLS is sufficient or not. Also mere use of TLS says nothing about the security of the channel in the absense of client certification verification, the server cannot exclude MITM attackers even when a TLS session is used. I don't think that the TLS on/off bit you propose is semantically sound. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Sending SSL/TLS state to Dovecot auth
Victor Duchovni: On Mon, Feb 23, 2009 at 02:18:01PM -0500, Timo Sirainen wrote: In some setups it's useful for authentication handling to know if the connection is SSL/TLS secured. The patch below should tell this to Dovecot. It compiles, but other than that I haven't yet tested it. How is this useful? It seems to me that a SASL implementation should validate the credentials and leave policy questions to the MTA. The MTA can decide whether SASL without TLS is sufficient or not. At least, that's what Postfix is currently trying to do. Postfix gets the SASL mechanism list from Dovecot, before Dovecot knows the connection status (which changes mid-session with TLS). Postfix can apply a policy such as no plaintext to control the mechanisms it announces to the SMTP client, and what mechanisms SMTP client can use so it won't send a plaintext password over an unencrypted connection. Also mere use of TLS says nothing about the security of the channel in the absense of client certification verification, the server cannot exclude MITM attackers even when a TLS session is used. I don't think that the TLS on/off bit you propose is semantically sound. Apparently it's possible apply policies at the Dovecot end, depending on the client IP address and I guess connection encryption status, for POP, IMAP, SMTP and so on. Whether it works is another matter (cf. the SMTP client sending plaintext over unencrypted channels). Wietse
Re: Sending SSL/TLS state to Dovecot auth
On Mon, 2009-02-23 at 14:32 -0500, Victor Duchovni wrote: On Mon, Feb 23, 2009 at 02:18:01PM -0500, Timo Sirainen wrote: In some setups it's useful for authentication handling to know if the connection is SSL/TLS secured. The patch below should tell this to Dovecot. It compiles, but other than that I haven't yet tested it. How is this useful? It seems to me that a SASL implementation should validate the credentials and leave policy questions to the MTA. The MTA can decide whether SASL without TLS is sufficient or not. It's basically the same thing as disable plaintext authentication, except on a per-user (or per-domain, or per-source-IP-range) basis rather than globally. There are probably some other use cases that I've heard before but can't remember right now. Also mere use of TLS says nothing about the security of the channel in the absense of client certification verification, There is a valid-client-cert parameter that can be used to tell dovecot-auth about that. I don't know if Postfix supports checking client certs - if it does then sure that parameter could be sent as well. the server cannot exclude MITM attackers even when a TLS session is used. The same problem exists with the global disable plaintext authentication flag. signature.asc Description: This is a digitally signed message part
Re: Sending SSL/TLS state to Dovecot auth
Timo Sirainen: On Mon, 2009-02-23 at 14:32 -0500, Victor Duchovni wrote: On Mon, Feb 23, 2009 at 02:18:01PM -0500, Timo Sirainen wrote: In some setups it's useful for authentication handling to know if the connection is SSL/TLS secured. The patch below should tell this to Dovecot. It compiles, but other than that I haven't yet tested it. How is this useful? It seems to me that a SASL implementation should validate the credentials and leave policy questions to the MTA. The MTA can decide whether SASL without TLS is sufficient or not. It's basically the same thing as disable plaintext authentication, except on a per-user (or per-domain, or per-source-IP-range) basis rather than globally. There are probably some other use cases that I've heard before but can't remember right now. The MTA gets the Dovecot mechanism list first, including PLAIN or LOGIN. Then the MTA sends the user's login name and password and the TLS session state, and then Dovecot says no you can't do that. What's the point? The same problem exists with the global disable plaintext authentication flag. Right now, MTA makes the decision not to announce PLAIN or LOGIN, therefore the client won't send plaintext. Wietse
Re: Sending SSL/TLS state to Dovecot auth
On Mon, 2009-02-23 at 16:49 -0500, Wietse Venema wrote: It's basically the same thing as disable plaintext authentication, except on a per-user (or per-domain, or per-source-IP-range) basis rather than globally. There are probably some other use cases that I've heard before but can't remember right now. The MTA gets the Dovecot mechanism list first, including PLAIN or LOGIN. Then the MTA sends the user's login name and password and the TLS session state, and then Dovecot says no you can't do that. What's the point? The same server may handle multiple different domains where some require that SSL/TLS is enabled for authentication to succeed, while for other domains it must be only optional. The server doesn't know if it requires SSL/TLS until it knows the SASL username. signature.asc Description: This is a digitally signed message part
Re: Sending SSL/TLS state to Dovecot auth
Timo Sirainen: On Mon, 2009-02-23 at 16:49 -0500, Wietse Venema wrote: It's basically the same thing as disable plaintext authentication, except on a per-user (or per-domain, or per-source-IP-range) basis rather than globally. There are probably some other use cases that I've heard before but can't remember right now. The MTA gets the Dovecot mechanism list first, including PLAIN or LOGIN. Then the MTA sends the user's login name and password and the TLS session state, and then Dovecot says no you can't do that. What's the point? The same server may handle multiple different domains where some require that SSL/TLS is enabled for authentication to succeed, while for other domains it must be only optional. The server doesn't know if it requires SSL/TLS until it knows the SASL username. The client has already sent the plaintext. What problem are you trying to solve by having Dovecot say no when it is too late? Wietse
Re: Sending SSL/TLS state to Dovecot auth
Mon, 2009-02-23 at 17:11 -0500, Wietse Venema wrote: Timo Sirainen: On Mon, 2009-02-23 at 16:49 -0500, Wietse Venema wrote: It's basically the same thing as disable plaintext authentication, except on a per-user (or per-domain, or per-source-IP-range) basis rather than globally. There are probably some other use cases that I've heard before but can't remember right now. The MTA gets the Dovecot mechanism list first, including PLAIN or LOGIN. Then the MTA sends the user's login name and password and the TLS session state, and then Dovecot says no you can't do that. What's the point? The same server may handle multiple different domains where some require that SSL/TLS is enabled for authentication to succeed, while for other domains it must be only optional. The server doesn't know if it requires SSL/TLS until it knows the SASL username. The client has already sent the plaintext. What problem are you trying to solve by having Dovecot say no when it is too late? It's too late for a few times (until user fixes the client configuration), but not forever (because it won't work until the configuration is fixed). Also with a laptop the initial setup is often done in a relatively safe location such as home or office, while the connections afterwards could be done in all kinds of insecure places. signature.asc Description: This is a digitally signed message part
Re: Sending SSL/TLS state to Dovecot auth
On Mon, Feb 23, 2009 at 05:40:05PM -0500, Timo Sirainen wrote: It's too late for a few times (until user fixes the client configuration), but not forever (because it won't work until the configuration is fixed). Also with a laptop the initial setup is often done in a relatively safe location such as home or office, while the connections afterwards could be done in all kinds of insecure places. Perhaps, but often the setting is TLS when available, so you only get illusory protection. With Postfix, the right place to enforce this is in the MTA. If some users need non-TLS MTAs, point them at alternative submission server. Which mainstream MUAs can't do TLS submission at this point in time? -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
