Re: [openssl-dev] [openssl-users] Is there openssl API to verify certificate content is DER or PEM format ?

2015-06-11 Thread Dave Thompson
 From: openssl-dev On Behalf Of Nayna Jain
 Sent: Wednesday, June 10, 2015 20:31

 If I have a pem file with private key in that, how do I check if that is
RSA/DSA ?

If it uses a legacy format, the BEGIN line specifies the algorithm
-BEGIN RSA PRIVATE KEY-
-BEGIN DSA PRIVATE KEY-
-BEGIN EC PRIVATE KEY-

If it uses either PKCS#8 format: if unencrypted there is an
AlgorithmIdentifier 
field near the beginning that specifies the type of the key; if encrypted,
you 
must first decrypt and the decrypted value contains the AlgorithmIdentifier.

It's usually easier to let PEM_read_PrivateKey figure out for you. It reads
all 
formats (encrypted only if you provide the correct passphrase) and returns 
an EVP_PKEY object whose type you can check with EVP_PKEY_type 
following the instructions on the manpage for EVP_PKEY_type.



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] Self-initialization of locking/threadid callbacks and auto-detection of features

2015-06-11 Thread Florian Weimer
On 10/30/2013 12:15 AM, Nico Williams wrote:
 On Tue, Oct 29, 2013 at 09:58:25PM +0100, Andy Polyakov wrote:
 pthreads and Windows, and one can indeed argue why wouldn't OpenSSL
 simply default to either of the two when appropriate. While it's
 more than appropriate on Windows as it is, on pthreads-powered
 Unices it's not as obvious. Because pthreads can be undesired in
 some situations. Basically it boils down to question whether or not
 libcrypto may be linked with libpthread or not. And answer is
 actually not desired. Ideally libcrypto should *detect* if

Detecting things in libcrypto is very difficult on GNU/Linux due to the
way dynamic linking works.

 More details would be nice.  What follows is speculation of mine as to
 what you might have in mind (or even if you don't, it might be
 relevant).
 
 To summarize the below:
 
 OpenSSL .so's should always be linked with -lpthread on OSes where
 there's a standard libpthread that threaded apps are expected to
 use; OpenSSL static link archives should assume no threading
 libraries and rely on the callers to provide the threading
 callbacks.

On GNU/Linux, you should try very hard to avoid linking -lpthread and
restrict yourself to the pthreads API subset which is available without
-lpthread.  If something is missing, we (as in glibc upstream) can move
additional functionality from libpthread to libc.

Linking -lpthread has a real performance hit for unthreaded
applications, so core libraries should avoid it.

If you have received advice to the contrary, your source of advice is
wrong. :-)

-- 
Florian Weimer / Red Hat Product Security
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

2015-06-11 Thread Jean-Philippe Aumasson
The status of the draft is unchanged (Finding Reviewers). Perhaps OpenSSL
can speed up the review process.

BLAKE2 has a keyed (aka MAC/PRF) mode, so it may also replace Poly1305. A
BLAKE2 MAC can be customized wrt key or tag size, and can provide the
highest security level for a give key/tag size combination.



On Thu, Jun 11, 2015 at 10:15 AM Yoav Nir ynir.i...@gmail.com wrote:


  On Jun 11, 2015, at 2:36 AM, Bill Cox waywardg...@google.com wrote:
 
  BLAKE2 rocks.  I'm looking forward to using it in many applications.
 

 Sure. I would be glad to see that used as a hash in signatures and in TLS,
 as a PRF in TLS and IKE, etc.

 Does anyone know what the status of draft-saarinen-blake2 is?  If that
 progresses we can propose things like
 TLS_ECDHE_EdDSA_WITH_CHACHA20_POLY1305_BLAKE2[*] or PRF_BLAKE2.

 Yoav

 [*] I think we should call that ciphersuite “Suite-C” with ‘C’ standing
 for civilian, because this is a whole bunch of algorithms, none of which
 came from the government of the (pseudo-)military.

 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

2015-06-11 Thread Yoav Nir
That shouldn’t be too difficult (finding reviewers, I mean).

Is the ISE asking for volunteers to review? What kind of volunteers?  IMO what 
a reviewer needs to be able to say is:
 - The document is clear (you can implement based on this)
 - The algorithm might be useful in the IETF
 - The security claims are sufficient to what IETF protocols need
 - The security claims are backed up by either peer-reviewed academic papers or 
equivalent

So there’s a lot of people who can do all that. You don’t even need real 
cryptographers, although having at least one would be good. What is holding 
things up?

Yoav

 On Jun 11, 2015, at 11:50 AM, Jean-Philippe Aumasson 
 jeanphilippe.aumas...@gmail.com wrote:
 
 The status of the draft is unchanged (Finding Reviewers). Perhaps OpenSSL 
 can speed up the review process.
 
 BLAKE2 has a keyed (aka MAC/PRF) mode, so it may also replace Poly1305. A 
 BLAKE2 MAC can be customized wrt key or tag size, and can provide the highest 
 security level for a give key/tag size combination.
 
 
 
 On Thu, Jun 11, 2015 at 10:15 AM Yoav Nir ynir.i...@gmail.com 
 mailto:ynir.i...@gmail.com wrote:
 
  On Jun 11, 2015, at 2:36 AM, Bill Cox waywardg...@google.com 
  mailto:waywardg...@google.com wrote:
 
  BLAKE2 rocks.  I'm looking forward to using it in many applications.
 
 
 Sure. I would be glad to see that used as a hash in signatures and in TLS, as 
 a PRF in TLS and IKE, etc.
 
 Does anyone know what the status of draft-saarinen-blake2 is?  If that 
 progresses we can propose things like 
 TLS_ECDHE_EdDSA_WITH_CHACHA20_POLY1305_BLAKE2[*] or PRF_BLAKE2.
 
 Yoav
 
 [*] I think we should call that ciphersuite “Suite-C” with ‘C’ standing for 
 civilian, because this is a whole bunch of algorithms, none of which came 
 from the government of the (pseudo-)military.
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 
 https://mta.openssl.org/mailman/listinfo/openssl-dev
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] Build failure on SLES11

