Mailing List Archive

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674




--- Comment #6 from Tony Finch <dot@dotat.at> 2008-08-13 12:13:38 ---
On Wed, 13 Aug 2008, Phil Pennock wrote:
>
> I guess the real question is whether or not it's bad to load all digests
> (and/or ciphers) when the Exim option tls_require_ciphers is set and whether or
> not we need a new tls_require_digests option (or if the ciphers option digest
> field stuff is sufficient for cert verification).

That sounds plausible.

> If tls_require_ciphers is a saving throw, then what probably needs to happen is
> that the tls_require_ciphers option should have a reasonable default set,
> instead of being unset by default, and then we add a call to
> OpenSSL_add_all_algorithms().

No, it's not Exim's job to know that kind of detail about TLS.

> Does anyone here have any expertise in this? If not, there are some people I
> can ask for help elsewhere.

That would be helpful.

Tony.


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

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

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674




--- Comment #7 from Phil Pennock <exim-dev@spodhuis.org> 2008-08-14 02:37:20 ---
Feedback from a colleague involved in such matters; these are not his words,
but me trying to summarise an IM conversation.

There's stuff required by the TLS specs for support, and there's other
algorithms. If it's not required by specs, it's not in the default init
(implied but not directly stated).

The cipher lists are distinct from the certificate verification;
SSL_CTX_set_cipher_list() affects only the negotiated session and has nothing
to do with identity verification on the remote end. Anything we do here
doesn't affect ability to verify certificate signatures.

We should really be setting a cipher spec instead of accepting anything; he got
cautious about saying what should be done by applications, but the impression I
was left with was that applications doing SSL need to know enough to have
policies and set defaults. "turn off SSL2 and export/weak ciphers, and you're
good to go" which he confirmed mapped to "ALL:!SSLv2:!LOW:!EXPORT:@STRENGTH"; I
presented what I personally set,
"ALL:!SSLv2:!LOW:!EXPORT:!ADH:!aNULL:!NULL:!DES:@STRENGTH" and got "sure.
that's a bit better" and "you might also disable EDH, which gives forward
secrecy but is also a cpu hog".

So there doesn't appear to be a good way to enable more hash types for
certificate validation without embedding knowledge of what to avoid.

If we think that SHA256 is something explicitly worth supporting for real world
production, as opposed to something someone is using in a private test-case,
then we can do:
EVP_add_digest(EVP_sha256())

(2008-08-13 17:59:49) Phil Pennock: So, we should be running
OpenSSL_add_all_algorithms(), we should be setting
SSL_CTX_set_cipher_list() and there is not at this time a convenient
interface to affect the normal internal
SSL_CTX_set_cert_verify_callback()-controlled chain, we have to embed knowledge
of poor ciphers in the normal application-specified callback (set by
SSL_CTX_set_verify()); and really, it boils down to "you're only going to
verify signed certs anyway, so if you don't trust the CA, don't have the CA in
the list" and it shouldn't matter past that?
(2008-08-13 18:00:32) Phil Pennock: for "convenient interface" I mean something
analogous to the cipher spec list for SSL_CTX_set_cipher_list() which can be
exposed as a string to administrator configuration.

(no response yet to confirm that, but that's the impression I'm left with)


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674




--- Comment #8 from Phil Pennock <exim-dev@spodhuis.org> 2008-08-14 02:46:32 ---
*sigh* In "of poor ciphers in the normal", I mis-spoke. Poor digest
algorithms. Sorry.


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

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

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674




