[exim-dev] [Bug 674] exim can't verify sha256WithRSAEncrypti…

Pàgina inicial
Delete this message
Reply to this message
Autor: Phil Pennock
Data:  
A: exim-dev
Assumptes vells: [exim-dev] [Bug 674] New: exim can't verify sha256WithRSAEncryption signature in X. 509 certificates when linked against OpenSSL
Assumpte: [exim-dev] [Bug 674] exim can't verify sha256WithRSAEncryption signature in X.509 certificates when linked against OpenSSL
------- 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@???> 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