2015-06-11 Thread Blumenthal, Uri - 0553 - MITLL
Just to let you ‎know that I thoroughly enjoyed your reply. :-)

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.

  Original Message  
From: Andy Polyakov
Sent: Thursday, June 11, 2015 10:14
To: openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Build failure on SLES11

 It could be the gcc version is too old. Trying to recall, gcc needs to
 be something like 4.4 or newer to support the Intel carry-less multiply
 instruction.

It's pure assembler issue, not compiler. You can compile the module with
gcc 3.x if you wish (I actually do) as long as you have new enough 'as'
on your $PATH.

 I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system.
 It fails unless I configure with no-asm. Here is the relevant output:

 ghash-x86_64.s: Assembler messages:
 ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq
 $17,%xmm2,%xmm0,%xmm1'
 ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq
 $0,%xmm2,%xmm0,%xmm0'
 [ ... many identical errors omitted ]


 I believe a check inside ./crypto/modes/asm/ghash-x86_64.pl is
 failing. Here is relevant output that might be of help:

 $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
 GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU
 Binutils; SUSE Linux Enterprise 11) 2.19

It's can as well be wrong. I mean it might have to be adjusted as
$1=2.20 instead of 2.19. While AVX support was added in binutils 2.19,
they might have omitted specifically vpclmulqdq. Can you confirm if it
works if you replace 2.19 with 2.20?

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] OpenSSL version 0.9.8zg released

2015-06-11 Thread OpenSSL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


   OpenSSL version 0.9.8zg 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 0.9.8zg of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

http://www.openssl.org/news/openssl-0.9.8-notes.html

   OpenSSL 0.9.8zg 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-0.9.8zg.tar.gz
  Size: 3826891
  MD5 checksum: 0a912b6623ac95a8627ea2bd0e0abf1b
  SHA1 checksum: a73005583ba8d5edc3bdcc1f99a1e33ee0ed41f8

   The checksums were calculated using the following commands:

openssl md5 openssl-0.9.8zg.tar.gz
openssl sha1 openssl-0.9.8zg.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVeZkpAAoJENnE0m0OYESRzLcIAKhsW3bm1latn1wLoQk0cJEf
GQVf9ztRkxivgodycUYhkuGhq2O+djeYHqKMXnedso+KnkgE/FnhTbDkyX6G12bs
H17ZMgWOIypjHnwGW6jT1GlH+qb9tlzJYAuqsIEbG+hwE5KIsUrwtjAb1MhUuZFC
f11jP5VFf4YXsN681TdyXxlhIdmeImiIDMjsVMGLIZ12zDV6AEJ4LrLkyyaaJxnd
cryKY+Ai4AqBW3Mnv/tVddDvUdgmvjyNHBXEyBUkhy8oIpHe33RMLmGyK6w4P6os
rTKsQzliZ8FSmBfbrOeFUTfPh/N1POqTcWV4VEBjD7mNZbnk3dHQZ3eFLBz8QGs=
=kj2n
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] OpenSSL version 1.0.0s released

2015-06-11 Thread OpenSSL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


   OpenSSL version 1.0.0s 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.0s of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

http://www.openssl.org/news/openssl-1.0.0-notes.html

   OpenSSL 1.0.0s 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.0s.tar.gz
  Size: 4102101
  MD5 checksum: fe54d58a42c6aa1c7a587378e27072f3
  SHA1 checksum: 3df4b9a87c0a37e6fd589360f9d43a6be2252b62

   The checksums were calculated using the following commands:

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

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVeZeTAAoJENnE0m0OYESR/qoIAJRa63Si5UbI8hrJVsTCDAb6
VBfb40NrzOA3x7XpsS1MQxHK9ixPokdhMSHsjAkk4D3tz703I5ig9BDymWr8U2tF
2XvNKm4JBwn8SGfPgI/sy+YgaD0Adzt84eeAek+elPReAdQZGTJ83YFbycs8tSH5
g35JNrEOO8eXADq1WTsM3iqgPt4rXW7RJFQuI4yOtZZA1aqeD+d3WGQTopglt5Az
/+CVViskrnlBihRiOZKfEk4qinB0s7TIJPZifPRzDFdhvMqz6VIndYsPmFhgQMSn
jkhhwHhNB/NXZyNUGBdrxeq2ySX88ObXFlMvUAHFnj0CpaGuHyA2XIEL3vmHdtg=
=8O7B
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] Build failure on SLES11

2015-06-11 Thread Andy Polyakov
 It could be the gcc version is too old.  Trying to recall, gcc needs to
 be something like 4.4 or newer to support the Intel carry-less multiply
 instruction.

It's pure assembler issue, not compiler. You can compile the module with
gcc 3.x if you wish (I actually do) as long as you have new enough 'as'
on your $PATH.

 I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system.
 It fails unless I configure with no-asm. Here is the relevant output:

 ghash-x86_64.s: Assembler messages:
 ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq
 $17,%xmm2,%xmm0,%xmm1'
 ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq
 $0,%xmm2,%xmm0,%xmm0'
 [ ... many identical errors omitted ]


 I believe a check inside ./crypto/modes/asm/ghash-x86_64.pl is
 failing. Here is relevant output that might be of help:

 $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
 GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU
 Binutils; SUSE Linux Enterprise 11) 2.19

It's can as well be wrong. I mean it might have to be adjusted as
$1=2.20 instead of 2.19. While AVX support was added in binutils 2.19,
they might have omitted specifically vpclmulqdq. Can you confirm if it
works if you replace 2.19 with 2.20?

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] [PATCH] logjam vulnerability changes for 0.9.8f version

2015-06-11 Thread Rao, Yarlagadda Srinivasa (MCOU)
Hello All,

