Mailing List Archive

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=512





------- Comment #2 from ph10@hermes.cam.ac.uk 2007-06-14 15:32 -------
I'm trying to work out why this is necessary. Can't you just set
hosts_require_tls to the same list as hosts_require_auth? Secondly, I don't
think you need a new variable. Won't tls_cipher do? What am I missing here?

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=512





------- Comment #3 from exim-dev@spodhuis.org 2007-06-14 20:43 -------
(In reply to comment #2)
> I'm trying to work out why this is necessary. Can't you just set
> hosts_require_tls to the same list as hosts_require_auth? Secondly, I don't
> think you need a new variable. Won't tls_cipher do? What am I missing here?

tls_cipher is the cipher used when the message was received and isn't (AFAICT)
set to the outbound cipher; the only current handling of the outbound cipher is
that the +tls_cipher log selector will get the connection's cipher. I doubt
that it'd be a good plan to change which security context the variable refers
to just because it's being used in an smtp transport. Hence the new variable.

I've just set up Exim on my laptop; I'll use multiple smarthosts, depending
upon where I am. I don't mind if a smarthost offers GSSAPI or DIGEST-MD5 (or
even CRAM-MD5) authentication in cleartext. I do mind if it suddenly offers
plaintext authentication in cleartext. Just as you can use
server_advertise_condition to confirm ${if def:tls_cipher} before offering
plaintext, the reciprocal client security should be able to set, by policy,
that plaintext will only be tried in the smtp transport if protected by the
cipher. No matter where the host is. Policy encoding, rather than current
host list encoding.

PS: Exim works great on MacOS 10.4.9 x86. I probably did need the fink
packages though, so I don't know how it would be on a "bare" system. :^)

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=512





------- Comment #4 from exim-dev@spodhuis.org 2007-06-14 20:47 -------
(In reply to comment #3)
> tls_cipher is the cipher used when the message was received and isn't (AFAICT)
> set to the outbound cipher; the only current handling of the outbound cipher

It's not _documented_ as being the outbound cipher; it's consistently
documented as being the received cipher. So when looking at smtp.c I didn't
look too closely.

I've just traced through and seen that indeed, $tls_cipher is set. The
documentation needs updating if this is to be kept.

Sorry.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=512





------- Comment #5 from ph10@hermes.cam.ac.uk 2007-06-15 16:11 -------
(In reply to comment #4)

> I've just traced through and seen that indeed, $tls_cipher is set. The
> documentation needs updating if this is to be kept.

OK, I now understand the problem you are trying to solve. I think the answer to
tls_cipher is to document it. I'll work on the patch, probably next week.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=512





------- Comment #6 from exim-dev@spodhuis.org 2007-06-15 19:49 -------
(In reply to comment #5)
> (In reply to comment #4)
>
> > I've just traced through and seen that indeed, $tls_cipher is set. The
> > documentation needs updating if this is to be kept.
>
> OK, I now understand the problem you are trying to solve. I think the answer to
> tls_cipher is to document it. I'll work on the patch, probably next week.

I'm probably just missing it (again), but where is $tls_cipher _unset_ before
being set if TLS is available?

It's copied from the spool, delivery is started; now, if the delivery avoids
TLS because it wasn't advertised (Man-in-the-Middle removing the expected
STARTTLS) then how can I test in the client whether the value of $tls_cipher is
that previously established or a new value?

Thanks,

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=512





------- Comment #7 from ph10@hermes.cam.ac.uk 2007-06-18 11:52 -------
(In reply to comment #6)

> I'm probably just missing it (again), but where is $tls_cipher _unset_ before
> being set if TLS is available?

It isn't. It ought to be. I will arrange for it to be unset. To move to a
situation with two different variables would be complicated, and I don't think
it is worth it. I will, of course document things more clearly. I'll post again
and close this bug when I've done the coding.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=512


ph10@hermes.cam.ac.uk changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED




------- Comment #8 from ph10@hermes.cam.ac.uk 2007-06-18 15:01 -------
OK, I have sorted out $tls_cipher so that it is set during an outgoing
connection only if the connection is authenticated. I have also added
client_condition to authenticators - I decided that that name was sufficient.
Simple tests work. The code is committed to CVS, so should be in tonight's
snapshot. Documentation in NewStuff.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=512





------- Comment #9 from holmgren@lysator.liu.se 2007-06-18 18:00 -------
ph10@hermes.cam.ac.uk wrote:
> OK, I have sorted out $tls_cipher so that it is set during an outgoing
> connection only if the connection is authenticated.

Just to check: You have changed so that $tls_cipher is set during an
outgoing connection only if the connection is *encrypted* (instead of
being set to the cipher used for the *incoming* connection if that
connection was encrypted but not the outgoing one)?

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=512





------- Comment #10 from ph10@hermes.cam.ac.uk 2007-06-19 09:22 -------
On Mon, 18 Jun 2007, holmgren@lysator.liu.se wrote:

> ------- Comment #9 from holmgren@lysator.liu.se 2007-06-18 18:00 -------
> ph10@hermes.cam.ac.uk wrote:
> > OK, I have sorted out $tls_cipher so that it is set during an outgoing
> > connection only if the connection is authenticated.
>
> Just to check: You have changed so that $tls_cipher is set during an
> outgoing connection only if the connection is *encrypted* (instead of
> being set to the cipher used for the *incoming* connection if that
> connection was encrypted but not the outgoing one)?

No, I have not changed the setting of $tls_cipher during an outgoing
connection. It was a mess before. It always got set when encryption was
started up, on either kind of connection.

What I have done is to *unset* it before making an outgoing connection.
Previously, if it was set, it meant that either the incoming or the
outgoing connection was encrypted. Now it means that the outgoing
connection is encrypted.

The only expansions that this affects are the one for the HELO/EHLO
text, and those in an authenticator. I think those are the only ones
that happen after the connection is established.

Philip

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##