Sergio NNX | 1 Sep 10:15 2011
Picon

RE: [openssl.org #2590] change commonName entry for default openssl config file

I reckon the commonName entry has different values depending on the certificateType. E.g., email address if an end user certificate, etc)


----
Parliamentary ICT
Houses of Parliament

UK
http://www.parliament.uk/


Subject: [openssl.org #2590] change commonName entry for default openssl config file
From: rt <at> openssl.org
CC: openssl-dev <at> openssl.org
Date: Wed, 31 Aug 2011 09:03:18 +0200

Hi,

This is just a minor thing that always bugs me whenever I install openssl;
by default the openssl configuration file (/etc/ssl/openssl.cnf) has the
following line:

"commonName = Common Name (eg, YOUR name)"

Sometimes when I'm installing a certificate I accidentally forget to write
my host name given this prompt (as I just did a few minutes ago). I'd
suggest

"commonName = Common Name (your host name)"

since the X.509 format of course requires the CN to be the host. I suspect
this default configuration file is being copied from apps/openssl.cnf,
though I confess this is just based on a diff without looking too closely.
This is of course very minor, but an easy change so I hope you'll consider
it to save lots of future idiots like me 30 seconds.

(I am running Ubuntu 10.04 (old!) at the moment, and peeked at the source
code from the openssl-fips-1.2.3.tar.gz tarball.)

Thanks,
Dan


Hi,

This is just a minor thing that always bugs me whenever I install openssl; by default the openssl configuration file (/etc/ssl/openssl.cnf) has the following line:

"commonName??? ??? ??? = Common Name (eg, YOUR name)"

Sometimes when I'm installing a certificate I accidentally forget to write my host name given this prompt (as I just did a few minutes ago). I'd suggest

"commonName??? ??? ??? = Common Name (your host name)"

since the X.509 format of course requires the CN to be the host. I suspect this default configuration file is being copied from apps/openssl.cnf, though I confess this is just based on a diff without looking too closely. This is of course very minor, but an easy change so I hope you'll consider it to save lots of future idiots like me 30 seconds.

(I am running Ubuntu 10.04 (old!) at the moment, and peeked at the source code from the openssl-fips-1.2.3.tar.gz tarball.)

Thanks,
Dan
Picon

Re: [openssl.org #2395] Resolved: openssl-1.0.0c bug: Decoding cert causes segv in ASN1 code

"Stephen Henson via RT" <rt <at> openssl.org> said:
> According to our records, your request has been resolved. If you have any
> further questions or concerns, please respond to this message.

For a programmer type like myself, such a laconic response is a definite nonplusser.

Given that I did go to effort to make a good bug report, you owe me more detail than this. What
was the issue?

Cheers,
--Sampo

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Coda Highland | 2 Sep 00:29 2011
Picon

Re: [openssl.org #2395] Resolved: openssl-1.0.0c bug: Decoding cert causes segv in ASN1 code

> For a programmer type like myself, such a laconic response is a definite nonplusser.
>
> Given that I did go to effort to make a good bug report, you owe me more detail than this. What
> was the issue?

For someone getting upgrades for free, arrogant claims that you
deserve anything is pretty presumptuous. If you're a programmer type,
go look at the commit history and find out for yourself.

/s/ Adam
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Nick Lewis via RT | 2 Sep 16:57 2011
Picon

[openssl.org #2592] req -newkey rsa does not use key length specified in cnf file PATCH

When the req -newkey option value is of the form rsa rather than rsa:<keylen> the key length of the new rsa key
should be taken from the config file. However req does not generate an rsa key of the correct length
(despite displaying the message "Generating a <keylen> bit RSA private key" that misleadingly does
include the correct key length).

 A patch against 20110815 that resolves this bug is enclosed below. It forces set_keygen_ctx() to be run
again to set EVP_PKEY_CTX_set_rsa_keygen_bits with the value from the config file. It has been tested
with default_bits=2048. It has also been confirmed that the patch does not introduce any problems with
-newkey ec:<paramfile>

Nick
--------

diff --git a/apps/req.c b/apps/req.c
index 8552658..f512b0e 100755
--- a/apps/req.c
+++ b/apps/req.c
 <at>  <at>  -654,6 +654,7  <at>  <at>  bad:

                                if (newkey <= 0)
                                                {
+                                             genctx=NULL;
                                                if (!NCONF_get_number(req_conf,SECTION,BITS, &newkey))
                                                                newkey=DEFAULT_KEY_LENGTH;
                                                }

________________________________
The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury,
Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of
this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not
endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

When the req -newkey option value is of the form rsa rather than rsa:<keylen> the key length of the new rsa key should be taken from the config file. However req does not generate an rsa key of the correct length (despite displaying the message “Generating a <keylen> bit RSA private key” that misleadingly does include the correct key length).

 

 A patch against 20110815 that resolves this bug is enclosed below. It forces set_keygen_ctx() to be run again to set EVP_PKEY_CTX_set_rsa_keygen_bits with the value from the config file. It has been tested with default_bits=2048. It has also been confirmed that the patch does not introduce any problems with -newkey ec:<paramfile>  

 

Nick

--------

 

diff --git a/apps/req.c b/apps/req.c

index 8552658..f512b0e 100755

--- a/apps/req.c

+++ b/apps/req.c

<at> <at> -654,6 +654,7 <at> <at> bad:

               

                                if (newkey <= 0)

                                                {

+                                             genctx=NULL;

                                                if (!NCONF_get_number(req_conf,SECTION,BITS, &newkey))

                                                                newkey=DEFAULT_KEY_LENGTH;

                                                }

 

 


The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.
Kenneth Robinette | 5 Sep 15:20 2011

openssl-fips-2.0-test-20110905

The latest fips_test_suite.exe displays the following errors on start:

C:\work\openssl-fips-2.0-test-20110905\out32dll>fips_test_suite
        FIPS-mode test application
        FIPS 2.0-dev unvalidated test module xx XXX xxxx

ERROR:2D072069:lib=45,func=114,reason=105:file=.\fips\rand\fips_drbg_selftest.c:
line=445
ERROR:2D072074:lib=45,func=114,reason=116:file=.\fips\rand\fips_drbg_selftest.c:
line=477
ERROR:2D073087:lib=45,func=115,reason=135:file=.\fips\rand\fips_drbg_lib.c:line=
98

On test end, the message "All tests completed with 0 errors". This is on a Windows XP 32 bit machine. 

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Dr. Stephen Henson | 5 Sep 17:47 2011
Picon

Re: openssl-fips-2.0-test-20110905

On Mon, Sep 05, 2011, Kenneth Robinette wrote:

> The latest fips_test_suite.exe displays the following errors on start:
> 
> C:\work\openssl-fips-2.0-test-20110905\out32dll>fips_test_suite
>         FIPS-mode test application
>         FIPS 2.0-dev unvalidated test module xx XXX xxxx
> 
> ERROR:2D072069:lib=45,func=114,reason=105:file=.\fips\rand\fips_drbg_selftest.c:
> line=445
> ERROR:2D072074:lib=45,func=114,reason=116:file=.\fips\rand\fips_drbg_selftest.c:
> line=477
> ERROR:2D073087:lib=45,func=115,reason=135:file=.\fips\rand\fips_drbg_lib.c:line=
> 98
> 
> On test end, the message "All tests completed with 0 errors". This is on a Windows XP 32 bit machine. 
> 

Thanks for the report.

Both problems (second is that it should've been a fatal error) should be fixed
in next snapshot.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

OpenSSL | 6 Sep 15:40 2011
Picon

OpenSSL Security Advisory


OpenSSL Security Advisory [6 September 2011]

Two security flaws have been fixed in OpenSSL 1.0.0e

CRL verification vulnerability in OpenSSL
=========================================

Under certain circumstances OpenSSL's internal certificate verification
routines can incorrectly accept a CRL whose nextUpdate field is in the past.
(CVE-2011-3207)

This issue applies to OpenSSL versions 1.0.0 through 1.0.0d. Versions of
OpenSSL before 1.0.0 are not affected.

Users of affected versions of OpenSSL should update to the OpenSSL 1.0.0e
release, which contains a patch to correct this issue.

Thanks to Kaspar Brand <ossl <at> velox.ch> for identifying this bug and 
suggesting a fix.

TLS ephemeral ECDH crashes in OpenSSL
=====================================

OpenSSL server code for ephemeral ECDH ciphersuites is not thread-safe, and
furthermore can crash if a client violates the protocol by sending handshake
messages in incorrect order. (CVE-2011-3210)

This issue applies to OpenSSL 0.9.8 through 0.9.8s (experimental "ECCdraft"
ciphersuites) and to OpenSSL 1.0.0 through 1.0.0d.

Affected users of OpenSSL should update to the OpenSSL 1.0.0e release, which
contains a patch to correct this issue. If you cannot immediately upgrade,
we recommend that you disable ephemeral ECDH ciphersuites if you have enabled
them.

Thanks to Adam Langley <agl <at> chromium.org> for identifying and fixing this
issue.

Which applications are affected
===============================

Applications are only affected by the CRL checking vulnerability if they enable
OpenSSL's internal CRL checking which is off by default. For example by setting
the verification flag X509_V_FLAG_CRL_CHECK or X509_V_FLAG_CRL_CHECK_ALL.
Applications which use their own custom CRL checking (such as Apache) are not
affected.

Only server-side applications that specifically support ephemeral ECDH
ciphersuites are affected by the ephemeral ECDH crash bug and only if
ephemeral ECDH ciphersuites are enabled in the configuration. You can check
to see if application supports ephemeral ECDH ciphersuites by looking for
SSL_CTX_set_tmp_ecdh, SSL_set_tmp_ecdh, SSL_CTRL_SET_TMP_ECDH,
SSL_CTX_set_tmp_ecdh_callback, SSL_set_tmp_ecdh_callback,
SSL_CTRL_SET_TMP_ECDH_CB in the source code.

References
==========

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20110906.txt

OpenSSL | 6 Sep 15:41 2011
Picon

OpenSSL version 1.0.0e released


   OpenSSL version 1.0.0e released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.0e of our open source toolkit for SSL/TLS. This new
   OpenSSL version is a security and bugfix release. For a complete
   list of changes, please see

       http://www.openssl.org/source/exp/CHANGES.

   The most significant changes are:

      o Fix for CRL vulnerability issue CVE-2011-3207
      o Fix for ECDH crashes CVE-2011-3210
      o Protection against EC timing attacks.
      o Support ECDH ciphersuites for certificates using SHA2 algorithms.
      o Various DTLS fixes.

   We consider OpenSSL 1.0.0e to be the best version of OpenSSL
   available and we strongly recommend that users of older versions
   upgrade as soon as possible. OpenSSL 1.0.0e is available for
   download via HTTP and FTP from the following master locations (you
   can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

     * http://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.0.0e.tar.gz
      Size: 4040229
      MD5 checksum: 7040b89c4c58c7a1016c0dfa6e821c86
      SHA1 checksum: 235eb68e5a31b0f7a23bc05f52d7a39c596e2e69

   The checksums were calculated using the following commands:

    openssl md5 openssl-1.0.0e.tar.gz
    openssl sha1 openssl-1.0.0e.tar.gz

   Yours,

   The OpenSSL Project Team...

    Mark J. Cox             Nils Larsch         Ulf Möller
    Ralf S. Engelschall     Ben Laurie          Andy Polyakov
    Dr. Stephen Henson      Richard Levitte     Geoff Thorpe
    Lutz Jänicke            Bodo Möller

huieying.lee | 6 Sep 15:45 2011
Picon

Auto Reply: OpenSSL Security Advisory

I will be on vacation from Sep/05/2011 thru Sep/16/2011  (back in the office on Sep 19).
Have a great day !

Huie-Ying
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

The Doctor | 6 Sep 16:34 2011
Picon

Re: OpenSSL Security Advisory

On Tue, Sep 06, 2011 at 03:40:30PM +0200, OpenSSL wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> OpenSSL Security Advisory [6 September 2011]
> 
> Two security flaws have been fixed in OpenSSL 1.0.0e
> 
> CRL verification vulnerability in OpenSSL
> =========================================
> 
> Under certain circumstances OpenSSL's internal certificate verification
> routines can incorrectly accept a CRL whose nextUpdate field is in the past.
> (CVE-2011-3207)
> 
> This issue applies to OpenSSL versions 1.0.0 through 1.0.0d. Versions of
> OpenSSL before 1.0.0 are not affected.
> 
> Users of affected versions of OpenSSL should update to the OpenSSL 1.0.0e
> release, which contains a patch to correct this issue.
> 
> Thanks to Kaspar Brand <ossl@...> for identifying this bug and 
> suggesting a fix.
> 
> 
> TLS ephemeral ECDH crashes in OpenSSL
> =====================================
> 
> OpenSSL server code for ephemeral ECDH ciphersuites is not thread-safe, and
> furthermore can crash if a client violates the protocol by sending handshake
> messages in incorrect order. (CVE-2011-3210)
> 
> This issue applies to OpenSSL 0.9.8 through 0.9.8s (experimental "ECCdraft"
> ciphersuites) and to OpenSSL 1.0.0 through 1.0.0d.
> 
> Affected users of OpenSSL should update to the OpenSSL 1.0.0e release, which
> contains a patch to correct this issue. If you cannot immediately upgrade,
> we recommend that you disable ephemeral ECDH ciphersuites if you have enabled
> them.
> 
> Thanks to Adam Langley <agl@...> for identifying and fixing this
> issue.
> 
> Which applications are affected
> ===============================
> 
> Applications are only affected by the CRL checking vulnerability if they enable
> OpenSSL's internal CRL checking which is off by default. For example by setting
> the verification flag X509_V_FLAG_CRL_CHECK or X509_V_FLAG_CRL_CHECK_ALL.
> Applications which use their own custom CRL checking (such as Apache) are not
> affected.
> 
> Only server-side applications that specifically support ephemeral ECDH
> ciphersuites are affected by the ephemeral ECDH crash bug and only if
> ephemeral ECDH ciphersuites are enabled in the configuration. You can check
> to see if application supports ephemeral ECDH ciphersuites by looking for
> SSL_CTX_set_tmp_ecdh, SSL_set_tmp_ecdh, SSL_CTRL_SET_TMP_ECDH,
> SSL_CTX_set_tmp_ecdh_callback, SSL_set_tmp_ecdh_callback,
> SSL_CTRL_SET_TMP_ECDH_CB in the source code.
> 
> References
> ==========
> 
> URL for this Security Advisory:
> http://www.openssl.org/news/secadv_20110906.txt
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEVAwUBTmYhWqLSm3vylcdZAQKsnQgAsD+GwbfpXuZyhLNcHrJjTiHgfVWQLiFq
> 6RupYmgfxPiCrGdSEvp6Uh3Y+bcOOoDXTXujk7T6RTRU4iYiARFkXo8bUtH47dWO
> AfwOyMxiM88G9TYj69RUjKNP70j1rEATIz+m4kpnDgmmsodDNsPj56k4gptsoELc
> S4Cb4+97uCBv1mkVFgvu71RVXbIwqOMt/vveHUttQQLEcdu2XcUylbMarDaOcZui
> e9AjYX3LoqdhPRl2v01tuJf3c8wmNTE+GtsO8hwda6eo8Mu/BAnqtFsiFRVjmJ2M
> vgj1Ot/SPQHcpDu7N3V3GY4tdY8iDHWZ5FfbyaoXvzM6guS+o4cDww==
> =xfeL
> -----END PGP SIGNATURE-----
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@...
> Automated List Manager                           majordomo@...

Will this affect openssl 1.0.1 ?

--

-- 
Member - Liberal International	This is doctor@... Ici doctor@...
God, Queen and country! Never Satan President Republic! Beware AntiChrist rising! 
https://www.fullyfollow.me/rootnl2k
IT is done!  http://groups.google.com/group/rec.arts.drwho/about
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...


Gmane