[ I am documenting protocol and cipherlist selection for Postfix 2.3
users, and want to get a solid understanding of the details first... ]
1. ----
I am curious why among the 56 bit, non-RC4 ciphers:
EXP1024-DHE-DSS-DES-CBC-SHA Kx=DH(1024) Au=DSS Enc=DES(56) Mac=SHA1 export
EXP1024-DES-CBC-SHA Kx=RSA(1024) Au=RSA Enc=DES(56) Mac=SHA1 export
EXP1024-RC2-CBC-MD5 Kx=RSA(1024) Au=RSA Enc=RC2(56) Mac=MD5 export
EDH-RSA-DES-CBC-SHA Kx=DH Au=RSA Enc=DES(56) Mac=SHA1
EDH-DSS-DES-CBC-SHA Kx=DH Au=DSS Enc=DES(56) Mac=SHA1
DES-CBC-SHA Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1
the default order is as above, with the "EXP" ciphers before the "LOW"
ciphers? Naively one may surmise that the non-export "LOW" triplet is
stronger... The order comes out as I might expect if I use the more
explicit:
!aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH
which ensures that (RC4 aside) the export ciphers are listed after the LOW
ciphers. The default order appears to be a consequence of the fact that,
the "ALL" alias seems to list the TLSv1 ciphers before the SSLv3 ciphers.
Since @STRENGTH is a stable sort, the TLSv1 export ciphers sort before
the SSLv3 non-export ciphers of the same bit strength.
ALL == TLS1_TXT_ADH_WITH_AES_256_SHA
TLS1_TXT_DHE_RSA_WITH_AES_256_SHA
... more TLS1 ciphers ...
TLS1_TXT_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5
TLS1_TXT_RSA_EXPORT1024_WITH_RC4_56_MD5
SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
SSL3_TXT_EDH_RSA_DES_64_CBC_SHA
... more SSL3 ciphers ...
SSL3_TXT_ADH_RC4_128_MD5
SSL3_TXT_ADH_RC4_40_MD5
Does the subtle difference in order make any practical difference? Or does
the relative order of TLSv1 and SSLv3 ciphers not matter?
Specifically, can TLSv1 sessions use SSLv3 ciphers? Can SSLv3 sessions
use TLSv1 ciphers? What are the compatibility constraints when one
configures a specific protocol and cipherlist in the SSL_CTX?
2. ----
Minor deviation from the ciphers(1) documentation:
The default cipher list appears to be: ALL:!ADH:+RC4:@STRENGTH
rather than the documented: ALL:!ADH:RC4+RSA:+SSLv2:@STRENGTH
the documented DEFAULT produces substantially different results.
3. ----
One last thing, perhaps unfortunate wording, the ciphers(1) manpage says:
Additionally the cipher string @STRENGTH can be used at any point to
sort the current cipher list in order of encryption algorithm key
length.
while fortunately the implementation seems to use the more reasonable
metric of brute-force attack resistance:
ssl.h:
typedef struct ssl_cipher_st {
...
int strength_bits; /* Number of bits really used */
int alg_bits; /* Number of bits for algorithm */
...
} SSL_CIPHER;
ssl_ciph.c:
/*
* Now find the strength_bits values actually used
*/
curr = *head_p;
while (curr != NULL)
{
if (curr->active)
number_uses[curr->cipher->strength_bits]++;
curr = curr->next;
}
/*
* Go through the list of used strength_bits values in descending
* order.
*/
for (i = max_strength_bits; i >= 0; i--)
if (number_uses[i] > 0)
ssl_cipher_apply_rule(0, 0, 0, 0, 0, CIPHER_ORD, i,
co_list, head_p, tail_p);
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