--- Comment #9 from Phil Pennock <exim-dev@spodhuis.org> 2008-08-14 05:49:32 ---
Created an attachment (id=261)
--> (http://bugs.exim.org/attachment.cgi?id=261)
New global option, openssl_load_all

I think this is a reasonable compromise and sensible way forward for now,
without undermining the whole point of the exercise.

A new option, available when SUPPORT_TLS defined, "openssl_load_all". It's a
boolean, default false. It is a fatal error to set this true without also
defining "tls_require_ciphers".

The theory being that anyone who knows to load all algorithms knows enough to
make their own educated decision about a cipher policy but that loading all
algorithms has the risk of adding new dangerous ciphers that should not be
present and would be a security step backwards. This avoids Exim needing to
push a cipher which can become stale and puts Exim only in the position of
having some mild protection against accidental shooting of self in foot.

I was able to use Martin's sha256 stuff successfully with this patch.


Documentation patch to come next, when I write it.


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

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

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674




--- Comment #10 from Phil Pennock <exim-dev@spodhuis.org> 2008-08-14 06:17:09 ---
Created an attachment (id=262)
--> (http://bugs.exim.org/attachment.cgi?id=262)
Documentation patch

Here is the documentation for openssl-load-all.patch.

Note that as I don't have xmlto installed I can't actually verify that I've
done the right thing with all these markup tags. I am not familiar with
docbook. I hope that if nothing else the text is acceptable and some markup
fixups will have to be done by the committer (if the other patch is accepted).


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

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

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674




--- Comment #11 from Martin Kaiser <eximBugzilla@kaiser.cx> 2008-08-14 21:02:12 ---
(In reply to comment #9)

Hi Phil,

nice to see that there's been some activity about this bug lately ;-)

> Created an attachment (id=261)
--> (http://bugs.exim.org/attachment.cgi?id=261) [details]
> New global option, openssl_load_all
>
> I think this is a reasonable compromise and sensible way forward for now,
> without undermining the whole point of the exercise.
>
> A new option, available when SUPPORT_TLS defined, "openssl_load_all". It's a
> boolean, default false. It is a fatal error to set this true without also
> defining "tls_require_ciphers".
>
> The theory being that anyone who knows to load all algorithms knows enough to
> make their own educated decision about a cipher policy but that loading all
> algorithms has the risk of adding new dangerous ciphers that should not be
> present and would be a security step backwards. This avoids Exim needing to
> push a cipher which can become stale and puts Exim only in the position of
> having some mild protection against accidental shooting of self in foot.
>
> I was able to use Martin's sha256 stuff successfully with this patch.
>

no doubt that this is going to do the trick. However, I think this is quite
complicated for an admin. Thinking about the issue again, my preferred solution
would be to just add SHA256 by a call to EVP_AddDigest(). This way, we're not
accidentially enabling weak ciphers and there's no additional complexity for
the exim administrator. I would assume that X.509 certificates with
sha256-based signature (or more exactly pkcs1 1.5 signature using sha256) will
become more and more common.

Best regards,

Martin


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

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

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674




--- Comment #12 from Phil Pennock <exim-dev@spodhuis.org> 2008-08-14 21:31:18 ---
Do you have a pointer to a standards document or policy statement from a major
CA that they're going to start using sha256 publicly? Or Bruce Schneier saying
"Exim folks, just do it!" ;) (The latter would be good enough for me).

Exim really should not be getting into the digests business if we can avoid it;
we're not cryptographers (AFAIK) and we're not qualified to make assertions of
what people should or should not be using, especially if that becomes dated.

Now, my personal understanding is that the weaknesses in the current standards
means that sha256 is a favoured intermediate step pending the completion of
that NIST competition to find a new digest algorithm (similarly to the AES
competition). Our assumption is that it is true that sha256 will be actively
used in mainstream PKI then OpenSSL will be updated to load sha256 by default.

Before Exim's maintainers start going around second-guessing the maintainers of
cryptographic libraries that we depend upon, we need something firmer to verify
that, for instance, we're more pragmatic than the other maintainers; I've not
seen that verified and have no reason to believe it's true.

Until there's a major push to start actually using sha256 I believe that most
users touching it will be specialists able to configure software themselves,
knowing that they're doing, and able to set tls_require_ciphers. I understand
that this does not mesh well with network protocols where you're talking to
systems maintained by others, but what are the options here?

Traditionally, if someone cares enough and writes a patch, then the support
spreads and the personal interests of the specialists become supported because
they care; as long as that's not to the detriment of others, no real problem
here and we'd accept patches. However, this particular area is one of the Exim
project making assertions to others about what is or isn't safe. Before we do
*that*, we really have to set a higher bar, IMO. I'm sorry that you're being
held to a higher standard than is normal because of this.

Since Exim is not really an end-user application, providing knobs for
specialists to play with is fair enough. And if there's an OpenSSL API for
loading specific named algorithms which we can expose by just passing it a
string-list, so we could have "openssl_add_algorithm sha256" in a config file,
I personally would be happy to see that in the config. If nothing else, in the
event of a(nother) major cryptographic breakthrough acting as a forcing event
to get people using stronger hashes in x509 PKI, it's good to have the ability
to point to a configuration workaround before we bite the bullet and add the
override code as a default. Note that here, we'd still be reacting to a policy
statement from a major CA and the only reason for adding the explicit load
would be that it lets us react faster than the lifecycle for getting a library
rolled out by all our users. On mail-systems, I suspect that Exim updates are
tracked more closely than OpenSSL ones.

It's an ugly situation.


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

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

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674




--- Comment #13 from Phil Pennock <exim-dev@spodhuis.org> 2008-08-15 12:56:34 ---
You're not likely to have long to wait. RFC 5246 is now out, specifying TLS
1.2.

----------------------------8< cut here >8------------------------------
1.2. Major Differences from TLS 1.1

This document is a revision of the TLS 1.1 [TLS1.1] protocol which
contains improved flexibility, particularly for negotiation of
cryptographic algorithms. The major changes are:

- The MD5/SHA-1 combination in the pseudorandom function (PRF) has
been replaced with cipher-suite-specified PRFs. All cipher suites
in this document use P_SHA256.
[...]
----------------------------8< cut here >8------------------------------

I've just checked with someone heavily involved in the OpenSSL project and it's
likely that sha256 will be loaded by default soon.

Which then just leaves the patch I offered as a way for people to tune knobs
without being dependent upon the Exim developers.


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

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

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674




--- Comment #14 from Martin Kaiser <eximBugzilla@kaiser.cx> 2008-08-15 19:16:09 ---
(In reply to comment #13)

Phil,

thanks a lot for this information. No doubt it's the cleanest solution if
OpenSSL loads SHA256 by default.

Best regards,

Martin


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

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