Re: Case-sensitive cipher names are a bad idea

[Jeffrey Walton]

On Sat, Aug 16, 2014 at 12:08 AM,   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

Re: Case-sensitive cipher names are a bad idea

[shathawa]

> 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.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

Error while attempting to create an Intermediate Root CA

[Michael G. Zajac]

This one really has me turned around…

I am receiving AKID errors which I have seen earlier:

 *Error Loading extension section v3_x509*

*2283200:error:22077079:X509 V3 routines:V2I_AUTHORITY_KEYID:no issuer
certificate:v3_akey.c:153:*

*2283200:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in
extension:v3_conf.c:93extension:v3_conf.c:93:name=authorityKeyIdentifier,
value=keyid*

What I believe this means is that the Authority Key Identifier cannot find
the issuing certificate, or in this case, the Root Certificate Authority.

To amend this I coded a CSR – Certificate Signing Request for the
intermediate Certificate Authority, batched in the CSR and it worked and
wrote the certificate out to the database without error.

I verified the validity of the intermediate certificate and concatenated
the Intermediate Certificate Authority and the Root Certificate Authority.

In sum, everything looks fine; the exception being the AKID in the v3_x509
extensions is missing.

I was wondering if there is a way to manually pass in the
*authorityKeyIdentifier=keyid* value in OpenSSL for the intermediate CA?
 It exists in the Root CA which does not make sense…

Kindest Regards,

 *Michael *   |   Analytics Support Engineer

RE: Case-sensitive cipher names are a bad idea

[Salz, Rich]

> 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

[Michael Wojcik]

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 
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

[Salz, Rich]

> 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

[Viktor Dukhovni]

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

[Walter H.]

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: Error Handling in a Multithreaded Environment, Failures effecting non-associated connections

[David Hinkle]

Thanks!


On Fri, Aug 15, 2014 at 10:50 AM, Salz, Rich  wrote:

> > Just so I make sure I understand, I just need to do something like:
> > while ((err = ERR_get_error()));
> > When I switch work and everything will be ok?
>
> Simpler to just call ERR_clear_error()
>
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge MA
> IM: rs...@jabber.me Twitter: RichSalz
>



-- 
*David Hinkle*

*Senior Software Developer*

*Phone:*  800.243.3729x3000

*Email:*  hin...@cipafilter.com

*Hours:*  Mon-Fri   8:00AM-5:00PM (CT)

RE: using openssl to generate SAN seems not working...

[Wellen Lau]

Pls ignore this. I got it works properly now.

 

From: Wellen Lau 
Sent: Thursday, August 14, 2014 10:50 AM
To: openssl-...@openssl.org; openssl-users@openssl.org
Subject: using openssl to generate SAN seems not working...

 

Hi All,

 

I am having trouble to use enable the Subject AlterName in generating CSR or 
signing the cert. I did google on it and found few places mentioning as below. 
Does it work ? or something has been broken?

 

This is my configuration file : openssl.conf

[ req ]

req_extensions = v3_req

 

[v3_req]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectAltName = @alt_names

 

[alt_names]

DNS.1 = ABC1.com

DNS.2 = ABC5.com

DNS.3 = ABC1*.com

DNS.4 = ABC1.net

 

I have downloaded both  http://www.openssl.org/source/ ( do compile into 
executable) and also  binary(https://www.openssl.org/related/binaries.html) to 
tried but I am not able to see my CSR or my cert being signed with my CA to 
have SAN.

 

Generating CSR :

D:\OpenSSL-1.0.1i-bin\work>openssl req -config openssl.conf -extensions v3_req 
-new -key keys\ san.key -out requests\san.csr

D:\OpenSSL-1.0.1i-bin\work>openssl req -text -noout -in requests\ san.csr

I could not see the SAN information.

 

Sigining the Cert with my CA:

D:\OpenSSL-1.0.1i-bin\work>openssl x509 -req -extfile openssl.conf -extensions 
v3_req -days 365 -in requests\san.csr -CA certs\ca.cer -CAkey keys\ca.key 
-set_serial 01 -out certs\san.cer

 

 

Please enlightened me on this.

Thanks in advance.

RE: Error Handling in a Multithreaded Environment, Failures effecting non-associated connections

[Salz, Rich]

> Just so I make sure I understand, I just need to do something like:
> while ((err = ERR_get_error()));
> When I switch work and everything will be ok?

Simpler to just call ERR_clear_error()

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
:��I"Ϯ��r�m
(Z+�K�+1���x��h[�z�(Z+���f�y���f���h��)z{,���

Case-sensitive cipher names are a bad idea

[Salz, Rich]

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.me Twitter: RichSalz

using openssl to generate SAN seems not working...

[Wellen Lau]

Hi All,

 

I am having trouble to use enable the Subject AlterName in generating CSR or 
signing the cert. I did google on it and found few places mentioning as below. 
Does it work ? or something has been broken?

 

This is my configuration file : openssl.conf

[ req ]

req_extensions = v3_req

 

[v3_req]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectAltName = @alt_names

 

[alt_names]

DNS.1 = ABC1.com

DNS.2 = ABC5.com

DNS.3 = ABC1*.com

DNS.4 = ABC1.net

 

I have downloaded both  http://www.openssl.org/source/ ( do compile into 
executable) and also  binary(https://www.openssl.org/related/binaries.html) to 
tried but I am not able to see my CSR or my cert being signed with my CA to 
have SAN.

 

Generating CSR :

D:\OpenSSL-1.0.1i-bin\work>openssl req -config openssl.conf -extensions v3_req 
-new -key keys\ san.key -out requests\san.csr

D:\OpenSSL-1.0.1i-bin\work>openssl req -text -noout -in requests\ san.csr

I could not see the SAN information.

 

Sigining the Cert with my CA:

D:\OpenSSL-1.0.1i-bin\work>openssl x509 -req -extfile openssl.conf -extensions 
v3_req -days 365 -in requests\san.csr -CA certs\ca.cer -CAkey keys\ca.key 
-set_serial 01 -out certs\san.cer

 

 

Please enlightened me on this.

Thanks in advance.