Re: [openssl-users] Case-sensitive cipher names are a bad idea
On 8/15/2014 10:10 PM, Jeffrey Walton wrote: On Sat, Aug 16, 2014 at 12:08 AM,shath...@e-z.net wrote: ... Even today with Unicode character set families, the ability to provide a global case-independent mapping becomes a massive problem. There are a variety of latin-like alphabets and greek alphabets, and even IBM EBCDIC encodings that are much unlike the US-ASCII character set. Even more problematic are the cyrillic, hebrew, aramaic, asian, and african alphabets. Do we need to accept transliteration to these various alphabetic schems? Traditionally, case-independence has been the conversion of US-ASCII and IBM EBCDIC encodings for named strings. In documentation languages, the use of various Unicode tablular character sets are used. How much of this above work needs to be accomplished so that name case-independent and character code table independence needs to be accomplished. Or should we just define a character encoding standard for the naming conventions and stick to the definitions? I believe they are discussing strings like used in cipher suites (for example, RC4-MD5). They are 8-bit clean. For the upcoming hostname matching gear, IDNs must be A-label form from RFC 6125, section 6.4.2. Jeff __ OpenSSL Projecthttp://www.openssl.org User Support Mailing listopenssl-us...@openssl.org Automated List managermajord...@openssl.org The general practice is to use 7-bit US_ASCII encoding or a transcoding into one of the transparent EBCDIC encoding for some mainframes based on IBM technology. Case independence is easy if you restrict yourself to the above code tables. Once you move to UTF-8 which may require an 8-bit clean transmission, the multi-byte content maps to a set of unicode characters in the range of 0x0001 - 0x10. There are a wide number of The older SIXBIT character system may still be in use on some systems, but is mostly obsolete. Steven J. Hathaway ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Case-sensitive cipher names are a bad idea
Does ANYONE think that case-sensitive cipher names are good idea? Someone who types TLSV1:RC4-MD5 will find things working, but is likely to be surprised by how weakly-protected they are. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
Re: Case-sensitive cipher names are a bad idea
Hello On 15.08.2014 17:43, Salz, Rich wrote: Does ANYONE think that case-sensitive cipher names are good idea? this is a bad idea; or can you explain the difference between tlsv1:rc4-md5 and TLSV1:RC4-MD5? Someone who types TLSV1:RC4-MD5 will find things working, but is likely to be surprised by how weakly-protected they are. the case of names doesn't make the cipher stronger ;-) Walter smime.p7s Description: S/MIME Cryptographic Signature
Re: Case-sensitive cipher names are a bad idea
On Fri, Aug 15, 2014 at 11:43:51AM -0400, Salz, Rich wrote: Does ANYONE think that case-sensitive cipher names are good idea? Someone who types TLSV1:RC4-MD5 will find things working, but is likely to be surprised by how weakly-protected they are. The case makes some things more clear: aRSA, kDHE, eNULL There are lots of other ways to typo the input string. To protect users from typos, raw cipherlist strings should not be exposed by applications as the primary user/administrator interface for cipher selection. Perhaps there are currently no collisions, and case folding is likely safe, but I don't really see much benefit from this. I think that's the wrong problem to invest time in. Instead, things like the security level interface in master, (which still needs some polish) are more like the way to go. The cipherlist mini-language is much too subtle for most users. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Case-sensitive cipher names are a bad idea
The case makes some things more clear: I never said it didn't. There are lots of other ways to typo the input string. Yup, but saying TLSV1 won't work while TLSv1 does work is silly. Perhaps there are currently no collisions, and case folding is likely safe, but I don't really see much benefit from this. I think that's the wrong problem to invest time in. Instead, things like the security level interface in master, (which still needs some polish) are more like the way to go. The cipherlist mini-language is much too subtle for most users. While I tend to agree (my test: explain the difference between ! and -), I have seen people hurt by this particular problem. I happen not to be thrilled with the security level interface, but that's me. Many people will find it useful. It will not address the problems some of us have. And as you point out, it's not done yet. I'm talking a bugfix-level patch to turn strncmp() in ssl/ssl_ciph.c to strncasecmp. Does anyone see a PROBLEM with this? /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Case-sensitive cipher names are a bad idea
Well, one problem is that strcasecmp is not in the Standard C Library, and in
fact is illegal, because external identifiers beginning with str are reserved
to the implementation.
There is no standard case-insensitive string-comparison function in C. You have
to write your own.
Here's one:
#include ctype.h
int cmpstri(const char *s1, const char *s2)
{
const unsigned char *us1 = (const unsigned char *)s1, *us2 = (const
unsigned char *)s2;
/***
Handle null inputs. This function treats null strings as equal to one
another
and less than non-null strings. Some applications might prefer different
semantics (e.g. treating null strings as empty strings).
***/
if (!s1 !s2) return 0;
else if (!s1) return -1;
else if (!s2) return 1;
/***
Compare strings. Use unsigned char because tolower is not guaranteed
with signed
input, and plain char may be signed (implemenation-dependent). ISO
9899-1990 7.3.
***/
while (*us1 || *us2)
{
unsigned char l1 = tolower(*us1), l2 = tolower(*us2);
if (l1 l2) return -1;
if (l2 l1) return 1;
us1++, us2++;
}
return 0;
}
(Untested, but copied with some modifications from an existing implementation.)
That said, I agree that case-insensitive comparison would be a good idea here.
--
Michael Wojcik
Technology Specialist, Micro Focus
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Salz, Rich
Sent: Friday, 15 August, 2014 14:36
To: openssl-users@openssl.org
Subject: RE: Case-sensitive cipher names are a bad idea
The case makes some things more clear:
I never said it didn't.
There are lots of other ways to typo the input string.
Yup, but saying TLSV1 won't work while TLSv1 does work is silly.
Perhaps there are currently no collisions, and case folding is likely safe,
but I
don't really see much benefit from this. I think that's the wrong problem
to
invest time in. Instead, things like the security level interface in
master,
(which still needs some polish) are more like the way to go. The
cipherlist
mini-language is much too subtle for most users.
While I tend to agree (my test: explain the difference between ! and -), I
have seen people hurt by this particular problem. I happen not to be
thrilled with the security level interface, but that's me. Many people will
find it useful. It will not address the problems some of us have.
And as you point out, it's not done yet.
I'm talking a bugfix-level patch to turn strncmp() in ssl/ssl_ciph.c to
strncasecmp.
Does anyone see a PROBLEM with this?
/r$
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
This message has been scanned for malware by Websense. www.websense.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Case-sensitive cipher names are a bad idea
Well, one problem is that strcasecmp is not in the Standard C Library, and in fact is illegal, because external identifiers beginning with str are reserved to the implementation. Openssl already handles that, thanks. That said, I agree that case-insensitive comparison would be a good idea here. Great. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Case-sensitive cipher names are a bad idea
Does ANYONE think that case-sensitive cipher names are good idea? Someone who types TLSV1:RC4-MD5 will find things working, but is likely to be surprised by how weakly-protected they are. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz --- Even today with Unicode character set families, the ability to provide a global case-independent mapping becomes a massive problem. There are a variety of latin-like alphabets and greek alphabets, and even IBM EBCDIC encodings that are much unlike the US-ASCII character set. Even more problematic are the cyrillic, hebrew, aramaic, asian, and african alphabets. Do we need to accept transliteration to these various alphabetic schems? Traditionally, case-independence has been the conversion of US-ASCII and IBM EBCDIC encodings for named strings. In documentation languages, the use of various Unicode tablular character sets are used. How much of this above work needs to be accomplished so that name case-independent and character code table independence needs to be accomplished. Or should we just define a character encoding standard for the naming conventions and stick to the definitions? Sincerely, Steven J. Hathaway __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Case-sensitive cipher names are a bad idea
On Sat, Aug 16, 2014 at 12:08 AM, shath...@e-z.net wrote: ... Even today with Unicode character set families, the ability to provide a global case-independent mapping becomes a massive problem. There are a variety of latin-like alphabets and greek alphabets, and even IBM EBCDIC encodings that are much unlike the US-ASCII character set. Even more problematic are the cyrillic, hebrew, aramaic, asian, and african alphabets. Do we need to accept transliteration to these various alphabetic schems? Traditionally, case-independence has been the conversion of US-ASCII and IBM EBCDIC encodings for named strings. In documentation languages, the use of various Unicode tablular character sets are used. How much of this above work needs to be accomplished so that name case-independent and character code table independence needs to be accomplished. Or should we just define a character encoding standard for the naming conventions and stick to the definitions? I believe they are discussing strings like used in cipher suites (for example, RC4-MD5). They are 8-bit clean. For the upcoming hostname matching gear, IDNs must be A-label form from RFC 6125, section 6.4.2. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
