RE: Signature Algorithm that was disabled because that algorithm is not secure

[Paul Suhler]

Two weeks ago Viktor Dukhovni wrote:
> Actually, SHA-2 SHOULD NOT (yet) be used for signing certificates.
>
> Many TLSv1 clients don't support SHA-2 and servers must present
> SHA-1 certificates except when TLSv1.2 clients indicate SHA-2 support.  
> Fielding multiple certificates with different
> signature algorithms is too complex.

-
Good point.  Microsoft isn't rushing to drop recognition of SHA-1 signatures:

http://arstechnica.com/security/2013/11/hoping-to-avert-collision-with-disaster-microsoft-retires-sha1/

" The company's software will stop recognizing the validity of digital 
certificates that use the SHA1 cryptographic algorithm after 2016 ..."

Thanks,

Paul

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Signature Algorithm that was disabled because that algorithm is not secure

[Paul Suhler]

Note that SHA-1 is being deprecated by NIST for generating new signatures.  You 
may want to consider a SHA-2 algorithm (e.g., SHA-224 or SHA-256).  In 
principle it's still okay to *validate* legacy signatures, e.g., SHA-1.

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Walter H.
Sent: Wednesday, October 30, 2013 11:05
To: openssl-users@openssl.org
Subject: Re: Signature Algorithm that was disabled because that algorithm is 
not secure

Hello,

On 30.10.2013 18:17, Marcus Schmitt wrote:
> I have one problem after I created a root-CA, intermediate-CA and a server 
> certificate. After I configured my apache with the server cert, key and 
> intermediate cert and importing the root-CA to firefox 24 I received the 
> following error when I browse to the website:
>
> Could not verify this certificate because it was signed using a 
> signature algoritm that was disabled because that algorithm is not 
> secure
>
>
> I assume the reason for this error message is that I see "Certificate 
> Signatore Algorithm" is "PKCS #1 MD5 With RSA Encryption" for the 
> Intermediate Certificate and Server Certificate. For the root-CA I see "PKCS 
> #1 SHA With RSA Encryption".
>
> Unfortunately I was not able to find the reason for this issue, please find 
> the lines I use below:
>
The problem is not in one of these lines, it is in the config file openssl.cnf
> openssl genrsa -des3 -out private/cakey.pem 2048 -config ./openssl.cnf 
> openssl req -new -x509 -nodes -days 3650 -key private/cakey.pem -out 
> certs/cacert.pem -config openssl.cnf
>
> openssl genrsa -des3 -out private/cakey.pem 2048 -config ./openssl.cnf 
> openssl req -new -sha1 -key private/cakey.pem -out csr/ica.csr -config 
> ./openssl.cnf openssl ca -config ./openssl.cnf -days 1825 -md sha1 -in 
> ica.csr -out ica.crt -extensions v3_ca
>
> openssl genrsa -des3 -out server.key 2048 -config ./openssl.cnf 
> openssl req -new -sha1 -key private/server.key -out csr/server.csr 
> -config ./openssl.cnf openssl ca -config ./openssl.cnf -days 730 -md 
> sha1 -in server.csr -out server.crt
>
look if you find there something similiar to

default_md = md5

change this to

default_md = sha1

and generate your certificates the same way as above

Greetings,
Walter
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: SHA-3?

[Paul Suhler]

Oops.  Forgot the 

 

;-)

 

From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Paul Suhler
Sent: Tuesday, October 02, 2012 8:38 PM
To: openssl-users@openssl.org
Subject: SHA-3?

 

* PGP Bad Signature, Signed: 10/2/2012 at 8:38:22 PM

Any plans for Keccak / SHA-3?

 

http://www.nist.gov/itl/csd/sha-100212.cfm

 

Cheers,

 

Paul

 

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.


PGP.sig
Description: PGP signature

SHA-3?

[Paul Suhler]

Any plans for Keccak / SHA-3?

 

http://www.nist.gov/itl/csd/sha-100212.cfm

 

Cheers,

 

Paul

_
 
Paul A. Suhler, PhD | Firmware Engineer | Quantum Corporation | Office: 
949.856.7748 | paul.suh...@quantum.com  

be-certain_lockup.gif  

 

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.
<>

PGP.sig
Description: PGP signature

RE: OpenSSL FIPS Object Module v2.0 validation now complete

[Paul Suhler]

