Re: ALL vs DEFAULT or how to properly order anonymous ciphers?
On Mon, Feb 19, 2007 at 02:19:27PM -0500, Victor Duchovni wrote:
[...] I
think it is cleaner to put the anonymous kEECDH and kEDH ciphers first,
they use the strongest key-exchange mechanisms available, and best meed
the authentication needs of apps that ignore authentication.
Allowing anonymous ciphersuites does not always mean that the
application will ignore authentication, though. Many applications
will merely tolerate anonymous ciphersuites, but still prefer
authenticated ciphersuites if they can get one of those.
I also think that kEECDH should be sorted ahead of kEDH, within the class
of forward secrecy capable key-exchange mechanisms.
Yes, that's reasonable. The current ciphersuite list processing code
doesn't keep the order of deleted ciphersuites sufficiently stable to
express this, but with some further changes this can be done:
Index: ssl_ciph.c
===
RCS file: /e/openssl/cvs/openssl/ssl/ssl_ciph.c,v
retrieving revision 1.68
diff -u -r1.68 ssl_ciph.c
--- ssl_ciph.c 20 Feb 2007 13:25:36 - 1.68
+++ ssl_ciph.c 20 Feb 2007 15:45:29 -
@@ -476,7 +476,7 @@
*head=curr-next;
if (curr-prev != NULL)
curr-prev-next=curr-next;
- if (curr-next != NULL) /* should always be true */
+ if (curr-next != NULL)
curr-next-prev=curr-prev;
(*tail)-next=curr;
curr-prev= *tail;
@@ -484,6 +484,22 @@
*tail=curr;
}
+static void ll_append_head(CIPHER_ORDER **head, CIPHER_ORDER *curr,
+CIPHER_ORDER **tail)
+ {
+ if (curr == *head) return;
+ if (curr == *tail)
+ *tail=curr-prev;
+ if (curr-next != NULL)
+ curr-next-prev=curr-prev;
+ if (curr-prev != NULL)
+ curr-prev-next=curr-next;
+ (*head)-prev=curr;
+ curr-next= *head;
+ curr-prev=NULL;
+ *head=curr;
+ }
+
static void ssl_cipher_get_disabled(unsigned long *mkey, unsigned long *auth,
unsigned long *enc, unsigned long *mac, unsigned long *ssl)
{
*mkey = 0;
@@ -586,19 +602,27 @@
/*
* Prepare linked list from list entries
*/
- for (i = 1; i co_list_num - 1; i++)
- {
- co_list[i].prev = (co_list[i-1]);
- co_list[i].next = (co_list[i+1]);
- }
if (co_list_num 0)
{
- (*head_p) = (co_list[0]);
- (*head_p)-prev = NULL;
- (*head_p)-next = (co_list[1]);
- (*tail_p) = (co_list[co_list_num - 1]);
- (*tail_p)-prev = (co_list[co_list_num - 2]);
- (*tail_p)-next = NULL;
+ co_list[0].prev = NULL;
+
+ if (co_list_num 1)
+ {
+ co_list[0].next = co_list[1];
+
+ for (i = 1; i co_list_num - 1; i++)
+ {
+ co_list[i].prev = co_list[i - 1];
+ co_list[i].next = co_list[i + 1];
+ }
+
+ co_list[co_list_num - 1].prev = co_list[co_list_num -
2];
+ }
+
+ co_list[co_list_num - 1].next = NULL;
+
+ *head_p = co_list[0];
+ *tail_p = co_list[co_list_num - 1];
}
}
@@ -679,22 +703,38 @@
int rule, int strength_bits,
CIPHER_ORDER **head_p, CIPHER_ORDER **tail_p)
{
- CIPHER_ORDER *head, *tail, *curr, *curr2, *tail2;
+ CIPHER_ORDER *head, *tail, *curr, *curr2, *last;
SSL_CIPHER *cp;
+ int reverse = 0;
#ifdef CIPHER_DEBUG
printf(Applying rule %d with %08lx/%08lx/%08lx/%08lx/%08lx %08lx
(%d)\n,
rule, alg_mkey, alg_auth, alg_enc, alg_mac, alg_ssl,
algo_strength, strength_bits);
#endif
- curr = head = *head_p;
- curr2 = head;
- tail2 = tail = *tail_p;
+ if (rule == CIPHER_DEL)
+ reverse = 1; /* needed to maintain sorting between currently
deleted ciphers */
+
+ head = *head_p;
+ tail = *tail_p;
+
+ if (reverse)
+ {
+ curr = tail;
+ last = head;
+ }
+ else
+ {
+ curr = head;
+ last = tail;
+ }
+
+ curr2 = curr;
for (;;)
{
- if ((curr == NULL) || (curr == tail2)) break;
+ if ((curr == NULL) || (curr == last)) break;
curr = curr2;
- curr2 = curr-next;
+ curr2 = reverse ? curr-prev : curr-next;
cp = curr-cipher;
@@ -736,6 +776,7 @@
/* add the cipher if it has not been added
Re: ALL vs DEFAULT or how to properly order anonymous ciphers?
On Mon, Feb 19, 2007 at 02:19:27PM -0500, Victor Duchovni wrote: Regardless of the specific details, using a comparator makes the order more systematic. One can still quible over whether anonymous auth beats RSA auth, and I may not get my wish there, but I still think a sort based based on a linear order should be considered. Perhaps this is impractical, but it seems tempting to me... One advantage of using ssl_cipher_apply_rule() for all of this in ssl_ciph.c is that we can see how well ssl_cipher_apply_rule() does this kind of job (in terms of bugs, and missing features) -- we sort the ciphersuite list only in the kind of ways that are available to textual ciphersuite list specifications. Bodo __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ALL vs DEFAULT or how to properly order anonymous ciphers?
On Mon, Feb 19, 2007 at 03:22:44PM -0500, Victor Duchovni wrote: As far as the 0.9.9 patch is concerned, is it possible to cache the initial sorted order? Some applications process cipherlists for every connection (destination dependent cipher lists), and it would be nice to keep this efficient, provided that there is negligbible or no additional cost for applications that set the cipherlist only once. It's true that the sorted order of ALL should be generated just once, and then cached, for better efficiency. Where and how to do this caching, though, is an optimization decision that will introduce certain complications, and should only be done once we are sure that the ciphersuite sorting code itself is OK. I'm thinking of caching the sorted list once per SSL_CTX, eventually. Bodo __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ALL vs DEFAULT or how to properly order anonymous ciphers?
On Tue, Feb 20, 2007 at 05:08:07PM +0100, Bodo Moeller wrote: On Mon, Feb 19, 2007 at 03:22:44PM -0500, Victor Duchovni wrote: As far as the 0.9.9 patch is concerned, is it possible to cache the initial sorted order? Some applications process cipherlists for every connection (destination dependent cipher lists), and it would be nice to keep this efficient, provided that there is negligbible or no additional cost for applications that set the cipherlist only once. It's true that the sorted order of ALL should be generated just once, and then cached, for better efficiency. Where and how to do this caching, though, is an optimization decision that will introduce certain complications, and should only be done once we are sure that the ciphersuite sorting code itself is OK. Makes sense. I'm thinking of caching the sorted list once per SSL_CTX, eventually. That seems very reasonable. In the mean-time, in Postfix 2.4, I am caching the cipher_list string that was last applied to SSL_CTX, so in the typical case that successive connections re-use the same cipherlist, additional NOOP calls to SSL_CTX_set_cipher_list() are avoided. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ALL vs DEFAULT or how to properly order anonymous ciphers?
On Sat, Feb 17, 2007 at 11:45:58PM -0500, Victor Duchovni wrote:
Currently the OpenSSL DEFAULT cipherlist serves two functions:
- Sort the cipherlist to put the strongest, most desirable algorithms
first.
- Exclude ciphers that most applications should not be exposed to.
Applications that don't need/want ciphers outside the DEFAULT list
can further restrict the cipher choice with DEFAULT:!this:!that ...
Things get more complicated for applications that want to support
anonymous ciphers but still maintain a sensible cipher order: [...]
... since once you've used DEFAULT, which involves !ADH or
!ADH:!AECDH (both of which really should be !aNULL), you cannot
re-enable anonymous ciphersuites.
(!this unlike -this thoroughly disables the ciphersuite so that
even !this:this cannot add it. E.g., RSA:!RSA:RSA is empty,
whereas RSA:-RSA:RSA is equivalent to RSA. It is intentional
that DEFAULT is that strict. In fact, DEFAULT should be just as
strict about ciphersuites without encryption, which it doesn't enable
but doesn't thoroughly disable either -- DEFAULT:RSA will enable
unencrypted authentication-only ciphersuites! This is a bug to
be fixed.)
I am therefore asking the team to consider splitting the two features:
- Sensible default order
- Non-default cipher exclusion
into two parts. The first part (ordering), should I believe be a feature
of the ALL cipher_alias:
ALL = preferred:all:+low-pref:@STRENGTH
(preferred = AES:CAMELLIA)
(all = legacy ALL cipher list)
(low-pref = +aECDH:+kRSA:+RC4)
an then DEFAULT is simply a filter on the already ordered ALL list:
DEFAULT = ALL:!aNULL.
This would allow applications using ALL (or legacy ALL:+RC4:@STRENGTH
which would be an equivalent more cumbersome way of getting the same
result) to portably (release to release) arrive at a sensible cipherlist
order.
Yes, this makes sense. Currently, ciphers start being ordered by ID,
which is rather arbitrary. Here's a patch that uses a reasonable
order for ALL instead, and also includes !eNULL in DEFAULT.
This will go into the 0.9.9 branch.
Bodo
+++ ssl/ssl.h 19 Feb 2007 18:39:53 -
@@ -315,8 +315,13 @@
/* The following cipher list is used by default.
* It also is substituted when an application-defined cipher list string
* starts with 'DEFAULT'. */
-#define SSL_DEFAULT_CIPHER_LIST
AES:CAMELLIA:ALL:!ADH:!AECDH:+aECDH:+kRSA:+RC4:@STRENGTH
-/* low priority for ciphersuites w/o forwared secrecy (fixed ECDH, RSA key
exchange), and for RC4 */
+#define SSL_DEFAULT_CIPHER_LISTALL:!aNULL:!eNULL
+/* As of OpenSSL 0.9.9, ssl_create_cipher_list() in ssl/ssl_ciph.c always
+ * starts with a reasonable order, and all we have to do for DEFAULT is
+ * throwing out anonymous and unencrypted ciphersuites!
+ * (The latter are not actually enabled by ALL, but ALL:RSA would enable
+ * some of them.)
+ */
/* Used in SSL_set_shutdown()/SSL_get_shutdown(); */
#define SSL_SENT_SHUTDOWN 1
Index: ssl/ssl_ciph.c
===
RCS file: /e/openssl/cvs/openssl/ssl/ssl_ciph.c,v
retrieving revision 1.66
diff -u -r1.66 ssl_ciph.c
--- ssl/ssl_ciph.c 17 Feb 2007 06:45:37 - 1.66
+++ ssl/ssl_ciph.c 19 Feb 2007 18:39:53 -
@@ -1120,6 +1120,40 @@
disabled_mkey, disabled_auth, disabled_enc,
disabled_mac, disabled_ssl,
co_list, head, tail);
+
+ /* Now arrange all ciphers by preference: */
+
+ /* Temporarily enabled AES first (preferred cipher) */
+ ssl_cipher_apply_rule(0, 0, 0, SSL_AES, 0, 0, 0, CIPHER_ADD, -1, head,
tail);
+
+ /* Temporarily enable everything else */
+ ssl_cipher_apply_rule(0, 0, 0, 0, 0, 0, 0, CIPHER_ADD, -1, head,
tail);
+
+ /* Move anonymous ciphers to the end. Usually, these will remain
disabled.
+* (For applications that allow them, they aren't too bad, but we prefer
+* authenticated ciphers.) */
+ ssl_cipher_apply_rule(0, 0, SSL_aNULL, 0, 0, 0, 0, CIPHER_ORD, -1,
head, tail);
+
+ /* Move ciphers without forward secrecy to then end */
+ ssl_cipher_apply_rule(0, 0, SSL_aECDH, 0, 0, 0, 0, CIPHER_ORD, -1,
head, tail);
+ ssl_cipher_apply_rule(0, SSL_kRSA, 0, 0, 0, 0, 0, CIPHER_ORD, -1,
head, tail);
+ ssl_cipher_apply_rule(0, 0, SSL_kPSK, 0, 0, 0, 0, CIPHER_ORD, -1,
head, tail);
+
+ /* RC4 is sort-of broken -- move the the end */
+ ssl_cipher_apply_rule(0, 0, 0, SSL_RC4, 0, 0, 0, CIPHER_ORD, -1, head,
tail);
+
+ /* Now sort by symmetric encryption strength. The above ordering
remains
+* in force within each class */
+ if (!ssl_cipher_strength_sort(head, tail))
+ {
+ OPENSSL_free(co_list);
+ return NULL;
+ }
+
+ /* Now disable everything (maintaining the ordering
Re: ALL vs DEFAULT or how to properly order anonymous ciphers?
On Mon, Feb 19, 2007 at 07:43:50PM +0100, Bodo Moeller wrote:
Thanks, a giant leap in the right direction! Nit-picking below:
+ /* Move anonymous ciphers to the end. Usually, these will remain
disabled.
+ * (For applications that allow them, they aren't too bad, but we prefer
+ * authenticated ciphers.) */
+ ssl_cipher_apply_rule(0, 0, SSL_aNULL, 0, 0, 0, 0, CIPHER_ORD, -1,
head, tail);
This is not quite right IMHO. I think the anonymous ciphers MUST be
first, because:
1. Most applications use DEFAULT and don't see them at all.
2. Applications that want anonymous ciphers, typically don't disable
the non-anonymous ones for interoperability reasons, so won't get to
use them if they are not first.
3. Applications that are happy with anonymous ciphers don't check
certs, so there is no reason to prefer ciphers with with certs, which
just waste cycles.
If the anonymous ciphers are last, perhaps:
ALL+aNULL:ALL:@STRENGTH
produces the desired order for applications that don't check certs, but I
think it is cleaner to put the anonymous kEECDH and kEDH ciphers first,
they use the strongest key-exchange mechanisms available, and best meed
the authentication needs of apps that ignore authentication.
I also think that kEECDH should be sorted ahead of kEDH, within the class
of forward secrecy capable key-exchange mechanisms.
The current somewhat adhoc initial order could be replaced by sort()
(need not be stable for initial order) based on a systematic comparator:
int ciph_compare(c1, c2)
{
if ((ret = (strength_compare(strength(c1), strength(c2 != 0)
return ret;
if ((ret = (enc_compare(enc(c1), enc(c2 != 0)
return ret;
if ((ret = (kx_compare(kx(c1), kx(c2 != 0)
return ret;
if ((ret = (auth_compare(auth(c1), auth(c2 != 0)
return ret;
if ((ret = (mac_compare(mac(c1), mac(c2 != 0)
return ret;
if ((ret = (proto_compare(proto(c1), proto(c2 != 0)
return ret;
}
One then needs to decide how to separately rank the available ciphers,
key exchange mechanisms, ... and whether the above relative order of
comparisons (alg_bits, cipher, key-exchange, auth, mac, proto) is
the right one.
Regardless of the specific details, using a comparator makes the order
more systematic. One can still quible over whether anonymous auth beats
RSA auth, and I may not get my wish there, but I still think a sort based
based on a linear order should be considered. Perhaps this is impractical,
but it seems tempting to me...
--
/\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
and use is prohibited.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: ALL vs DEFAULT or how to properly order anonymous ciphers?
On Mon, Feb 19, 2007 at 02:19:27PM -0500, Victor Duchovni wrote: This is not quite right IMHO. I think the anonymous ciphers MUST be first, because: 1. Most applications use DEFAULT and don't see them at all. 2. Applications that want anonymous ciphers, typically don't disable the non-anonymous ones for interoperability reasons, so won't get to use them if they are not first. 3. Applications that are happy with anonymous ciphers don't check certs, so there is no reason to prefer ciphers with with certs, which just waste cycles. If the anonymous ciphers are last, perhaps: ALL+aNULL:ALL:@STRENGTH produces the desired order for applications that don't check certs, but I think it is cleaner to put the anonymous kEECDH and kEDH ciphers first, they use the strongest key-exchange mechanisms available, and best meed the authentication needs of apps that ignore authentication. Well, I have tested the ALL+aNULL:ALL:+RC4:@STRENGTH form against the new 0.9.9 code and current 0.9.7 and 0.9.8. And it behaves as I had hoped, so while I still think that aNULL should be first, if the consensus is that it should not, I have a work-around. As far as the 0.9.9 patch is concerned, is it possible to cache the initial sorted order? Some applications process cipherlists for every connection (destination dependent cipher lists), and it would be nice to keep this efficient, provided that there is negligbible or no additional cost for applications that set the cipherlist only once. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
ALL vs DEFAULT or how to properly order anonymous ciphers?
Currently the OpenSSL DEFAULT cipherlist serves two functions: - Sort the cipherlist to put the strongest, most desirable algorithms first. - Exclude ciphers that most applications should not be exposed to. Applications that don't need/want ciphers outside the DEFAULT list can further restrict the cipher choice with DEFAULT:!this:!that ... Things get more complicated for applications that want to support anonymous ciphers but still maintain a sensible cipher order: - With OpenSSL 0.9.7 we have: #define SSL_DEFAULT_CIPHER_LIST \ ALL:!ADH:+RC4:@STRENGTH - With OpenSSL 0.9.8 we have: #ifdef OPENSSL_NO_CAMELLIA # define SSL_DEFAULT_CIPHER_LIST\ ALL:!ADH:+RC4:@STRENGTH #else # define SSL_DEFAULT_CIPHER_LIST\ AES:CAMELLIA:-ECCdraft:ALL:!ADH:+RC4:@STRENGTH #endif - With OpenSSL 0.9.9 (dev) we have: #define SSL_DEFAULT_CIPHER_LIST \ AES:CAMELLIA:ALL:!ADH:!AECDH:+aECDH:+kRSA:+RC4:@STRENGTH If one wants a correctly ordered cipherlist with anonymous ciphers left in, one needs to use: - 0.9.7 ALL:+RC4:@STRENGTH - 0.9.8 (default build) ALL:!ADH:+RC4:@STRENGTH - 0.9.8 ( enable-camellia ) AES:CAMELLIA:ALL:+RC4:@STRENGTH removing ECCdraft is not necessary, because these are already excluded from the ALL cipher alias. - 0.9.9 AES:CAMELLIA:ALL:+aECDH:+kRSA:+RC4:@STRENGTH This volatility from release to release makes it impractical to define a correctly ordered default cipher list for aNULL applications that survives upgrades in the OpenSSL library with configuration changes in the application. Now it is true that the 0.9.9 list can be used with reasonably good results with 0.9.8 and 0.9.7 resulting in only minor deviations from the native (DEFAULT with aNULL left in) order for the earlier releases, the diffence being that ADH precedes kRSA in more cases (which is desirable). Still, the DEFAULT order is likely to change yet again in future releases, and it is going to be difficult to play catchup with an ever evolving DEFAULT cipher list. I am therefore asking the team to consider splitting the two features: - Sensible default order - Non-default cipher exclusion into two parts. The first part (ordering), should I believe be a feature of the ALL cipher_alias: ALL = preferred:all:+low-pref:@STRENGTH (preferred = AES:CAMELLIA) (all = legacy ALL cipher list) (low-pref = +aECDH:+kRSA:+RC4) an then DEFAULT is simply a filter on the already ordered ALL list: DEFAULT = ALL:!aNULL. This would allow applications using ALL (or legacy ALL:+RC4:@STRENGTH which would be an equivalent more cumbersome way of getting the same result) to portably (release to release) arrive at a sensible cipherlist order. Comments? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Anonymous Ciphers
Title: Anonymous Ciphers Good Morning All, I am trying to match up some anonymous ciphers to use between JSSE and OpenSSL. I did a dump of JSSE and came across some anonymous ciphers. I then did a dump of the ciphers built into my build of OpenSSL. I did see any that specifically said anonymous so I must be reading them wrong. Now if I use an anonymous cipher suite I do not need to have a public/private key pair for the server nor the client correct? My main goal is to have encryption but not authentication. I would prefer to use DH anonymous with 3DES. I did not see that for OpenSSL though. It doesn't look to me like I have all the ciphers but I could be wrong. Just thought I would start out the day with a seemingly easy question. I just wanted to consort with you guys/gals first. Thanks! - Andrew JSSE SSL_DH_anon_WITH_DES_CBC_SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_RC4_128_MD5 SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 OpenSSL --- EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DES-CBC3-MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 DHE-DSS-RC4-SHA SSLv3 Kx=DH Au=DSS Enc=RC4(128) Mac=SHA1 IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 IDEA-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-64-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(64) Mac=MD5 EXP1024-DHE-DSS-RC4-SHA SSLv3 Kx=DH(1024) Au=DSS Enc=RC4(56) Mac=SHA1 export EXP1024-RC4-SHA SSLv3 Kx=RSA(1024) Au=RSA Enc=RC4(56) Mac=SHA1 export EXP1024-DHE-DSS-DES-CBC-SHA SSLv3 Kx=DH(1024) Au=DSS Enc=DES(56) Mac=SHA1 export EXP1024-DES-CBC-SHA SSLv3 Kx=RSA(1024) Au=RSA Enc=DES(56) Mac=SHA1 export EXP1024-RC2-CBC-MD5 SSLv3 Kx=RSA(1024) Au=RSA Enc=RC2(56) Mac=MD5 export EXP1024-RC4-MD5 SSLv3 Kx=RSA(1024) Au=RSA Enc=RC4(56) Mac=MD5 export EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5 EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export - Andrew T. Finnell Software Engineer eSecurity Inc (321) 394-2485
Re: Anonymous Ciphers
On Mon, Dec 17, 2001 at 09:49:37AM -0500, Andrew Finnell wrote: I am trying to match up some anonymous ciphers to use between JSSE and OpenSSL. I did a dump of JSSE and came across some anonymous ciphers. I then did a dump of the ciphers built into my build of OpenSSL. I did see any that specifically said anonymous so I must be reading them wrong. Now if I use an anonymous cipher suite I do not need to have a public/private key pair for the server nor the client correct? My main goal is to have encryption but not authentication. I would prefer to use DH anonymous with 3DES. I did not see that for OpenSSL though. It doesn't look to me like I have all the ciphers but I could be wrong. Just thought I would start out the day with a seemingly easy question. I just wanted to consort with you guys/gals first. Thanks! man ciphers (espcially look for ADH) man SSL_CTX_set_cipher_list Best regard, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