This patch fixes/back port the DH parameters changes from 1.0.1 stable branch 
to 0.9.8f version.

---
$ cat /tmp/patch.txt
--- s3_clnt.c_org   2015-06-10 14:27:54.0 +0530
+++ s3_clnt.c   2015-06-11 08:05:46.0 +0530
@@ -2575,22 +2575,31 @@
 }
#endif
#ifndef OPENSSL_NO_DH
-if ((algs  SSL_kEDH) 
-!(has_bits(i, EVP_PK_DH | EVP_PKT_EXCH) || (dh != NULL))) {
-SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM, SSL_R_MISSING_DH_KEY);
+if ((algs  SSL_kEDH)  dh == NULL) {
+SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM, ERR_R_INTERNAL_ERROR);
 goto f_err;
-} else if ((algs  SSL_kDHr)  !has_bits(i, EVP_PK_DH | EVP_PKS_RSA)) {
+}
+if ((algs  SSL_kDHr)  !has_bits(i, EVP_PK_DH | EVP_PKS_RSA)) {
 SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,
SSL_R_MISSING_DH_RSA_CERT);
 goto f_err;
 }
# ifndef OPENSSL_NO_DSA
-else if ((algs  SSL_kDHd)  !has_bits(i, EVP_PK_DH | EVP_PKS_DSA)) {
+if ((algs  SSL_kDHd)  !has_bits(i, EVP_PK_DH | EVP_PKS_DSA)) {
 SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,
SSL_R_MISSING_DH_DSA_CERT);
 goto f_err;
 }
