On Mon, Jan 29, 2007 at 04:53:50PM -0500, Victor Duchovni wrote:
> Sun builds libcrypto with AES128 support, but without AES256 support.
>
> And attempts to paper-over the problem with a custom "DEFAULT" cipherlist,
> (but COMPLEMENTOFDEFAULT is wrong, and "ALL" and "HIGH" are not usable).
>
> When "ALL" is used instead of "DEFAULT", libssl believes that AES256 is
> present because AES128 is present:
>
> ssl_cipher_get_disabled():
>
> mask |= (ssl_cipher_methods[SSL_ENC_AES128_IDX] == NULL) ? SSL_AES:0;
>
> there is no separate probe for AES256, and no dedicated mask bit to tell
> the two apart.
>
> but I would like to find out whether this problem:
>
> - is likely to be resolved for AES256 in future OpenSSL releases
> (by separately testing for disabled AES256 and AES128, and not mixing
> AES128 in with the "HIGH" ciphers).
>
> - is not likely to be repeated with other ciphers in future OpenSSL
> releases (by ensuring that ssl_cipher_get_disabled() is not "fuzzy"
> and masks out all symmetric ciphers that are not available).
Is this the wrong forum for this type of question? I just downloaded
the 0.9.9 20070125 snapshot, and found the AES 128 vs AES 256 trap is
now possible also with CAMELLIA. If Sun or another distributor again
chooses to only implement the 128 bit and not the 256 bit cipher, the
disabled algorithm filter will once again break.
$ egrep -n AES ssl_ciph.c
154:#define SSL_ENC_AES128_IDX 6
155:#define SSL_ENC_AES256_IDX 7
244: {0,SSL_TXT_AES, 0,SSL_AES, 0,0,0,0,SSL_ENC_MASK,0},
289: ssl_cipher_methods[SSL_ENC_AES128_IDX]=
291: ssl_cipher_methods[SSL_ENC_AES256_IDX]=
407: case SSL_AES:
410: case 128: i=SSL_ENC_AES128_IDX; break;
411: case 256: i=SSL_ENC_AES256_IDX; break;
515: mask |= (ssl_cipher_methods[SSL_ENC_AES128_IDX] == NULL) ?
SSL_AES:0;
1223: case SSL_AES:
1226: case 128: enc="AES(128)"; break;
1227: case 192: enc="AES(192)"; break;
1228: case 256: enc="AES(256)"; break;
1229: default: enc="AES(?""?""?)"; break;
$ egrep -ni CAMELLIA ssl_ciph.c
156:#define SSL_ENC_CAMELLIA128_IDX 8
157:#define SSL_ENC_CAMELLIA256_IDX 9
245: {0,SSL_TXT_CAMELLIA, 0,SSL_CAMELLIA, 0,0,0,0,SSL_ENC_MASK,0},
293: ssl_cipher_methods[SSL_ENC_CAMELLIA128_IDX]=
294: EVP_get_cipherbyname(SN_camellia_128_cbc);
295: ssl_cipher_methods[SSL_ENC_CAMELLIA256_IDX]=
296: EVP_get_cipherbyname(SN_camellia_256_cbc);
415: case SSL_CAMELLIA:
418: case 128: i=SSL_ENC_CAMELLIA128_IDX; break;
419: case 256: i=SSL_ENC_CAMELLIA256_IDX; break;
516: mask |= (ssl_cipher_methods[SSL_ENC_CAMELLIA128_IDX] == NULL) ?
SSL_CAMELLIA:0;
1232: case SSL_CAMELLIA:
1235: case 128: enc="Camellia(128)"; break;
1236: case 256: enc="Camellia(256)"; break;
1237: default: enc="Camellia(?""?""?)"; break;
0.9.9 introduces:
ADH-CAMELLIA256-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-DSS-CAMELLIA256-SHA
CAMELLIA256-SHA
ADH-CAMELLIA128-SHA
DHE-RSA-CAMELLIA128-SHA
DHE-DSS-CAMELLIA128-SHA
CAMELLIA128-SHA
and it is possible to get handshake failures from/with systems that
implement only the weaker cipher grade in the CAMELLIA family. Even if
distributions *should not* implement only a subset of the ciphers in
a family, they likely will, and I am hoping that the library can be
more defensive in the face of partially implemented cipher families
in libcrypto.
Is this the right forum? I want to make that Postfix 2.4 is still correct
when OpenSSL 0.9.9 is released, and I am reluctant to augment the AES-256
work-around with a Camellia-256 work-around, ... I am looking for a more
systematic solution, ideally in the OpenSSL library.
Can ssl_cipher_get_disabled() be enhanced to distinguish between AES-128
and AES-256 or Camellia-128 and Camellia-256?
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
