Dominyk Tiller | 24 Jul 18:09 2014
Picon

OS X OpenSSL


Hey all,

I noticed something in the latest Yosemite developer preview - Apple
has finally updated the OpenSSL that ships with OS X.

We remain on the 0.9.8 branch, but 'Openssl version' now gets the
response 'OpenSSL 0.9.8za 5 Jun 2014'. I guess this confirms that OS X
was vulnerable to the security issues OpenSSL patched and announced in
early June, given Apple's extreme reluctance to update OpenSSL at any
point other than when absolutely necessary.

I don't know however if Mavericks has been patched in the same way.
Can anyone on OS X 10.9-10.9.3/10.9.4 run the 'openssl version'
command and see what the response is? Curious if only Yosemite has
received this fix & Mavericks remains vulnerable.

It should seem unlikely, but given Apple's history with OpenSSL
updates I'm not quite certain either way.

I'd still prefer to be using the 1.0.1 branch but at least this seems
to close the vulnerabilities exposed last month.

Dominyk
--

-- 
Sent from Thunderbird for OS X. My PGP public key is automatically
attached to this email.
Attachment (0x9D74326C.asc): application/pgp-keys, 3561 bytes
Attachment (0x9D74326C.asc.sig): application/octet-stream, 734 bytes
(Continue reading)

noloader@gmail.com via RT | 24 Jul 17:17 2014
Picon