# endif
+/* Check DHE only: static DH not implemented. */
+if (algs  SSL_kEDH) {
+int dh_size = BN_num_bits(dh-p);
+if ((!SSL_C_IS_EXPORT(s-s3-tmp.new_cipher)  dh_size  768)
+|| (SSL_C_IS_EXPORT(s-s3-tmp.new_cipher)  dh_size  512)) {
+SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM, 
SSL_R_DH_KEY_TOO_SMALL);
+goto f_err;
+}
+}
#endif

 if (SSL_C_IS_EXPORT(s-s3-tmp.new_cipher)  !has_bits(i, EVP_PKT_EXP)) {
--- ssl.h_org   2015-06-10 14:24:27.0 +0530
+++ ssl.h   2015-06-11 08:05:28.0 +0530
@@ -2036,6 +2036,7 @@
# define SSL_R_DATA_LENGTH_TOO_LONG   146
# define SSL_R_DECRYPTION_FAILED  147
# define SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC281
+# define SSL_R_DH_KEY_TOO_SMALL   372
# define SSL_R_DH_PUBLIC_VALUE_LENGTH_IS_WRONG148
# define SSL_R_DIGEST_CHECK_FAILED149
# define SSL_R_DTLS_MESSAGE_TOO_BIG   318
--- ssl_err.c_org   2015-06-10 14:21:03.0 +0530
+++ ssl_err.c   2015-06-11 08:05:21.0 +0530
@@ -390,6 +390,7 @@
 {ERR_REASON(SSL_R_DECRYPTION_FAILED), decryption failed},
 {ERR_REASON(SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC),
  decryption failed or bad record mac},
+{ERR_REASON(SSL_R_DH_KEY_TOO_SMALL), dh key too small},
 {ERR_REASON(SSL_R_DH_PUBLIC_VALUE_LENGTH_IS_WRONG),
  dh public value length is wrong},
 {ERR_REASON(SSL_R_DIGEST_CHECK_FAILED), digest check failed},
--- dhparam.c_org   2015-06-10 14:17:53.0 +0530
+++ dhparam.c   2015-06-11 08:04:47.0 +0530
@@ -130,7 +130,7 @@
# undef PROG
# define PROGdhparam_main

-# define DEFBITS 512
+# define DEFBITS 2048

/*-
  * -inform arg  - input format - default PEM (DER or PEM)
@@ -254,7 +254,7 @@
 BIO_printf(bio_err,
 -5generate parameters using  5 as the 
generator value\n);
 BIO_printf(bio_err,
-numbits   number of bits in to generate (default 
512)\n);
+numbits   number of bits in to generate (default 
2048)\n);
# ifndef OPENSSL_NO_ENGINE
 BIO_printf(bio_err,
 -engine e use engine e, possibly a hardware 
device.\n);
--- gendh.c_org 2015-06-10 14:18:31.0 +0530
+++ gendh.c 2015-06-11 08:04:55.0 +0530
@@ -80,7 +80,7 @@
# include openssl/x509.h
# include openssl/pem.h

-# define DEFBITS 512
+# define DEFBITS 2048
# undef PROG
# define PROG gendh_main

--- s_server.c_org  2015-06-10 14:16:40.0 +0530
+++ s_server.c  2015-06-11 08:04:38.0 +0530
@@ -197,7 +197,7 @@
unsigned int *id_len);
#ifndef OPENSSL_NO_DH
static DH *load_dh_param(const char *dhfile);
-static DH *get_dh512(void);
+static DH *get_dh2048(void);
#endif

#ifdef MONOLITH
@@ -213,30 +213,48 @@
#endif

#ifndef OPENSSL_NO_DH
-static unsigned char dh512_p[] = {
-0xDA, 0x58, 0x3C, 0x16, 0xD9, 0x85, 0x22, 0x89, 0xD0, 0xE4, 0xAF, 0x75,
-0x6F, 0x4C, 0xCA, 0x92, 0xDD, 0x4B, 0xE5, 0x33, 0xB8, 0x04, 0xFB, 0x0F,
-0xED, 0x94, 0xEF, 0x9C, 0x8A, 0x44, 0x03, 0xED, 0x57, 0x46, 0x50, 0xD3,
-0x69, 0x99, 0xDB, 0x29, 0xD7, 0x76, 0x27, 0x6B, 0xA2, 0xD3, 0xD4, 0x12,
-0xE2, 0x18, 0xF4, 0xDD, 0x1E, 0x08, 0x4C, 0xF6, 0xD8, 0x00, 0x3E, 0x7C,
-0x47, 0x74, 0xE8, 0x33,
+static unsigned char dh2048_p[] = {
+0xF6,0x42,0x57,0xB7,0x08,0x7F,0x08,0x17,0x72,0xA2,0xBA,0xD6,
+0xA9,0x42,0xF3,0x05,0xE8,0xF9,0x53,0x11,0x39,0x4F,0xB6,0xF1,
+0x6E,0xB9,0x4B,0x38,0x20,0xDA,0x01,0xA7,0x56,0xA3,0x14,0xE9,
+0x8F,0x40,0x55,0xF3,0xD0,0x07,0xC6,0xCB,0x43,0xA9,0x94,0xAD,
+

Re: [openssl-dev] OpenSSL version 1.0.2b released

2015-06-11 Thread Rainer Jung
The release notes mentioned and linked in all of the four release 
announcements still contain stale text:


https://www.openssl.org/news/openssl-1.0.2-notes.html
https://www.openssl.org/news/openssl-1.0.1-notes.html
https://www.openssl.org/news/openssl-1.0.0-notes.html
https://www.openssl.org/news/openssl-0.9.8-notes.html

The current release simply looks like

 Major changes between OpenSSL 1.0.2a and OpenSSL 1.0.2b [under 
development]


-

Major changes between OpenSSL 1.0.2 and OpenSSL 1.0.2a [19 Mar 2015]
...

So all entries for todays releases are still missing.

Maybe it is on its way, but since the announcement was 2 hours ago and 
the pages are linked in them I thought I'd better let you know.


Regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl-users] Is there openssl API to verify certificate content is DER or PEM format ?

2015-06-11 Thread Viktor Dukhovni
On Thu, Jun 11, 2015 at 06:01:26AM +0530, Nayna Jain wrote:

 I have similar concern for private key.
 If I have a pem file with private key in that, how do I check if that is
 RSA/DSA ?

In almost all cases don't check.  Just load and use the key as a
generic EVP_PKEY.

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] Build failure on SLES11

2015-06-11 Thread John Foley
It could be the gcc version is too old.  Trying to recall, gcc needs to
be something like 4.4 or newer to support the Intel carry-less multiply
instruction.



On 06/11/2015 09:37 AM, Dimitrios Apostolou wrote:
 Hello list,

 I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system.
 It fails unless I configure with no-asm. Here is the relevant output:

 gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC
 -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
 -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall
 -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
 -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
 -DECP_NISTZ256_ASM -c  -o ghash-x86_64.o ghash-x86_64.s
 ghash-x86_64.s: Assembler messages:
 ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq
 $17,%xmm2,%xmm0,%xmm1'
 ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq
 $0,%xmm2,%xmm0,%xmm0'
 [ ... many identical errors omitted ]


 I believe a check inside ./crypto/modes/asm/ghash-x86_64.pl is
 failing. Here is relevant output that might be of help:

 $ uname -a
 Linux buildslave3-sles-11-x86_64 2.6.27.19-5-default #1 SMP 2009-02-28
 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux
 $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
 GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU
 Binutils; SUSE Linux Enterprise 11) 2.19


 Thanks in advance,
 Dimitris

 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] Build failure on SLES11

2015-06-11 Thread Dimitrios Apostolou

Hello list,

I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system. 
It fails unless I configure with no-asm. Here is the relevant output:


gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H 
-Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
-DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c  -o ghash-x86_64.o 
ghash-x86_64.s
ghash-x86_64.s: Assembler messages:
ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq 
$17,%xmm2,%xmm0,%xmm1'
ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq 
$0,%xmm2,%xmm0,%xmm0'
[ ... many identical errors omitted ]


I believe a check inside ./crypto/modes/asm/ghash-x86_64.pl is failing. 
Here is relevant output that might be of help:


$ uname -a
Linux buildslave3-sles-11-x86_64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 
+0100 x86_64 x86_64 x86_64 GNU/Linux
$ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU Binutils; 
SUSE Linux Enterprise 11) 2.19


Thanks in advance,
Dimitris

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] [openssl.org #3902] #3423: Undefined behavior in crypto/cast/c_enc.c

2015-06-11 Thread starlight.201...@binnacle.cx via RT
Hello,

FYI using gcc 4.9.2 on x86_64 AMD

after Configure added

   -flto
   -g
   -fstack-protector-all --param ssp-buffer-size=1
   -fsanitize=address
   -fsanitize=undefined
   -fasynchronous-unwind-tables
   -DOPENSSL_NO_BUF_FREELIST

and 'make test' fails with old bug marked resolved

  3423: Undefined behavior in crypto/cast/c_enc.c



started with

./Configure \
linux-x86_64 \
enable-ec_nistp_64_gcc_128 \
shared \
threads \
zlib \
no-ssl2 \
no-ssl3 \
no-exp-edh-rsa-des-cbc-sha \
no-exp-edh-dss-des-cbc-sha \
no-exp-des-cbc-sha \
no-exp-rc2-cbc-md5 \
no-exp-rc4-md5 \
--openssldir=/usr/local/openssl-1.0.2

Regards

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL Security Advisory

2015-06-11 Thread Steffen Nurpmeso
Huhu!!

 |Fixes for this issue were developed by Emilia Käsper and Kurt Roeckx

I just want to mention these «UTF-8 re-encoded as UTF-8» issues,
which may be acceptable for names of males, but, but
*particularly* with respect to the natural beauty of the affected
person…  On the other hand i always knew engineers have the
etiquettes of construction workers.
The good news: it seems to be a long way to Boko Haram.  Still.


Also it is a real pity that it seems to be too hard to copy and
paste the NEWS.  And now it didn't even help to point one of those
HTML monsters to the cesspool.
Wait.  I haven't said there is a coincidence.


(^_^)/

--steffen
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] Openssl Poodle Vulnerability Clarification

2015-06-11 Thread Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco)
Hi All,

To resolve openSSL POODLE vulnerability we need to disable the SSLv3. In our 
application we have using openSSL through Apache. We have disabled using the 
below lines.

SSLProtocol all -SSLv2 -SSLv3

We are using 443 as SSL port. The command openssl s_client -connect 
IPAddress:443 -ssl3 shows the handshake failure message for 443 port. But for 
the ports  and  is connecting using SSLv3. The scanner as well report 
the high severity risk for those ports. In our application we are using those 
ports for syslog related tasks. If we change the port some other, then the 
scanner shows the new port in the list.

How to disable the SSLv3 connection for those ports as well since may customers 
are waiting for the fix. Your suggestion is much appreciated. 

Thanks,
Kannan Narayanasamy.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3903] Infer run on openssl-1.0.2a

2015-06-11 Thread Jules Villard via RT
On Thu, 11 Jun 2015 22:47:16 +, Salz, Rich via RT wrote:
 This is great!
 
 Any chance you can run it against master?  I'm hoping most of the ones in 
 apps go away ...

On master I get the following 12 reports. The first 10 seem to match
reports in my previous email, and the last two are new. I've looked at
the result of inferTraceBugs on those and added comments.

apps/srp.c:109: error: NULL_DEREFERENCE
   pointer pp last assigned on line 108 could be null and is dereferenced at 
line 109, column 47

apps/srp.c:126: error: NULL_DEREFERENCE
   pointer pp last assigned on line 124 could be null and is dereferenced at 
line 126, column 13

apps/x509.c:1008: error: NULL_DEREFERENCE
   pointer upkey last assigned on line 1007 could be null and is dereferenced 
by call to EVP_PKEY_copy_parameters() at line 1008, column 5

crypto/mem_dbg.c:650: error: NULL_DEREFERENCE
   pointer lcl last assigned on line 647 could be null and is dereferenced at 
line 650, column 22

crypto/objects/o_names.c:104: error: NULL_DEREFERENCE
   pointer name_funcs last assigned on line 102 could be null and is 
dereferenced at line 104, column 9

crypto/objects/o_names.c:106: error: NULL_DEREFERENCE
   pointer name_funcs last assigned on line 102 could be null and is 
dereferenced at line 106, column 9

crypto/objects/o_names.c:108: error: NULL_DEREFERENCE
   pointer name_funcs last assigned on line 102 could be null and is 
dereferenced at line 108, column 9

crypto/pkcs7/pk7_doit.c:1096: error: NULL_DEREFERENCE
   pointer ri last assigned on line 1095 could be null and is dereferenced at 
line 1096, column 12

crypto/x509/x509_cmp.c:406: error: NULL_DEREFERENCE
   pointer x last assigned on line 401 could be null and is dereferenced at 
line 406, column 55

crypto/x509/x509_req.c:125: error: NULL_DEREFERENCE
   pointer xk last assigned on line 124 could be null and is dereferenced by 
call to EVP_PKEY_cmp() at line 125, column 13

crypto/x509v3/v3_prn.c:131: error: NULL_DEREFERENCE
   pointer extoct last assigned on line 130 could be null and is dereferenced 
by call to ASN1_STRING_data() at line 131, column 9

  If X509V3_EXT_print() is called with ext == NULL then
  X509_EXTENSION_get_data(ext) returns NULL and exctoct == NULL gets
  dereferenced.

crypto/x509v3/v3_scts.c:187: error: NULL_DEREFERENCE
   pointer oct last assigned on line 179 could be null and is dereferenced at 
line 187, column 9

  This one looks like it might be a false positive where Infer doesn't
  know that d2i_ASN1_OCTET_STRING() will allocate oct.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] Openssl Poodle Vulnerability Clarification

2015-06-11 Thread Kurt Roeckx
On Thu, Jun 11, 2015 at 09:43:24PM +, Kannan Narayanasamy -X (kannanar - 
HCL TECHNOLOGIES LIMITED at Cisco) wrote:
 Hi All,
 
 To resolve openSSL POODLE vulnerability we need to disable the SSLv3. In our 
 application we have using openSSL through Apache. We have disabled using the 
 below lines.
 
 SSLProtocol all -SSLv2 -SSLv3
 
 We are using 443 as SSL port. The command openssl s_client -connect 
 IPAddress:443 -ssl3 shows the handshake failure message for 443 port. But 
 for the ports  and  is connecting using SSLv3. The scanner as well 
 report the high severity risk for those ports. In our application we are 
 using those ports for syslog related tasks. If we change the port some other, 
 then the scanner shows the new port in the list.
 
 How to disable the SSLv3 connection for those ports as well since may 
 customers are waiting for the fix. Your suggestion is much appreciated. 

There are 2 solutions:
- Change the configuration of syslog to disable SSLv3.  Not sure
  it can actually be configured.
- Build your openssl with SSLv3 disabled.


Kurt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3903] Infer run on openssl-1.0.2a

2015-06-11 Thread Salz, Rich via RT
This is great!

Any chance you can run it against master?  I'm hoping most of the ones in apps 
go away ...


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] [openssl.org #3903] Infer run on openssl-1.0.2a

2015-06-11 Thread Jules Villard via RT
Hello,

The following 13 potential null-pointer dereference bugs were found by
running Facebook's Infer static analyzer on openssl-1.0.2a. You can
reproduce these reports by downloading Infer and running it like so:

  https://fbinfer.org/docs/getting-started.html
  cd openssl-1.0.2a
  ./config  make clean
  infer -- make
  inferTraceBugs

The last command allows you to see more information about each report,
in particular symbolic traces that lead to the bug.

- apps/srp.c at line 149: NULL_DEREFERENCE
pointer pp last assigned on line 148 could be null and is dereferenced at 
line 149, column 43

  apps/srp.c at line 166: NULL_DEREFERENCE
pointer pp last assigned on line 164 could be null and is dereferenced at 
line 166, column 13

  The functions print_entry and print_user don't check that
  db-data-data is not NULL, hence sk_OPENSSL_PSTRING_value could
  return NULL.

  Additional note: the test is slightly different in both cases:
  verbose  0 for print_user vs indx = 0  verbose for
  print_entry.

- apps/x509.c at line 1108: NULL_DEREFERENCE
pointer upkey last assigned on line 1107 could be null and is dereferenced 
by call to EVP_PKEY_copy_parameters() at line 1108, column 5

  Calling x509_certify() with xca == NULL or xca-cert_info == NULL
  makes X509_get_pubkey() return NULL, which triggers a NULL
  dereference in EVP_PKEY_copy_parameters().

  Additional note: the return value of X509_get_pubkey() is checked
  for NULL elsewhere in the codebase, eg, in apps/ca.c:1597.

- apps/x509.c at line 1220: NULL_DEREFERENCE
pointer pktmp last assigned on line 1219 could be null and is dereferenced 
by call to EVP_PKEY_copy_parameters() at line 1220, column 5

  Similar to the previous one.

- crypto/mem_dbg.c at line 647: NULL_DEREFERENCE
pointer lcl last assigned on line 644 could be null and is dereferenced at 
line 647, column 22

  localtime(3) can return NULL in case of error.

- crypto/objects/o_names.c at line 105: NULL_DEREFERENCE
pointer name_funcs last assigned on line 103 could be null and is 
dereferenced at line 105, column 9

  crypto/objects/o_names.c at line 107: NULL_DEREFERENCE
pointer name_funcs last assigned on line 103 could be null and is 
dereferenced at line 107, column 9

  crypto/objects/o_names.c at line 109: NULL_DEREFERENCE
pointer name_funcs last assigned on line 103 could be null and is 
dereferenced at line 109, column 9

  If the names_type_num  0 or if name_type_num =
  name_funcs_stack-num, then name_funcs is assigned to NULL on
  line 103. These ones may be false positives, as it looks like that
  this can never be the case in that file.

- crypto/pkcs7/pk7_doit.c at line 1149: NULL_DEREFERENCE
pointer ri last assigned on line 1148 could be null and is dereferenced at 
line 1149, column 12

  If PKCS7_get_issuer_and_serial() is called with idx  0 then the
  execution gets to the last call to sk_PKCS7_RECIP_INFO_value(),
  which returns NULL.

- crypto/x509/x509_cmp.c at line 410: NULL_DEREFERENCE
pointer x last assigned on line 405 could be null and is dereferenced at 
line 410, column 55

  If X509_chain_check_suiteb() is called with chain == NULL, then the
  call to sk_X509_value() on line 410 will assign NULL to x. Line 410
  is X509_get_version(x), which dereferences x without checking for
  NULL.

- crypto/x509/x509_req.c at line 125: NULL_DEREFERENCE
pointer xk last assigned on line 124 could be null and is dereferenced by 
call to EVP_PKEY_cmp() at line 125, column 13

  If X509_REQ_check_private_key() is called with x == NULL, then xk
  will get NULL on line 124.

- crypto/x509/x509_req.c at line 204: NULL_DEREFERENCE
pointer attr last assigned on line 203 could be null and is dereferenced at 
line 204, column 13

  In X509_REQ_get_extensions(), the call to X509_REQ_get_attr_by_NID()
  may return -2 as an error code, but the caller checks for -1
  instead. This results in an NPE a few lines down, as the -2 is
  passed to X509_REQ_get_attr(), which sees that idx is invalid and
  returns NULL. Then attr == NULL is dereferenced by attr-single in
  the condition of the if statement on the next line.

- crypto/x509/x509_lu.c at line 311: NULL_DEREFERENCE
pointer lu last assigned on line 310 could be null and is dereferenced by 
call to X509_LOOKUP_by_subject() at line 311, column 17

  If vs-ctx-get_cert_methods is NULL then sk_X509_LOOKUP_num()
  returns -1 in the condition of the for loop. Then, if
  vs-current_method  -1 we still enter the body of the loop. Then lu
  gets assigned to NULL by sk_X509_LOOKUP_value.


Best regards,
Jules Villard
Facebook Static Analysis Tools Team

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] sizeof (HMAC_CTX) changes with update, breaks binary compatibility

2015-06-11 Thread Dan McDonald
I noticed that a new field was added to HMAC_CTX in the 1.0.2a-b or 1.0.1m-n 
update:

typedef struct hmac_ctx_st {
   const EVP_MD *md;
   EVP_MD_CTX md_ctx;
   EVP_MD_CTX i_ctx;
   EVP_MD_CTX o_ctx;
   unsigned int key_length;
   unsigned char key[HMAC_MAX_MD_CBLOCK];
+ int key_init;
} HMAC_CTX;

This breaks binary compatibility.  I found this out the hard way during an 
attempt to update OmniOS's OpenSSL to 1.0.2b ('014, bloody) or 1.0.1n (006, 
012).  Observe our use of HMAC_CTX in illumos (which OmniOS is a distribution 
of):

struct Mac {
char*name;
int enabled;
u_int   mac_len;
u_char  *key;
u_int   key_len;
int type;
const EVP_MD*evp_md;
HMAC_CTXevp_ctx;
};
struct Comp {
int type;
int enabled;
char*name;
};
struct Newkeys {
Enc enc;
Mac mac;
Compcomp; /* XXX KEBE SAYS THIS GETS CLOBBERED!!! */
};