I see that the FIPS 2.0 tarball is not available online.  Moreover, the link to 
request a CD (http://openssl.com/fips/verify.html) doesn't work.

Thanks,

Paul
_
 
Paul A. Suhler, PhD | Firmware Engineer | Quantum Corporation | Office: 
949.856.7748 | paul.suh...@quantum.com

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.


PGP.sig
Description: PGP signature

RE: McAfee Claims TLS Vulnerability

[Paul Suhler]

Perhaps it's related to CVE-2011-4576:

https://kc.mcafee.com/corporate/index?page=content&id=KB75138&actp=LIST
and
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4576

"The SSL 3.0 implementation in OpenSSL before 0.9.8s and 1.x before 1.0.0f does 
not properly initialize data structures for block cipher padding, which might 
allow remote attackers to obtain sensitive information by decrypting the 
padding data sent by an SSL peer."


 
Paul A. Suhler, PhD | Firmware Engineer | Quantum Corporation | Office: 
949.856.7748 | paul.suh...@quantum.com  
Preserving the World's Most Important Data. Yours.T 

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Ben Laurie
Sent: Monday, April 30, 2012 1:32 AM
To: openssl-users@openssl.org
Subject: Re: McAfee Claims TLS Vulnerability

On Sun, Apr 29, 2012 at 10:40 PM, Mike Hoy  wrote:
> We use McAfee to scan our website for vulnerabilities. They claim the
> following:
>>
>> Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported.
>> Configure SSL/TLS servers to only support cipher suites that do not 
>> use block ciphers. Apply patches if available.

What kind of crazy advice is this?


--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: OpenSSL FIPS 2.0 Object Module platform questions

[Paul Suhler]

Where is the draft User Guide  for 2.0 available, please?  The most recent one 
that NIST has is for 1.2.3, dated about two weeks ago.

Thanks,

Paul
_
Paul A. Suhler, PhD | Firmware Engineer | Quantum Corporation | Office: 
949.856.7748 | paul.suh...@quantum.com
Preserving the World's Most Important Data. Yours.(tm)

From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of dave.mclel...@emc.com
Sent: Monday, April 02, 2012 5:14 AM
To: openssl-users@openssl.org
Subject: OpenSSL FIPS 2.0 Object Module platform questions


In the draft User Guide for the FIPS Object Module 2.0, the official validated 
platforms are shown as Linux and Windows, 32- and 64-bit architectures, with or 
without assembler optimizations.   The draft Security Policy mentions only 
Android 2.2 and HP-UX 11i in section 2: Tested Configurations, and mentions 
changes to accommodate cross-compilation for UCLinux.



QUESTION: The Security Policy for 1.2.2 specifically spells out the Linux and 
Windows validation platforms, but the draft 2.0 document does not.  What does 
this imply about what platforms will be considered validated on the 2.0 module?



The User's Guide also mentions success with the build on a number of other Unix 
platforms, and also uses 'Solaris 10' as an example of a platform appearing in 
section 5.5 in the statement of use of the Module.

QUESTION: even though Solaris is not shown as a validated platform, can we, 
having implemented with (OpenSSL 1.0.1 and FIPS 2.0) safely make a statement 
similar to the sample in Section 5.5 on the non-validated platforms?  That is, 
if we implement additionally on Solaris, HP, and Linux IA, for example, can we 
responsibly make the claim that we are using the validated Module on those 
platforms?

Thanks for any advice.

+-+-+-+-+-+-+
Dave McLellan, Symmetrix Software Engineering
EMC Corporation, 176 South St, Hopkinton MA
Mail Stop 176-B1 1/P-36
office 508-249-1257, fax 508-497-8027
cell 978-500-2546
+-+-+-+-+-+-+

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.

KAT for X9.31 Key Generation

[Paul Suhler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, developers.

 

I assume that the X9.31 key gen algorithm will be FIPS 140-2 certified, as it 
was in the FIPS module version 1.2.  Is the KAT  for X9.31 key generation 
covered by the PRNG testing in fips_rand_selftest.c::do_x931_test(), as an 
embedded crypto algorithm described in 140-2 IG section 9.2?

 

Or is its KAT implemented somewhere else?

 

Thanks very much,

 

Paul

_
 
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: 949.856.7748 
| paul.suh...@quantum.com    
Preserving the World's Most Important Data. Yours. 

 


-BEGIN PGP SIGNATURE-
Version: 10.2.0 (Build 1950)
Charset: iso-8859-1

wsBVAwUBTx7qpS8PM95JBvhoAQhNAggAoMhovZZFE1idgA9ryTtr4CaZnF6KMGB/
VkIVns4bKVFRzeGCSv5fADbb6MKX0YSV7O/P/NTtCzZKoMB9xQ6HVka/TML38Ohe
gRGPoE9TxKHOLX/hz3/5cLbUhqwLwiHLDcLsFMPUbVzjUKPSP62MaF9pltuwc+/d
uATEr4wnjp21clHvE4xhvEo8oFREC6BkfKcyfiWG12EjQhMJTEec8vEmBKg67iWB
I6NaGkdHf0WetfATY3CdQse0LUyQVX8ZJnTZ7N7dwqyOxtpiFSA6p70M+KQka/xG
Tkug2OnYy08kasnvbw4E9q9kFBoeckgtp6rbBLCqEVKQWejhXCDqrg==
=kARi
-END PGP SIGNATURE-

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.


PGPexch.htm.pgp
Description: PGPexch.htm.pgp

RE: openssl-1.0.1-stable-SNAP-20110927

[Paul Suhler]

I haven't tried your build process, but is the following still in 
ssl_lib.c::SSL_CTX_new()

/* Disable TLS v1.2 by default for now */
ret->options |= SSL_OP_NO_TLSv1_2;

Paul
_
 
Paul A. Suhler, PhD | Firmware Engineer | Quantum Corporation | Office: 
949.856.7748 | paul.suh...@quantum.com  
Preserving the World's Most Important Data. Yours.(tm) 

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Michael Haas
Sent: Thursday, September 29, 2011 1:40 AM
To: openssl-users@openssl.org
Subject: openssl-1.0.1-stable-SNAP-20110927

Hello,

i tried to enable TLS1.1 + TLS1.2 on Apache 2.2.21 with
openssl-1.0.1-stable-SNAP-20110927 but didn't succeed.
TLS 1.1 is working as excpected but TLS 1.2 not. I don't get a
connection with TLS1.2, tried IE9 and Opera.
Should TLS 1.2 work already with openssl 1.0.1 or is only the
implimentation of TLS 1.1 finished?

I get the following error in the apache log with
openssl s_client -tls1_2 -CAfile SSL_CA.pem -connect XXX.XXX.XXX.XXX:443
SSL Library Error: 336151598 error:1409442E:SSL
routines:SSL3_READ_BYTES:tlsv1 alert protocol version

Thanks in Advance
Michael
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

EVP_Cipher()

[Paul Suhler]

Hi, everyone.

 

(This got no response on the developers list, so I'll retry it here.)

 

Should EVP_Cipher() be used?  I've found an inconsistency in its return
values:  For the cipher EVP_aes_256_gcm, successful decryption returns
the length of the input.  (That's what aes_gcm_cipher() returns.)  For
other ciphers, like EVP_aes_256_cbc, EVP_Cipher() returns 1 for success.
Is this inconsistency indicative of a deprecated API that isn't being
maintained?  It's not documented on the website.

 

Thanks,

 

Paul


_ 
Paul A. Suhler, PhD | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com 

Preserving the World's Most Important Data. Yours.(tm) 

 

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.

RE: Usage of macro OPENSSL_NO_STDIO

[Paul Suhler]

One related caveat.  I've found that if OPENSSL_NO_FP_API is defined, then 
there will be some undefined symbol errors at compile time; some references to 
FILE, etc. are not conditionalized out.

However, I've done an embedded port to a non-standard OS, so your mileage may 
vary.

Paul
_
 
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: 949.856.7748 
| paul.suh...@quantum.com  
Preserving the World's Most Important Data. Yours.(tm) 

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Jeffrey Walton
Sent: Wednesday, August 17, 2011 4:31 PM
To: openssl-users@openssl.org
Subject: Re: Usage of macro OPENSSL_NO_STDIO

On Wed, Aug 17, 2011 at 1:51 PM, Kchitiz Saxena
 wrote:
> Hi Wim
> Thanks for the response. Actually, I am trying to compile openssl for WinCE
> 5.0. That's why I was trying to figure out whether I should define this
> macro while compiling or not. However, if this macro is defined, I get few
> compilation errors.
>
> Have anyone compiled the code with this flag for the same platform?
Yes. See Pierre Delaage's wcecompat at http://delaage.pierre.free.fr/.

>
> On Wed, Aug 17, 2011 at 10:59 PM, Wim Lewis  wrote:
>> On 17 Aug 2011, at 7:36 AM, Kchitiz Saxena wrote:
>> > Can somebody briefly explain the use of macro OPENSSL_NO_STDIO. There
>> > are few functions like SSL_CTX_use_certificate_file() which are defined 
>> > only
>> > if this macro is not defined. What is the functionality which is derived 
>> > out
>> > of this macro definition. In short, what I get/loose if I define this macro
>> > while compiling this macro.
>>
>> It removes functions which depend on the "stdio" functions (defined in
>> stdio.h, which perform I/O using the FILE * type). I assume this is useful
>> when openssl is being compiled for use in an embedded environment or other
>> special situation where stdio is not available.
>>
>> I think it's not a macro that users of openssl are expected to define;
>> instead, it's defined when openssl is configured, and users of the library
>> can check whether it's defined in openssl's headers (probably via
>> opensslconf.h).
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Question about signature_algorithms

[Paul Suhler]

Hi, all.

 

This question is perhaps best answered by Steve Henson, but I'll address
it to this list.

 

I've found that using openssl-SNAP-20110526, we send a Client Hello with
a signature_algorithms extension that apparently contains duplicate
entries.

 

If I understand RFC 5246 correctly, then this field contains pairs of
one-byte values, { hash, signature }.  If that's correct, then there are
17 pairs:

 

00:20

06:01

06:02

06:02

05:01

05:02

05:02

04:01

04:02

04:02

03:01

03:02

03:02

02:01

02:02

02:02

01:01

 

As you see, there are a number of duplicate entries.  Is this
potentially a problem?

 

Thanks,

 

Paul


_ 
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com 

Preserving the World's Most Important Data. Yours.(tm) 

 

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.

CVS Help, Please

[Paul Suhler]

Hi, everyone.

I've been trying to use the TortoiseCVS client (on WinXP) to access
cvs.openssl.org.  When I go to the Revision tab, select "Choose branch
or tag," and click on "Update list" I get a failure with the following
nearly-useless message:

In C:\Documents and Settings\suhlerp\My Documents\OpenSSL: "C:\Program
Files\CVS 
Suite\TortoiseCVS\cvs.exe" -q -Q rlog -h -l 
CVSROOT=:ssh:anonym...@cvs.openssl.org:/openssl-cvs

Error, CVS operation failed (exit code -1)


Can anyone suggest what I might be doing wrong in my configuration?

Thanks,

Paul

_ 
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com  
Preserving the World's Most Important Data. Yours.(tm) 


--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.

openssl-SNAP-20110412.tar.gz corrupted?

[Paul Suhler]

Is anyone else having trouble opening openssl-SNAP-20110411.tar.gz
  and
openssl-SNAP-20110412.tar.gz
 ?  I can
extract the .tar file, but then 7Zip says that it can't be opened as an
archive.

Thanks,

Paul

_ 
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com  
Preserving the World's Most Important Data. Yours.(tm) 


--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.

FW: TLS 1.1 / 1.0 Interoperation

[Paul Suhler]

I'm forwarding this to the users list so that others won't be confused
by the documentation as I was.

Paul

-Original Message-
From: owner-openssl-...@openssl.org
[mailto:owner-openssl-...@openssl.org] On Behalf Of Paul Suhler
Sent: Wednesday, October 13, 2010 11:10 AM
To: openssl-...@openssl.org
Subject: RE: TLS 1.1 / 1.0 Interoperation

Hi, Mounir.

Thanks for your help; we can now negotiate between 1.0 and 1.1.  My only
comment is that -- based on our testing -- only SSLv23_{server,
client}_method allows negotiation.  TLSv1_*_method will *not* accept TLS
1.1 connections.  And SSL3_*_method will not accept TLS connections.

This is actually documented in
http://www.openssl.org/docs/ssl/SSL_CTX_new.html, although it doesn't
(yet) mention TLS 1.1.  For the benefit of whoever works on that
documentation I'd recommend that it be changed to specify 1.0:

TLSv1_method(void), TLSv1_server_method(void), TLSv1_client_method(void)

A TLS/SSL connection established with these methods will only understand
the TLSv1.0 protocol. A client will send out TLSv1.0 client hello
messages and will indicate that it only understands TLSv1.0. A server
will only understand TLSv1.0 client hello messages. This especially
means, that it will not understand SSLv2 client hello messages which are
widely used for compatibility reasons, see SSLv23_*_method(). It will
also not understand SSLv3 client hello messages.

And if you really want consistency, change TLSv1_method to
TLSv1_0_method, etc.

Unless the intention is really that TLSv1_method will accept 1.1, but
that's a lot more work.

Cheers,

Paul

_
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com Preserving the World's Most
Important Data. Yours.(tm)

-Original Message-
From: owner-openssl-...@openssl.org
[mailto:owner-openssl-...@openssl.org] On Behalf Of Mounir IDRASSI
Sent: Sunday, October 10, 2010 3:58 PM
To: openssl-...@openssl.org
Subject: Re: TLS 1.1 / 1.0 Interoperation


  Hi Paul,

The use of an XXX_server_method function in a server defines the minimal
client version it supports.
 SSLv23_server_method   => SSLv2
 SSLv3_server_method => SSLv3
 TLSv1_server_method => TLS 1.0
 TLSv1_1_server_method => TLS 1.1.
Thus, the error you are getting is normal: you told OpenSSL to support
only TLS 1.1 and that's why TLS 1.0 clients are rejected.
Use TLSv1_server_method if you want to support both TLS 1.0 and TLS 1.1
clients.
By the way, setting SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3 is useless since
the server only supports TLS 1.0/1.1.

Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr

On 10/10/2010 6:28 AM, Paul Suhler wrote:
> Hi, Mounir.
>
> In the server, I use TLSv1_1_server_method, resulting in s->version ==
> 0x0302 (TLS 1.1).  In the client, I use TLSv1_client_method to get TLS

> 1.0.  When the server sees s->client_version == 0x0301, shouldn't it 
> change s->version to 0x0301 and operate thereafter in 1.0 mode?
>
> Thanks for the warning about the double free.
>
> Cheers,
>
> Paul
> __
> __
> _
> Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
> 949.856.7748 | paul.suh...@quantum.com Preserving the World's Most 
> Important Data. Yours.(tm)
>
> -Original Message-
> From: owner-openssl-...@openssl.org
> [mailto:owner-openssl-...@openssl.org] On Behalf Of Mounir IDRASSI
> Sent: Saturday, October 09, 2010 6:37 PM
> To: openssl-...@openssl.org
> Subject: Re: TLS 1.1 / 1.0 Interoperation
>
>
>Hi Paul,
>
> I was not able to reproduce your problem using that snapshot. I set up

> an SSL server using SSLv23_server_method and set the options 
> SSL_OP_ALL
> | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 as you did : I always have
> s->version equal to 0x0301 as expected and the test you mentioned is 
> s->OK
> since s->client_version is also equal to 0x0301.
> Same test can be done using the command line :
> openssl s_server -accept 443 -key server.pem -cert server.pem -no_ssl2
> -no_ssl3 -bugs
>
> Can you post a sample code that exposes the problem?
>
> By the way, I detected a double free in the implementation of 
> ssl3_send_server_key_exchange in this snapshot. I'll see if it has 
> been already corrected, otherwise I'll send a patch for it.
>
> Cheers,
> --
> Mounir IDRASSI
> IDRIX
> http://www.idrix.fr
>
> On 08/10/2010 18:55, Paul Suhler wrote:
>> Hi, everyone.
>>
>> [I'm re-sending this to the developers list.]
>>
>> I've found that when a server built with
>> openssl-1.0.1-s

TLS 1.1 / 1.0 Interoperation

[Paul Suhler]

Hi, everyone.

I've found that when a server built with
openssl-1.0.1-stable-SNAP-20101004 receives a Client Hello from a client
specifying TLS 1.0 (version = 0x0301), the connection is rejected for a
bad version.  This appears to be implemented in ssl3_get_client_hello()
by:

if ((s->version == DTLS1_VERSION && s->client_version >
s->version) ||
(s->version != DTLS1_VERSION && s->client_version <
s->version))
{
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,
SSL_R_WRONG_VERSION_NUMBER);

In the SSL_CTX, I'm setting options SSL_OP_ALL | SSL_OP_NO_SSLv2 |
SSL_OP_NO_SSLv3.  I see no options that would be forcing TLS 1.1 only.

However, RFC 4346 Appendix E says:

   Similarly, a TLS 1.1  server that wishes to interoperate with TLS 1.0
   or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages and
   respond with a SSL 3.0 server hello if an SSL 3.0 client hello with a
   version field of {3, 0} is received, denoting that this client does
   not support TLS.  Similarly, if a SSL 3.0 or TLS 1.0 hello with a
   version field of {3, 1} is received, the server SHOULD respond with a
   TLS 1.0 hello with a version field of {3, 1}.

Am I misunderstanding the requirements of the RFC, or is this part of
the fix for the renegotiation exploit?  (I'm not renegotiating when this
happens; it's the initial connection attempt that's rejected.)

Thanks very much,

Paul

_
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com  
Preserving the World's Most Important Data. Yours.(tm)

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.

RE: Google Chrome certificate idiosyncrasies?

[Paul Suhler]

I haven't seen that, but I have seen Chrome (on MacOS 10.5.8) complain
about the validity of certificates that don't bother Firefox.
 
Paul

___
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com 


___
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individuals or organizations, without restriction.



From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Lou Picciano
Sent: Friday, March 19, 2010 8:17 AM
To: openssl-users@openssl.org
Subject: Google Chrome certificate idiosyncrasies?


Fellow OpenSSL-ers, 


We're beginning to look at an apparent discrepancy in the way Google
Chrome (OS X) handles certificates.  

Though Chrome seems to use the same OS X-standard keychain application
used by Safari, we are finding that Chrome reports the dreaded
'Handshake Re-negotiation' error in attempting to connect to certain
locked-down websites, while Safari connects just fine.

Hmm...  More digging on this to follow.  Meanwhile, anyone else run into
this?

Lou

Re: Verify with RSA Public Key Fails

[Paul Suhler]

Does anyone else have any speculation on why I'm failing the padding
check?  I'm definitely using the public exponent and public modulus from
the CAVP sample request file.  After conversion to BIGNUMs, the bytes in
the d, top, and dmax fields of each BIGNUM seem to be correct.
 
I don't see anything else in the EVP_Verify*() APIs that are needed to
specify the algorithm to be used -- just set specify the hash algorithm
and provide the RSA key (inside an EVP_PKEY).
 
Thanks,
 
Paul 


From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Paul Suhler
Sent: Saturday, February 27, 2010 6:17 AM
To: openssl-users@openssl.org; openssl-users@openssl.org
Subject: RE: Verify with RSA Public Key Fails



Hi, Mounir.

I misspoke.  The value of the public exponent is in fact 3.

Any idea what is the purpose of the padding check or why it should fail?

Thanks,

Paul

-Original Message-
From: owner-openssl-us...@openssl.org on behalf of Mounir IDRASSI
Sent: Sat 2/27/2010 4:15 AM
To: openssl-users@openssl.org
Subject: Re: Verify with RSA Public Key Fails

Hi Paul,

You say that the exponent is 1024 bit long. This means you are using the
private exponent because usually the public exponent is much smaller:
typically the public exponent is 3 or 65537.
So in order to construct your RSA public key, replace the value of the
private exponent you are using by the value of the corresponding public
exponent.
If my guess is correct, then you should be able to verify the signature
correctly.

Cheers,

--
Mounir IDRASSI
IDRIX
http://www.idrix.fr


On 2/27/2010 3:00 AM, Paul Suhler wrote:
>
> Hi, everyone.
>
> In Openssl 0.9.8i, I'm trying to take an RSA public exponent and
> public modulus, assemble them into an RSA key, and use that to verify
> a signature for a message.  However, EVP_VerifyFinal() always fails,
> apparently because of the wrong use of padding.
>
> My code:
>
>RSA *   RsaKeyPtr = RSA_new();
>EVP_PKEY *  EvpKeyPtr = EVP_PKEY_new();
>
>RsaKeyPtr->n = BN_bin2bn(ModulusPtr, ModulusLength, NULL); //
> Public modulus n
>RsaKeyPtr->e = BN_bin2bn(Exponent, sizeof(Exponent), NULL); //
> Public key exponent e
>EvpKeyPtr->type = EVP_PKEY_RSA;
>if(EVP_PKEY_assign_RSA(EvpKeyPtr, RsaKeyPtr))
>{
>   EVP_MD_CTX_init(&MDContext);
>   if(EVP_VerifyInit_ex(&MDContext, EvpMdPtr, NULL))
>   {
>  if(EVP_VerifyUpdate(&MDContext, MessagePtr, MessageLength))
>  {
> if(EVP_VerifyFinal(&MDContext, SignaturePtr,
> SignatureLength, EvpKeyPtr))
> {
> ...
>
> The call stack looks like:
>
> RSA_public_decrypt((int)siglen,sigbuf,s,rsa,RSA_PKCS1_PADDING);
> ...
> RSA_eay_public_decrypt()
> RSA_padding_check_PKCS1_type_1()
>
> and that last function fails.
>
> Am I assembling the RSA key incorrectly?
>
> The modulus and exponent are each 1024 bits long and the message and
> signature are each 128 bytes long
>
> Thanks very much,
>
> Paul
> *___
> Paul A. Suhler* | Firmware Engineer |* Quantum Corporation* |*
> Office:* 949.856.7748 | _paul.suh...@quantum.com_
> <mailto:paul.suh...@quantum.com>
>
>

> The information contained in this transmission may be confidential.
> Any disclosure, copying, or further distribution of confidential
> information is not permitted unless such privilege is explicitly
> granted in writing by Quantum. Quantum reserves the right to have
> electronic communications, including email and attachments, sent
> across its networks filtered through anti virus and spam software
> programs and retain such messages in order to comply with applicable
> data security and retention requirements. Quantum is not responsible
> for the proper and complete transmission of the substance of this
> communication or for any delay in its receipt.

--
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Verify with RSA Public Key Fails

[Paul Suhler]

Hi, Mounir.

I misspoke.  The value of the public exponent is in fact 3.

Any idea what is the purpose of the padding check or why it should fail?

Thanks,

Paul

-Original Message-
From: owner-openssl-us...@openssl.org on behalf of Mounir IDRASSI
Sent: Sat 2/27/2010 4:15 AM
To: openssl-users@openssl.org
Subject: Re: Verify with RSA Public Key Fails
 
Hi Paul,

You say that the exponent is 1024 bit long. This means you are using the 
private exponent because usually the public exponent is much smaller: 
typically the public exponent is 3 or 65537.
So in order to construct your RSA public key, replace the value of the 
private exponent you are using by the value of the corresponding public 
exponent.
If my guess is correct, then you should be able to verify the signature 
correctly.

Cheers,

-- 
Mounir IDRASSI
IDRIX
http://www.idrix.fr


On 2/27/2010 3:00 AM, Paul Suhler wrote:
>
> Hi, everyone.
>
> In Openssl 0.9.8i, I'm trying to take an RSA public exponent and 
> public modulus, assemble them into an RSA key, and use that to verify 
> a signature for a message.  However, EVP_VerifyFinal() always fails, 
> apparently because of the wrong use of padding.
>
> My code:
>
>RSA *   RsaKeyPtr = RSA_new();
>EVP_PKEY *  EvpKeyPtr = EVP_PKEY_new();
>
>RsaKeyPtr->n = BN_bin2bn(ModulusPtr, ModulusLength, NULL); // 
> Public modulus n
>RsaKeyPtr->e = BN_bin2bn(Exponent, sizeof(Exponent), NULL); // 
> Public key exponent e
>EvpKeyPtr->type = EVP_PKEY_RSA;
>if(EVP_PKEY_assign_RSA(EvpKeyPtr, RsaKeyPtr))
>{
>   EVP_MD_CTX_init(&MDContext);
>   if(EVP_VerifyInit_ex(&MDContext, EvpMdPtr, NULL))
>   {
>  if(EVP_VerifyUpdate(&MDContext, MessagePtr, MessageLength))
>  {
> if(EVP_VerifyFinal(&MDContext, SignaturePtr, 
> SignatureLength, EvpKeyPtr))
> {
> ...
>
> The call stack looks like:
>
> RSA_public_decrypt((int)siglen,sigbuf,s,rsa,RSA_PKCS1_PADDING);
> ...
> RSA_eay_public_decrypt()
> RSA_padding_check_PKCS1_type_1()
>
> and that last function fails.
>
> Am I assembling the RSA key incorrectly?
>
> The modulus and exponent are each 1024 bits long and the message and 
> signature are each 128 bytes long
>
> Thanks very much,
>
> Paul
> *___
> Paul A. Suhler* | Firmware Engineer |* Quantum Corporation* |* 
> Office:* 949.856.7748 | _paul.suh...@quantum.com_ 
> <mailto:paul.suh...@quantum.com>
>
> 
> The information contained in this transmission may be confidential. 
> Any disclosure, copying, or further distribution of confidential 
> information is not permitted unless such privilege is explicitly 
> granted in writing by Quantum. Quantum reserves the right to have 
> electronic communications, including email and attachments, sent 
> across its networks filtered through anti virus and spam software 
> programs and retain such messages in order to comply with applicable 
> data security and retention requirements. Quantum is not responsible 
> for the proper and complete transmission of the substance of this 
> communication or for any delay in its receipt.

-- 
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Verify with RSA Public Key Fails

[Paul Suhler]

Hi, everyone.

In Openssl 0.9.8i, I'm trying to take an RSA public exponent and public
modulus, assemble them into an RSA key, and use that to verify a
signature for a message.  However, EVP_VerifyFinal() always fails,
apparently because of the wrong use of padding.

My code:

   RSA *   RsaKeyPtr = RSA_new();
   EVP_PKEY *  EvpKeyPtr = EVP_PKEY_new();

   RsaKeyPtr->n = BN_bin2bn(ModulusPtr, ModulusLength, NULL); // Public
modulus n
   RsaKeyPtr->e = BN_bin2bn(Exponent, sizeof(Exponent), NULL); // Public
key exponent e
   EvpKeyPtr->type = EVP_PKEY_RSA;
   if(EVP_PKEY_assign_RSA(EvpKeyPtr, RsaKeyPtr))
   {
  EVP_MD_CTX_init(&MDContext);
  if(EVP_VerifyInit_ex(&MDContext, EvpMdPtr, NULL))
  {
 if(EVP_VerifyUpdate(&MDContext, MessagePtr, MessageLength))
 {
if(EVP_VerifyFinal(&MDContext, SignaturePtr,
SignatureLength, EvpKeyPtr))
{
...

The call stack looks like:

RSA_public_decrypt((int)siglen,sigbuf,s,rsa,RSA_PKCS1_PADDING);
...
RSA_eay_public_decrypt()
RSA_padding_check_PKCS1_type_1()

and that last function fails.

Am I assembling the RSA key incorrectly?

The modulus and exponent are each 1024 bits long and the message and
signature are each 128 bytes long

Thanks very much,

Paul
___
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com 

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.

Enabling Session Caching

[Paul Suhler]

Hi, everyone.

I'm trying to enable session caching, but my server doesn't seem to send
a session ID.

According to
http://www.openssl.org/docs/ssl/SSL_CTX_set_session_id_context.html, all
I have to do is invoke SSL_CTX_set_session_id_context() with a pointer
to a string (or binary data) and the length of that string.  I've done
this and the desired session ID and length are correct in both the
SSL_CTX structure and (during SSL_accept) in the SSL structure.
However, in the Server Hello message, the session ID length is always
zero.  The client that connects shows a zero-length session ID, which
would seem to be consistent with not sendig an ID.  I'm using anonymous
TLS, so there are no certificates in the server context.

The code that I'm using to set up the context is:

   netSSLServerContextPtr = SSL_CTX_new(TLSv1_server_method());
   SSL_CTX_set_options(netSSLServerContextPtr, SSL_OP_ALL |
SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
   SSL_CTX_set_session_cache_mode(netSSLServerContextPtr,
SSL_SESS_CACHE_BOTH);
   SSL_CTX_set_session_id_context(netSSLServerContextPtr,
netSslSessionIdContext, sizeof(netSslSessionIdContext));
   SSL_CTX_set_mode(netSSLServerContextPtr, SSL_MODE_AUTO_RETRY);

I've tried this with netSslSessionIdContext indicating both 17- and
ten-byte-long strings; neither work, so it seems not to be a string
length mismatch issue.

What have I missed?

Thanks very much,

Paul
___
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com 
___
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individuals or organizations, without restriction.

RE: BIO definitions missing in 0.9.8k

[Paul Suhler]

Hmm.  I just pulled 0.9.8k down again, and they're in the tree.  asn_mime.c 
also contains some of the stream symbols.

Are the streaming ASN.1 interface files included but not supposed to be built?

Thanks,

Paul

-Original Message-
From: owner-openssl-us...@openssl.org on behalf of Dr. Stephen Henson
Sent: Sat 8/8/2009 3:46 AM
To: openssl-users@openssl.org
Subject: Re: BIO definitions missing in 0.9.8k
 
On Fri, Aug 07, 2009, Paul Suhler wrote:

> Hi, all.
> 
> I'm trying to upgrade from 0.9.8i to 0.9.8k for an embedded application.
> There are two new files in crypto/bio that are having undefined symbols,
> and I can't find the symbols defined anywhere in the code:
> 
> bio_asn1.c:
> BIOC_C_SET_EX_ARG
> BIO_C_SET_PREFIX
> BIO_C_GET_PREFIX
> BIO_C_GET_SUFFIX
> asn1_ps_func
> and others
> 
> bio_ndef.c:
> ASN1_STREAM_ARG
> ASN1_F_BIO_NEW_NDEF
> 
> I'm apparently skipping some (new?) step in the build process.  Can
> anyone tell me how these symbols are created?
> 

I'm not sure what you are doing but those symbols are not in th 0.9.8 source
tree at all, they are part of the streaming ASN1 interface which is only in
1.0.0.

Steve.

--
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum 
Corporation. Furthermore, Quantum Corporation is not responsible for the proper 
and complete transmission of the substance of this communication or for any 
delay in its receipt.

BIO definitions missing in 0.9.8k

[Paul Suhler]

Hi, all.

I'm trying to upgrade from 0.9.8i to 0.9.8k for an embedded application.
There are two new files in crypto/bio that are having undefined symbols,
and I can't find the symbols defined anywhere in the code:

bio_asn1.c:
BIOC_C_SET_EX_ARG
BIO_C_SET_PREFIX
BIO_C_GET_PREFIX
BIO_C_GET_SUFFIX
asn1_ps_func
and others

bio_ndef.c:
ASN1_STREAM_ARG
ASN1_F_BIO_NEW_NDEF

I'm apparently skipping some (new?) step in the build process.  Can
anyone tell me how these symbols are created?

Thanks very much,

Paul
___
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com 
___
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individuals or organizations, without restriction.

RE: Memory Leak Creating a CSR

[Paul Suhler]

That did it!

The example uses X509_REQ_get_subject_name(CSR).  X509_REQs now contain
a pointer to a valid X509_NAME, so it's not necessary to allocate one.
I was leaking the original one when I replaced it with the new one.

Thanks very much, Steve.

Paul
___
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com 
___
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individuals or organizations, without restriction.

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Saturday, May 30, 2009 4:56 PM
To: openssl-users@openssl.org
Subject: Re: Memory Leak Creating a CSR

On Sat, May 30, 2009, Paul Suhler wrote:

> Hi.
> 
> Using OpenSSL 0.9.8i, I'm getting a memory leak when I create a CSR. 
> My process is taken more-or-less from the Viega, et al. book:
> 

No idea what that version is but the one in demos/x509/mkreq.c doesn't
leak memory.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Memory Leak Creating a CSR

[Paul Suhler]

Hi.

Using OpenSSL 0.9.8i, I'm getting a memory leak when I create a CSR. My
process is taken more-or-less from the Viega, et al. book:

Initial: 
X509_REQ_new() to get the request structure 
OPENSSL_malloc(1) to add a byte to the request for the version 

RSA Key: 
RSA_new() for an RSA structure 
BN_bin2bn() a number of times to add the public and private keys and
intermediate values 
EVP_PKEY_new() for an EVP structure 
EVP_PKEY_assign_RSA() 
X509_REQ_set_pubkey() to attach the key to the request 

subjectName: 
X509_NAME_new() 
X509_NAME_add_entry_by_NID() six times to add the components of the name

X509_REQ_set_subject_name() to attach the name to the request 

CSR Creation: 
X509_REQ_sign() to sign the request 
BIO_new(BIO_s_mem()) to create a memory BIO to receive the DER-encoded
CSR 
i2d_X509_REQ_bio() to write the DER 
BIO_get_mem_data() to get the location of the data 
memcpy() to copy the DER from the BIO to the destination buffer 

Cleanup: 
BIO_free() 
EVP_PKEY_free() 
X509_REQ_free() 

However, each time I do this, the allocated memory increases by about
800 to 1000 bytes. If I do it enough, CRYPTO_malloc() eventually fails.
If I don't include the subjectName, then there is no leak.  The
inference is that X509_REQ_free() is not freeing all the memory
allocated by the subjectName creation step.

Is there additional structure free-ing that I should be doing? 

Thanks very much, 

Paul
___
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com 
___
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individuals or organizations, without restriction.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: FIPS and new releases of openssl

[Paul Suhler]

That's how FIPS 140 certification works.  If *any* change is made to the thing 
that was certified, then it must reviewed and re-certified.  If the change is 
small, then the review process can be short.  The certifying lab has to ensure 
that the change didn't intentionally or unintentionally compromise the security 
of the rest of the module.  My take on it is that the lab cannot trust the 
vendor (the OpenSSL community in this case) not to be trying to compromise the 
module.

Paul
___
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: 949.856.7748 
| [EMAIL PROTECTED]
___
Disregard the Quantum Corporation confidentiality notice below.  The 
information contained in this transmission is not confidential.  Permission is 
hereby explicitly granted to disclose, copy, and further distribute to any 
individuals or organizations, without restriction.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger No-Spam
Sent: Tuesday, November 04, 2008 8:34 AM
To: openssl-users@openssl.org
Subject: FIPS and new releases of openssl


Hello,

In appendix B of the openssl FIPS security policy it is stated that the module 
must be built with a particular tar file (openssl-fips-1.1.2.tar.gz) and a hmac 
hash value for the tar file is specified. Furthermore it is stated that there 
shall be no additions, deletions, or alterations of the set of files in the tar 
file as used during module build.

The way I read this is that if you modify for instance the ASN.1 or SSL code 
(in order to fix a bug), then the FIPS validation is canceled. This does not 
make sense to me. Why can't higher level code be bug fixed without FIPS 
validation being canceled?

/Roger
_
Var sommaren för kort? Här hittar du solen!
http://resor.se.msn.com/__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

---
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]