[openssl.org #3472] PATCH: Update info on PKCS8 command and -iter option

Following MC's comments at
https://groups.google.com/d/msg/mailing.openssl.users/BETH6d-kS38/2BikoVnINp8J:

$ cat pkcs8.pod.diff
diff --git a/doc/apps/pkcs8.pod b/doc/apps/pkcs8.pod
index e946cbd..59954de 100644
--- a/doc/apps/pkcs8.pod
+++ b/doc/apps/pkcs8.pod
 <at>  <at>  -81,7 +81,8  <at>  <at>  see the B<PASS PHRASE ARGUMENTS> section in
L<openssl(1)|openssl(1)>.

 When creating new PKCS#8 containers, use a given number of iterations
on the password
 in deriving the encryption key for the PKCS#8 output. High values
increase the time
-required to brute-force a PKCS#8 container.
+required to brute-force a PKCS#8 container. B<note>: this option is
available in
+OpenSSL 1.1.0 and above.

 =item B<-nocrypt>

diff --git a/doc/apps/pkcs8.pod b/doc/apps/pkcs8.pod
index e946cbd..59954de 100644
--- a/doc/apps/pkcs8.pod
+++ b/doc/apps/pkcs8.pod
 <at>  <at>  -81,7 +81,8  <at>  <at>  see the B<PASS PHRASE ARGUMENTS> section in L<openssl(1)|openssl(1)>.

(Continue reading)

Hubert Kario | 24 Jul 13:48 2014
Picon

Problems with cross-signed certificates and Authority Key Info

I have 4 key pairs:
 * CA1
 * CA2
 * subCA
 * server

the CA1 and CA2 are self signed root CAs

subCA has two certificates, one signed by CA1 and one signed by CA2

server has a certificate signed by subCA (server.pem file)
and also has Authority Key Identifier with DirName that points to CA1
(server2.pem file).

The problem happens when I try to verify the server certificate
using chain that links up to CA1 and one that links to CA2.

That is:
$ openssl verify -CAfile ca1.pem -untrusted subca-ca1.pem server2.pem
server2.pem: OK

$ openssl verify -CAfile ca2.pem -untrusted subca-ca2.pem server2.pem
server2.pem: CN = localhost
error 20 at 0 depth lookup:unable to get local issuer certificate

While
$ openssl verify -CAfile ca2.pem -untrusted subca-ca2.pem server.pem
server.pem: OK
$ openssl verify -CAfile ca1.pem -untrusted subca-ca1.pem server.pem
server.pem: OK
(Continue reading)

Andy Polyakov via RT | 24 Jul 10:55 2014
Picon

Re: [openssl.org #3471] [PATCH] md5-asm-aarch64-29regs

Hi,

> I would like to submit a patch for md5 calculation on aarch64 architectures.

Thanks for submission, but because of time constraints it will be looked
into later.

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

Hubert Kario via RT | 23 Jul 15:12 2014
Picon

Re: [openssl.org #3443] [patch] Implement Camellia-CBC suites from RFC6367

Pull request [v2], with correct formatting:

https://github.com/openssl/opensl/pull/154
--

-- 
Regards,
Hubert Kario

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

Matt Caswell via RT | 23 Jul 00:05 2014
Picon

[openssl.org #3467] FW: Critical vulnerabilities found (#8083-432678597-2590)

If you originally obtained your copy of OpenSSL in binary form (such as from
your OS vendor), then please get hold of the latest copy from them.

If you originally obtained your copy of OpenSSL in source form then you will
need to build a new version from the latest release on the OpenSSL website. If
you are having problems building from source then please post a message to the
openssl-users email list. Provide details of exactly what you have done and
what errors or problems you have encountered.

As this ticket is not a defect or request for enhancement I am closing it.

Matt

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

Andreas Kraschitzer via RT | 22 Jul 23:32 2014
Picon

[openssl.org #3471] [PATCH] md5-asm-aarch64-29regs

Hi,

I would like to submit a patch for md5 calculation on aarch64 architectures.

The patch is based on https://github.com/openssl/openssl
commit cba11f57ce161fd301a72194827327128191de7e
Author: Billy Brumley <bbrumley <at> gmail.com>
Date:   Mon Jul 21 22:08:23 2014 +0100

    "EC_POINT_invert" was checking "dbl" function pointer instead of "invert".

    PR#2569

    Reviewed-by: Rich Salz <rsalz <at> openssl.org>

Test: openssl speed md5

Testenvironment:
CPU: AArch64 Processor [500f0000] revision 0
Machine: APM X-Gene Mustang board
Kernel: Linux version 3.12.0-mustang_sw_1.12.10-beta
OS: Ubuntu 13.10
current openssl implementation:

root <at> localhost:~/tmp/baseline/openssl# ./install/bin/openssl speed md5         
Doing md5 for 3s on 16 size blocks: 6191686 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 4113283 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 2091292 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 705014 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 98077 md5's in 3.00s
(Continue reading)

Brian Hassink via RT | 22 Jul 23:32 2014
Picon

[openssl.org #3470] [BUG] DTLS abort

OpenSSL:             1.0.1e

OS:                         Red Hat Enterprise Linux Server release 6.5 (Santiago)

Hello,

We recently did some negative testing against OpenSSL 1.0.1e, with a focus on DTLS, and observed that the
library, running on the peer, could be made to abort by simply disconnecting during the handshake process.

The abort is due to a getsockopt() or setsockopt() call failing from within dgram_sctp_read() because the
socket descriptor has been rendered invalid by the disconnect.

We ran the same scenario against TLS, but it is not affected.

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

Massimiliano Pala | 22 Jul 23:15 2014

Reporting an Issue with OpenSSL in MacOS SDK 10.8

Hi all,

working on porting my LibPKI implementation (based on OpenSSL) to MacOS 
I found out an issue that is not really related to the code itself but 
the distributed version in the SDK.

In particular, I found out that several functions' signatures have been 
altered in their return codes. This is particularly scary as they 
removed the ability to verify the return code by changing the return 
type to void. An example of this is: HMAC_Init_ex(), HMAC_Update(), 
HMAC_Final().

I don't know if there are others functions that have been "redacted",
but I expect that to be true.

I am not sure if this is an issue or if any of the people subscribed 
here from Apple could explain why they changed an API that is not theirs 
and that causes portability issues of applications that are based on 
OpenSSL. But I think this is a big mistake from Apple and if we could 
manage to have them to actually include a non-modified version of the 
API (or at least change the names of include/lib so that applications 
will not have compiling issues and/or binary incompatibilities), that 
would be a good outcome.

This, of course, unless I am missing an important reason - so far, my 
contacts at Apple were not able to give any real reasons for that odd 
changes other than (quote) "it must be that Apple looked at the code and 
those functions can not fail.. besides what would you do if that fails 
?" (arguably, a very wrong answer also considering it is not an Apple's 
internal API).
(Continue reading)

Massimiliano Pala | 22 Jul 21:23 2014

Reporting an Issue with OpenSSL in MacOS SDK 10.8

Hi all,

working on porting my libpki implementation (based on OpenSSL) to MacOS 
I found out an issue that is not really related to the code itself but 
the distributed version in the SDK.

In particular, I found out that several functions' signatures have been 
altered in their return codes. This is particularly scary as they 
removed the ability to verify the return code by changing the return 
type to void. An example of this is: HMAC_Init_ex(), HMAC_Update(), 
HMAC_Final().

I don't know if there are others.

I am not sure if this is an issue or if any of the people subscribed 
here from Apple could explain why they changed an API that is not theirs 
and that causes portability issues of applications that are based on 
OpenSSL. But I think this is a big mistake from Apple and if we could 
manage to have them to actually include a non-modified version of the 
API (or at least change the names of include/lib so that applications 
will not have compiling issues and/or binary incompatibilities), that 
would be a good outcome.

This, of course, unless I am missing an important reason - so far, my 
contacts at Apple were not able to give any real reasons for that odd 
changes other than (quote) "it must be that Apple looked at the code and 
those functions can not fail.. besides what would you do if that fails 
?" (arguably, a very wrong answer also considering it is not an Apple's 
internal API).

(Continue reading)

Massimiliano Pala | 22 Jul 15:37 2014

Reporting an Issue with OpenSSL in MacOS SDK 10.8

Hi all,

working on porting my libpki implementation (based on OpenSSL) to MacOS 
I found out an issue that is not really related to the code itself but 
the distributed version in the SDK.

In particular, I found out that several functions' signatures have been 
altered in their return codes. This is particularly scary as they 
removed the ability to verify the return code by changing the return 
type to void. An example of this is: HMAC_Init_ex(), HMAC_Update(), 
HMAC_Final().

I don't know if there are others.

I am not sure if this is an issue or if any of the people subscribed 
here from Apple could explain why they changed an API that is not theirs 
and that causes portability issues of applications that are based on 
OpenSSL. But I think this is a big mistake from Apple and if we could 
manage to have them to actually include a non-modified version of the 
API (or at least change the names of include/lib so that applications 
will not have compiling issues and/or binary incompatibilities), that 
would be a good outcome.

This, of course, unless I am missing an important reason - so far, my 
contacts at Apple were not able to give any real reasons for that odd 
changes other than (quote) "it must be that Apple looked at the code and 
those functions can not fail.. besides what would you do if that fails 
?" (arguably, a very wrong answer also considering it is not an Apple's 
internal API).

(Continue reading)


Gmane