You can see the code here:


http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/ssh/include/kex.h#100

What is supposed to happen in this situation?  I was under the impression that 
letter releases don't break binary compatibility.  The SSH in illumos breaks 
because of this, but it appears OpenSSH has worked around such a situation.

Clues are welcome.

Thanks,
Dan McDonald -- OmniOS Engineering

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

2015-06-11 Thread Bill Cox
Actually, just to get the ball rolling, I'll integrate the reg version of
Blake2, which is portable C, and a bit faster than the reference version,
which was designed for readability rather than performance.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] sizeof (HMAC_CTX) changes with update, breaks binary compatibility

2015-06-11 Thread Dan McDonald

 On Jun 11, 2015, at 9:07 PM, Dan McDonald dan...@omniti.com wrote:
 
 typedef struct hmac_ctx_st {
   const EVP_MD *md;
   EVP_MD_CTX md_ctx;
   EVP_MD_CTX i_ctx;
   EVP_MD_CTX o_ctx;
   unsigned int key_length;
   unsigned char key[HMAC_MAX_MD_CBLOCK];
 + int key_init;
 } HMAC_CTX;

A cheesy, but binary compatible, fix might be:

typedef struct hmac_ctx_st {
  const EVP_MD *md;
  EVP_MD_CTX md_ctx;
  EVP_MD_CTX i_ctx;
  EVP_MD_CTX o_ctx;
  unsigned int key_init:1;   /* Ewww, cheesy use of bitfields... */
  unsigned int key_length:31;  /* but the sizeof (HMAC_CTX) doesn't change! */
  unsigned char key[HMAC_MAX_MD_CBLOCK];
} HMAC_CTX;


