openssl 1.0.1d Broken

[dylanryan]

As of the most recent openssl update installed via sudo port upgrade outdated, it seems that using curl or wget (and presumably anything else using openssl) to fetch a https page fails.

For example:

$ curl https://google.com
curl: (35) error:1006706B:elliptic curve routines:ec_GFp_simple_oct2point:point is not on curve

$wget https://google.com
--2013-02-10 17:05:19--  https://google.com/
Resolving google.com (google.com)... 74.125.224.36, 74.125.224.39, 74.125.224.41, ...
Connecting to google.com (google.com)|74.125.224.36|:443... connected.
ERROR: The certificate of ‘google.com’ is not trusted.
ERROR: The certificate of ‘google.com’ hasn't got a known issuer.

Similar problems on similar pages (dropbox, etc. I can't find any https page that actually _works_)

Specs and such: Macports: v 2.1.3

Ports:

  openssl @1.0.1d_0 (active)
  curl @7.29.0_0+ssl (active)
  curl-ca-bundle @7.29.0_0 (active)
  wget @1.14_2+ssl (active)

System: 10.8.2, on a early 2011 MBP i7

[neverpanic (Clemens Lang)]

If you didn't uninstall openssl 1.0.1c yet, you might want to run

sudo port -f deactivate openssl
sudo port activate openssl @1.0.1c_0

meanwhile.

[dylanryan]

Thanks. Unfortunately, I didn't notice the issue immediately, so I did uninstall it. Not a huge issue for me at the moment, I can work around it by downloading things with a browser instead for the time being.

That said, if there's a way to re-download the older version via macports (I'm fine replacing portfiles if that is what is needed), that might be helpful.

[neverpanic (Clemens Lang)]

As a temporary fix, force-uninstalling openssl, then reverting the Portfile to the old version and running port install in the directory where the Portfile is should work. Also see wiki:howto/InstallingOlderPort.

You can get the old version of the Portfile from source:trunk/dports/devel/openssl/.

[dylanryan]

Thanks, that worked (sort of). Of course, after it installed, the broken port scanner (rev-upgrade) indicated that python27 is broken, and proceeded to start downloading it's dependencies... including the new openssl. Fun times.

I killed that, and things seem to work for now, and I can switch back and forth between the various OpenSSLs depending on what ports I need to work at any given time, though it is likely to be a little unstable I suspect (that's fine with me, though).

[skymoo (Adam Mercer)]

Cc Me!

[jmroot (Joshua Root)]

Upstream ticket with link to fix in upstream git: ​http://rt.openssl.org/Ticket/Display.html?id=2975

Please apply the fix rather than reverting to 1.0.1c, as 1.0.1d also fixes some CVEs.

[ryandesign (Ryan Carsten Schmidt)]

#38017 might be a duplicate.

[neverpanic (Clemens Lang)]

Replying to jmr@…:

Please apply the fix rather than reverting to 1.0.1c, as 1.0.1d also fixes some CVEs.

The commit that broke compatibility in the first place was the one fixing two out of three of these CVEs. I haven't found any comment by upstream on whether they claim their fix for the issue also closes these. The third CVE left over is only a DoS. Debian is holding off the update, and so should we, unless somebody of you knows his way around the crypto code at hand (people have previously failed at patching openssl…).

[davidfavor (David Favor)]

Definitely best to roll back to openssl-1.0.1c as openssl-1.0.1d breaks many versions of ssh + scp making it impossible to login to external machines or copy files between them. Very ugly.

[davidfavor (David Favor)]

browser:trunk/dports/devel/openssl/Portfile?rev=92914​ is the link to the openssl-1.0.1c portfile so you can downgrade.

[ryandesign (Ryan Carsten Schmidt)]

As reported on our mailing list, 1.0.1e is out now.

[ryandesign (Ryan Carsten Schmidt)]

mww updated the port to 1.0.1e in r103006. Does that fix the problem?

[dylanryan]

Yes and no. the +universal variant appears to be broken still, but -universal works.

~/Desktop $ port installed openssl
The following ports are currently installed:
  openssl @1.0.1e_0
  openssl @1.0.1e_0+universal (active)
~/Desktop $ curl https://google.com
curl: (35) error:1006706B:elliptic curve routines:ec_GFp_simple_oct2point:point is not on curve
~/Desktop $ sudo port activate  openssl @1.0.1e_0
--->  Computing dependencies for openssl
--->  Deactivating openssl @1.0.1e_0+universal
--->  Cleaning openssl
--->  Activating openssl @1.0.1e_0
--->  Cleaning openssl
~/Desktop $ curl https://google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>
~/Desktop $ sudo port activate  openssl @1.0.1e_0+universal
--->  Computing dependencies for openssl
--->  Deactivating openssl @1.0.1e_0
--->  Cleaning openssl
--->  Activating openssl @1.0.1e_0+universal
--->  Cleaning openssl
~/Desktop $ curl https://google.com
curl: (35) error:1006706B:elliptic curve routines:ec_GFp_simple_oct2point:point is not on curve
~/Desktop $ 

Edit: Note that I did NOT use the +universal variant of curl. python27+universal requests the universal variant of openssl, and appears broken without it, and curl appears broken with it. Unsure why I have python27 installed +universal honestly, I try never to use that unless I NEED it, so my solution is just going to be to follow dependencies back rebuilding -universal until I either find something that I did specifically want universal, or else make macports happy. But that probably isn't a good solution for others.

Edit x2: Ah, boost requires python27, and I do want boost +universal. That explains why it was built universal in the first place.

[Serge3leo (Serguei E. Leontiev)]

Cc Me!

[Serge3leo (Serguei E. Leontiev)]

Replying to dylanryan@…: For

$ openssl version
OpenSSL 1.0.1e 11 Feb 2013

wget workaround: add root certificate "OU = Equifax Secure Certificate Authority, O = Equifax, C = US", for example from /opt/local/share/curl/curl-ca-bundle.crt

$ wget --ca-certificate=/opt/local/share/curl/curl-ca-bundle.crt https://google.com/
$ arch -x86_64 wget --ca-certificate=/opt/local/share/curl/curl-ca-bundle.crt https://google.com/
$ arch -i386 wget --ca-certificate=/opt/local/share/curl/curl-ca-bundle.crt https://google.com/

Both 32-bit & 64-bit version `wget' work fine.

curl & "openssl s_client" workaround: use 32-bit or use RC4-SHA cipher

$ arch -i386 curl https://google.com/
$ arch -x86_64 curl --ciphers $( openssl ciphers | sed 's/ECDH[^:]*://g' ) https://google.com/
$ arch -i386 openssl s_client -connect www.google.com:443 -CAfile /opt/local/share/curl/curl-ca-bundle.crt -debug
$ arch -x86_64 openssl s_client -connect www.google.com:443 -CAfile Equifax\ Secure\ Certificate\ Authority.pem -cipher $( openssl ciphers | sed 's/ECDH[^:]*://g' )

[elventear (Pepe Barbe)]

OpenSSL 1.0.1e still exhibits the problems described in #38017. Only downgrading to 1.0.1c has resolved the issue.

[Serge3leo (Serguei E. Leontiev)]

Replying to jmr@…:

Upstream ticket with link to fix in upstream git: ​http://rt.openssl.org/Ticket/Display.html?id=2975

Probably, this is macports bug, not openssl. "Original" OpenSSL 1.0.1e with default configure work fine with "​https://www.google.com".

$ cd openssl-1.0.1e.test
$ ./Configure darwin64-x86_64-cc
$ make
$ sh -x util/opensslwrap.sh s_client -connect www.google.com:443 -CAfile ~/Temp/Equifax\ Secure\ Certificate\ Authority.pem
...OK 64-bit
$ make clean
$ ./config
$ make 
$ sh -x util/opensslwrap.sh s_client -connect www.google.com:443 -CAfile ~/Temp/Equifax\ Secure\ Certificate\ Authority.pem
...OK 32-bit

[Serge3leo (Serguei E. Leontiev)]

Complete workaround for OpenSSL-1.0.1e port:

sudo port edit openssl

Remove "no-asm" from

configure.args      -L${prefix}/lib --openssldir=${prefix}/etc/openssl zlib no-krb5 shared no-asm

to

configure.args      -L${prefix}/lib --openssldir=${prefix}/etc/openssl zlib no-krb5 shared

Rebuild openssl port

sudo port upgrade --force openssl

32-bit & 64-bit version of wget, curl and "openssl s_client" work fine

[dylanryan]

Replying to leo@…:

Complete workaround for OpenSSL-1.0.1e port:

sudo port edit openssl

Remove "no-asm" from

configure.args      -L${prefix}/lib --openssldir=${prefix}/etc/openssl zlib no-krb5 shared no-asm

...

Works for me. Thanks!

[elventear (Pepe Barbe)]

Work around from leo works for me too. Not experiencing #38017 anymore with 1.0.1e

[blair (Blair Zajac)]

Cc Me!

[blair (Blair Zajac)]

I just rebuilt openssl on my 5 year old iMac running 10.7 and removing the "no-asm" flag got ssh to successfully connect to my linux box.

[blair (Blair Zajac)]

On my ancient PowerBook running 10.5.8 openssl 1.0.1d and 1.0.1e work with no modifications to the Portfile.

[Serge3leo (Serguei E. Leontiev)]

Replying to blair@…:

On my ancient PowerBook running 10.5.8 openssl 1.0.1d and 1.0.1e work with no modifications to the Portfile.

Probably this "strict aliasing" optimization bug for "crypto/bn/bn_nist.c", see [openssl.org #2981] ​http://rt.openssl.org/Ticket/Display.html?id=2981

Mac OSX x86_64 compiler fail test/ectest: cc [Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)] gcc-mp-4.3 gcc-mp-4.4 gcc-mp-4.5 gcc-mp-4.6 clang-mp-3.0 clang-mp-3.1 clang-mp-3.2

Mac OSX x86_64 compiler test/ectest OK: gcc-apple-4.2 gcc-mp-4.7 gcc-mp-4.8 [gcc-mp-4.8 (MacPorts gcc48 4.8-20130203_0+universal) 4.8.0 20130203 (experimental)] clang-mp-2.9 clang-mp-3.3 [clang version 3.3 (trunk 173279)]

Use `sudo port test openssl' for test openssl port on your system&compiler

[davidfavor (David Favor)]

port test openssl throws this error for me...

:info:test testing internal curves: ...........
:info:test EC_GROUP_check() failed with curve secp384r1
:info:test .
:info:test EC_GROUP_check() failed with curve prime192v1
:info:test 
:info:test EC_GROUP_check() failed with curve prime192v2
:info:test 
:info:test EC_GROUP_check() failed with curve prime192v3
:info:test ...
:info:test EC_GROUP_check() failed with curve prime256v1
:info:test ............................................... failed

[davidfavor (David Favor)]

Ran a the complete test suite via 'make -i' to show all errors.

Attached test log.

Tried to send this to upstream openssl by emailing rt@… (per openssl Website) and my email was rejected.

Unsure how to report this to openssl.

If someone knows, pass along the attached test log to the developers.

[davidfavor (David Favor)]

Looks like this has already been reported (​http://www.mail-archive.com/openssl-dev@openssl.org/msg32077.html) even though a search of the openssl bug tracker fails to mention this bug.

[Serge3leo (Serguei E. Leontiev)]

Replying to david@…:

port test openssl throws this error for me...

After workaround (port edit openssl, see above) must OK Warring, You need `port edit' after every port selfupdate etc.

About, OpenSSL, most instillation OpenSSL not use "no-asm" configure flag, this default (!). But macports use this flag

[davidfavor (David Favor)]

Attached is a copy of the openssh-6.1p1 test log which shows a failure.

Version of openssl installed is... OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012 which should have been working for a long time.

So there are two test failures, one in openssl-1.0.1e + one in openssh-6.1p1 (using openssl-1.0.1c) which suggests, best to run test suites before deploying port updates.

Guess the correct action is to wait until openssl fixes their test suite failure, then try retesting openssh.

[ryandesign (Ryan Carsten Schmidt)]

Replying to leo@…:

About, OpenSSL, most instillation OpenSSL not use "no-asm" configure flag, this default (!). But macports use this flag

Yes. We started using this flag in r92126, apparently to fix a built failure on Lion x86_64. If Lion x86_64 no longer fails when we remove that flag, then we should remove that flag. Removing that flag did also fix the problems mentioned in this ticket for me, on Mountain Lion.

[Serge3leo (Serguei E. Leontiev)]

Replying to ryandesign@…:

Replying to leo@…:

About, OpenSSL, most instillation OpenSSL not use "no-asm" configure flag, this default (!). But macports use this flag

Yes. We started using this flag in r92126, apparently to fix a built failure on Lion x86_64. If Lion x86_64 no longer fails when we remove that flag, then we should remove that flag...

I test Lion with last Xcode:

MacBook-Pro-lvadmin:~ lvadmin$ uname -a
Darwin MacBook-Pro-lvadmin.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
MacBook-Pro-lvadmin:~ lvadmin$ xcodebuild -version
Xcode 4.6
Build version 4H127

OK, workaround work fine. Because, Xcode version identical, results identical. See attachment: lion-openssl-no-asm.log and lion-openssl.log.

[davidfavor (David Favor)]

Looks like openssl upstream has opened a bug about openssl-1.0.1e test suite failure.

​http://rt.openssl.org/Ticket/History.html?id=2989 is the upstream ticket history.

[davidfavor (David Favor)]

Looking through this bug, I removed no-asm in the Portfile + ran the test suite again.

Without no-asm the test suite runs with 100% passes.

Suggest releasing a new Portfile removing no-asm for Mountain Lion. From the above comments, looks like this is already in the works.

[ruben+macports@…]

Cc Me!

[Serge3leo (Serguei E. Leontiev)]

Replying to david@…:

Suggest releasing a new Portfile removing no-asm for Mountain Lion. From the above comments, looks like this is already in the works.

Lion with Xcode 4.6 (OS X 10.7.4 or later) also failed with "no-asm" flag, see attachment lion-openssl-no-asm.log​.

May be, remove "no-asm" and create variant "+no-asm" for old Xcode users?

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #38041.

Replying to leo@…:

May be, remove "no-asm" and create variant "+no-asm" for old Xcode users?

I would prefer no variants be added. Can anyone confirm that old Xcode version (or rather: old clang or possibly llvm-gcc-4.2 versions) require no-asm? If so, what versions?

[aaron@…]

Cc Me!

[aaron@…]

Hi, what are we waiting for regarding the removal of the 'no-asm' option? Every person who has updated MacPorts in the last two weeks has broken their OpenSSL in this way. It's somewhat urgent to resolve.

[ryandesign (Ryan Carsten Schmidt)]

The no-asm build option in openssl has a bit of a history in MacPorts which is worth recounting:

• r2140: the openssl 0.9.7a port is created, with the no-asm option in place; no explanation is given, but it could be that OS X was still so new that the project's assembly code did not work on OS X.
• r90928: with openssl now at 1.0.1, no-asm is removed (i.e. asm is enabled) because "all tests pass on 10.7/x64".
• r91166: no-asm is reinstated (i.e. asm is disabled again) for OS X 10.5 and 10.6 only, because "'asm' only is tested on 10.7/x64"; asm remains enabled for 10.4, presumably erroneously. It's not clear whether Markus specifically knew of problems with asm on Leopard or Snow Leopard or whether he was just being cautious.
• r92126: openssl is updated to 1.0.1a and no-asm is reinstated globally "to make compile on 10.7/x64". I backdated my openssl port to r92126 and verified it built fine on Lion x86_64; then I edited the portfile and removed no-asm and verified that it did in fact fail to build.
• r92138: the platform darwin 9 and darwin 10 blocks that were added in r91166 are removed again since they are now redundant with the reinstated global no-asm option.

So asm has been off for most of the openssl port's life, and it was only briefly enabled for openssl version 1.0.1 only, and only for Lion, and then disabled when the next version of openssl didn't build with that option anymore. So if we want to enable asm now, we should do some thorough testing. Which is what I did, with the current version, 1.0.1e:

CPU	OS X	Xcode	Compiler	Compiler Version	Archs	Tests Pass		curl https://google.com works
						Before (no-asm)	After (asm)	Before (no-asm)	After (asm)
PowerPC G4	10.4.11	2.5	gcc-4.0	gcc version 4.0.1 (Apple Computer, Inc. build 5370)	ppc	yes	yes	yes	yes
	10.5.8	3.1.2	gcc-4.0	gcc version 4.0.1 (Apple Inc. build 5493)	ppc	yes	yes	yes	yes
Intel	10.5.8	3.1.2	gcc-4.0	gcc version 4.0.1 (Apple Inc. build 5493)	i386	yes	yes	yes	yes
					x86_64	yes	yes	yes	yes
Core 2 Duo	10.6.8	3.2.6	gcc-4.2		i386	yes	yes	yes	yes
					x86_64	yes	yes	yes	yes
	10.7.5	4.3.3	clang	Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn)	i386	yes	yes	yes	yes
					x86_64	yes	yes	yes	yes
	10.8.2	4.5.2	clang	Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)	i386	yes	yes	yes	yes
					x86_64	yes	yes	yes	yes
Core i7	10.8.2	4.6	clang	Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)	i386	yes	yes	yes	yes
					x86_64	no	yes	no	yes

Given these results I think it's safe to remove no-asm globally. Committed in r103461.

[aaron@…]

Thank you for the thorough tests and recounting of history!

[blair (Blair Zajac)]

Nice work Ryan!

[cooljeanius (Eric Gallager)]

Cc Me!