Dan

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] sizeof (HMAC_CTX) changes with update, breaks binary compatibility

2015-06-11 Thread Peter Waltenberg

Which is exactly why our hacked version of OpenSSL has
allocators/deallocators for all these private struct's.

It'd be really nice if OpenSSL would fix this, adding them won't break
backwards compatibility (i.e. API breakage isn't an excuse for not fixing
these)  and going forwards problems like this would stop occuring.

Peter

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

2015-06-11 Thread Yoav Nir

 On Jun 11, 2015, at 2:36 AM, Bill Cox waywardg...@google.com wrote:
 
 BLAKE2 rocks.  I'm looking forward to using it in many applications.
 

Sure. I would be glad to see that used as a hash in signatures and in TLS, as a 
PRF in TLS and IKE, etc.

Does anyone know what the status of draft-saarinen-blake2 is?  If that 
progresses we can propose things like 
TLS_ECDHE_EdDSA_WITH_CHACHA20_POLY1305_BLAKE2[*] or PRF_BLAKE2.

Yoav

[*] I think we should call that ciphersuite “Suite-C” with ‘C’ standing for 
civilian, because this is a whole bunch of algorithms, none of which came from 
the government of the (pseudo-)military.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)

2015-06-11 Thread Andy Polyakov
Hi,

Can we use armv8 assembly support provided in openssl-1.0.2a for
 32 bit mode compilation.

It *is* used in 32-bit compilation as-is. aesv8-armx and ghashv8-armx
are included in armv4_asm, and sha1-armv4-large and sha256-armv4 modules
incorporate support for ARMv8 SHA instructions. But don't miss
commentary in Configure prior linux-armv4 line.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] A Question about CRYPTO_THREADID when upgrading to OpenSSL 1.0.1e

2015-06-11 Thread Florian Weimer
On 01/14/2014 07:12 AM, Aaron wrote:
 Hi All,
 
 We have upgraded our OpenSSL from 9.0.8b to OpenSSL 1.0.1e. We have
 encountered some thread issues. From releated OpenSSL document
 (http://www.openssl.org/docs/crypto/threads.html), we see the following
 description.
 
 /CRYPTO_THREADID and associated functions were introduced in OpenSSL 1.0.0
 to replace (actually, deprecate) the previous CRYPTO_set_id_callback(),
 CRYPTO_get_id_callback(), and CRYPTO_thread_id() functions which assumed
 thread IDs to always be represented by 'unsigned long'. /
 
 We haven't change all calls to CRYPTO_set_id_callback(),
 CRYPTO_get_id_callback(), and CRYPTO_thread_id() in our code to
 CRYPTO_THREADID routines. 
 
 The question I would like to ask is if we upgrade OpenSSL from 9.0.8b to
 OpenSSL 1.0.1e without making the above suggested change what the
 sebsequence is? Will this cause race conditions?

Which platform are you on?

-- 
Florian Weimer / Red Hat Product Security
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] OpenSSL version 1.0.2b released

2015-06-11 Thread OpenSSL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


   OpenSSL version 1.0.2b 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.2b of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

http://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2b 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.2b.tar.gz
  Size: 5281009
  MD5 checksum: 7729b259e2dea7d60b32fc3934d6984b
  SHA1 checksum: 9006e53ca56a14d041e3875320eedfa63d82aba7

   The checksums were calculated using the following commands:

openssl md5 openssl-1.0.2b.tar.gz
openssl sha1 openssl-1.0.2b.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVeZNdAAoJENnE0m0OYESRYscIAKrJik5qyPifnVhWRHVTUXot
NYhfl+h+ooHequRyz9ug7Wz3vdUioftuOYlX0eJBBZ+YvskVk27U9tjY+plFnRjq
vpdNKfa6bSL9rjztZObupvbCnhYRdDkcJRqLi8HfPb53UlZS/ALIbpDi1FPqIErs
Bc7D/toD0nDoQUONLVQw/aSZNWWCaACO09326K2xX/jZGEsQbhCWdlkERfO3RzRW
RBN0RnR+k8XBaqy6TRELF1vlYdHe83Dqxg1h3KBTBJ+yOFXvQblPoZO4GnkAyoNA
8EGhbzgWsjg6OIroUbnbbq50avvya/2eDmY+N3gNg5wOrYBNZlWShy91WGZ4378=
=rcRW
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] Build failure on SLES11

2015-06-11 Thread Dimitrios Apostolou

On Thu, 11 Jun 2015, Andy Polyakov wrote:


It's can as well be wrong. I mean it might have to be adjusted as
$1=2.20 instead of 2.19. While AVX support was added in binutils 2.19,
they might have omitted specifically vpclmulqdq. Can you confirm if it
works if you replace 2.19 with 2.20?



Indeed, I confirm that the following patch fixes the issue:


--- crypto/modes/asm/ghash-x86_64.pl.bak	2015-06-11 
17:04:21.0 +0200
+++ crypto/modes/asm/ghash-x86_64.pl	2015-06-11 17:04:28.0 
+0200

@@ -92,7 +92,7 @@

 if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 21`
=~ /GNU assembler version ([2-9]\.[0-9]+)/) {
-   $avx = ($1=2.19) + ($1=2.22);
+   $avx = ($1=2.20) + ($1=2.22);
 }

 if (!$avx  $win64  ($flavour =~ /nasm/ || $ENV{ASM} =~ /nasm/) 



Dimitris

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] OpenSSL Security Advisory

2015-06-11 Thread OpenSSL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [11 Jun 2015]
===

DHE man-in-the-middle protection (Logjam)


A vulnerability in the TLS protocol allows a man-in-the-middle
attacker to downgrade vulnerable TLS connections using ephemeral
Diffie-Hellman key exchange to 512-bit export-grade cryptography. This
vulnerability is known as Logjam (CVE-2015-4000).

OpenSSL has added protection for TLS clients by rejecting handshakes
with DH parameters shorter than 768 bits. This limit will be increased
to 1024 bits in a future release.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n

Fixes for this issue were developed by Emilia Käsper and Kurt Roeckx
of the OpenSSL development team.

Malformed ECParameters causes infinite loop (CVE-2015-1788)
===

Severity: Moderate

When processing an ECParameters structure OpenSSL enters an infinite loop if
the curve specified is over a specially malformed binary polynomial field.

This can be used to perform denial of service against any
system which processes public keys, certificate requests or
certificates.  This includes TLS clients and TLS servers with
client authentication enabled.

This issue affects OpenSSL versions: 1.0.2 and 1.0.1. Recent
1.0.0 and 0.9.8 versions are not affected. 1.0.0d and 0.9.8r and below are
affected.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0d (and below) users should upgrade to 1.0.0s
OpenSSL 0.9.8r (and below) users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 6th April 2015 by Joseph Birr-Pixton. The
fix was developed by Andy Polyakov of the OpenSSL development team.

Exploitable out-of-bounds read in X509_cmp_time (CVE-2015-1789)
===

Severity: Moderate

X509_cmp_time does not properly check the length of the ASN1_TIME
string and can read a few bytes out of bounds. In addition,
X509_cmp_time accepts an arbitrary number of fractional seconds in the
time string.

An attacker can use this to craft malformed certificates and CRLs of
various sizes and potentially cause a segmentation fault, resulting in
a DoS on applications that verify certificates or CRLs. TLS clients
that verify CRLs are affected. TLS clients and servers with client
authentication enabled may be affected if they use custom verification
callbacks.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0 users should upgrade to 1.0.0s
OpenSSL 0.9.8 users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 8th April 2015 by Robert Swiecki
(Google), and independently on 11th April 2015 by Hanno Böck. The fix
was developed by Emilia Käsper of the OpenSSL development team.

PKCS7 crash with missing EnvelopedContent (CVE-2015-1790)
=

Severity: Moderate

The PKCS#7 parsing code does not handle missing inner EncryptedContent
correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs
with missing content and trigger a NULL pointer dereference on parsing.

Applications that decrypt PKCS#7 data or otherwise parse PKCS#7
structures from untrusted sources are affected. OpenSSL clients and
servers are not affected.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0 users should upgrade to 1.0.0s
OpenSSL 0.9.8 users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 18th April 2015 by  Michal
Zalewski (Google). The fix was developed by Emilia Käsper of the
OpenSSL development team.

CMS verify infinite loop with unknown hash function (CVE-2015-1792)
===

Severity: Moderate

When verifying a signedData message the CMS code can enter an infinite loop
if presented with an unknown hash function OID.

This can be used to perform denial of service against any system which
verifies signedData messages using the CMS code.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0 users should upgrade to 1.0.0s
OpenSSL 0.9.8 users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 31st March 2015 by Johannes Bauer. The
fix was developed by Dr. Stephen Henson of the OpenSSL development team.

Race condition handling NewSessionTicket (CVE-2015-1791)


Severity: Low

If a NewSessionTicket is received by a multi-threaded client 

[openssl-dev] OpenSSL version 1.0.1n released

2015-06-11 Thread OpenSSL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


   OpenSSL version 1.0.1n 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.1n of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

http://www.openssl.org/news/openssl-1.0.1-notes.html

   OpenSSL 1.0.1n 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.1n.tar.gz
  Size: 4545564
  MD5 checksum: 139568bd5a56fa49b72a290d37113f30
  SHA1 checksum: 2f6ea1e0f2724aca1805392e4387df8361442ace

   The checksums were calculated using the following commands:

openssl md5 openssl-1.0.1n.tar.gz
openssl sha1 openssl-1.0.1n.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVeZWaAAoJENnE0m0OYESRqlwIAJ1ncajYk0swYcFxXEbCs02q
dI220NF3q9ohvXSzUVvM18Az8Lrr4u/bkZUNhmWkW2GwY7HF6DHUzgg7yWTWZ3h3
pxz33OxxNhBdXA0bkIl4d8q8SW9m7Xo+JZ2Pky2BC8MO3FTd5N8p9zfyJY63dtYV
W9pOV0M/LzD3CkFMyX1NdAsoy3KNxB4NFoGKxuaYyOSwyrYCkHBXsBZM5O4BhvDt
JeZMAcZagu4kNZ9fdNDNo28AxSOQicGuCqW4SOYnC/XACcsVvpuZYvMFdoqDRBN4
vWS91UAoor1Ld2IsdNsqe2D7S/35NKokvxdeUjbPKzyxPMoX5sgtJJyQZ6IUM0s=
=d4VL
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev