HEADS UP: OpenSSL 1.0.1_4 (1.0.1c), OpenVPN, and ipsec-tools, and others.

jimp

To upgrade ipsec-tools to 0.8.1, we had to pull in OpenSSL 1.0.1_4 (1.0.1c) from the FreeBSD ports repository.

Because many aspects of the system rely on OpenSSL, such as IPsec, OpenVPN, Certificate Management, GUI access, Backup encryption, Vouchers, etc. There could be some unexpected fallout from changing OpenSSL.

I have already fixed a few issues on the current snapshot, notably OpenVPN using the padlock engine and Certificate generation.

If you find something else has suddenly broken with OpenVPN or IPsec, or another encryption-related area that had been working in snaps before the change, let us know.

There are more fixes coming in the next snapshot that should be available later this evening, so if you find something before then, wait until after the next new snapshot to test again and report it broken.

OpenSSL 1.0.x is also supposed to contain better support for AES-NI, so it may help those who had been trying to use it but not seeing any real performance gains.
Additionally there is a new engine in it called "rsax" that supposedly improves speed on amd64 for 1024-bit RSA operations. Not sure if we'll really find much use for that though these days.

dhatz

I think you meant to say 1.0.1_4 from http://www.freshports.org/security/openssl/

There is no openssl 1.0.4 as far as I can tell from the openssl.org site, latest version is 1.0.1c (May-2012).

jimp

@dhatz:

I think you meant to say 1.0.1_4 from http://www.freshports.org/security/openssl/

There is no openssl 1.0.4 as far as I can tell from the openssl.org site, latest version is 1.0.1c (May-2012).

Yep, you're right.

marcelloc

getting this while trying to create an internal CA.

2.1-BETA1 (amd64)
built on Fri Jan 25 17:45:36 EST 2013

The following input errors were detected:

openssl library returns: error:0E064002:configuration file routines:CONF_load:system lib

jimp

Old snap. Already fixed on current snaps.

marcelloc

@jimp:

Old snap. Already fixed on current snaps.

I'll update it today, thank jimp! :)

2.1-BETA1 (i386)
built on Fri Feb 1 01:15:41 EST 2013
FreeBSD 8.3-RELEASE-p5

running on a Soekris 6501

-> Diagnostics: Execute command

$ /usr/bin/openssl version
OpenSSL 0.9.8q 2 Dec 2010

$ /usr/local/bin/openssl version
OpenSSL 1.0.1c 10 May 2012

I haven't fully tested but I have reason to believe that on my box Certs are still produced using old openssl 0.9.8q.
Since I assume that the goal is to completely replace 0.9.8 by 1.0.x the fact that both binaries are still around might be considered a problem and hence my post.

Regards
A.

jimp

It is neigh impossible to completely replace the base system OpenSSL without breaking things like ssh or requiring a lot of hoop-jumping on the builder.

They will both stick around. They coexist peacefully.

@jimp:

It is neigh impossible to completely replace the base system OpenSSL without breaking things like ssh or requiring a lot of hoop-jumping on the builder.

They will both stick around. They coexist peacefully.

ah, too bad, I thought that I would now finally be able to create an internal CA with validity > year 2038 on my i386 box :) Will have to do that on one of my amd64 debian machines then.

Thanks for clarifying.

jimp

Why can't you? All our certificate code uses the ports version of OpenSSL (1.0.1c)

Only FreeBSD programs in the base FreeBSD OS (not to be confused with pfSense's "base install") would use the old OpenSSL.

Whenever I create an internal CA with Lifetime 36500 and then test it on the pfsense box afterwards I get something like this:

/home/alex(3): /usr/local/bin/openssl x509 -in x.cert -noout -enddate
notAfter=Dec 2 14:44:37 1976 GMT

Since I'm using the 1.0.x binary to test I assume that something must have provoked the 2038 bug while creating the cert and that lead me to believe that openssl 0.9.8 was used for creation. I might completely overlook something here, since I'm not an expert with openssl and Certs…

php indeed uses OpenSSL 1.0.1c (see below) - which leaves at least the following options:

I'm doing something wrong
the year 2038 bug is still present in 1.0.1c on i386

I might come back to this at some point, but for now I'll just create my Certs on some other machine (which is a bit of a shame since the pfsense Cert Manager is one of the most comfortable tools I have seen when it comes to Certs)

/home/alex(64): php -i | grep OpenSSL
SSL Version OpenSSL/1.0.1c
OpenSSL support enabled
OpenSSL Library Version OpenSSL 1.0.1c 10 May 2012
OpenSSL Header Version OpenSSL 1.0.1c 10 May 2012

jimp

There is a third option and that is that the 2038 bug is present in PHP's OpenSSL interface code.
(Or, fourth, somewhere in between those layers…)

@jimp:

There is a third option and that is that the 2038 bug is present in PHP's OpenSSL interface code.
(Or, fourth, somewhere in between those layers…)

Seems that option three it is, from the php openssl library code:

/* {{{ proto resource openssl_csr_sign(mixed csr, mixed x509, mixed priv_key, long days [, array config_args [, long serial]])
Signs a cert with another CERT /
PHP_FUNCTION(openssl_csr_sign)
{
zval ** zcert = NULL, **zcsr, **zpkey, args = NULL;
long num_days;
…...
X509_gmtime_adj(X509_get_notAfter(new_cert), (long)606024*num_days);
......

Assuming that "sizeof(long) = 4" on i386 and "sizeof(long) = 8" on amd64 (as it usually is, if I remember correctly) the experienced behavior would be explainable.

Thanks for pointing me into the right direction - and now on to a 64-bit environment :)

msi

I'm not completely sure if this is related to OpenSSL too, I have issues with LDAPS authentication after upgrading:

Updated from: Mon Jan 28 16:55:26 EST 2013, Last commit: b0059636a9ccba5708152cb9548633e2f44c38d1
Checking the commit dates I'm positive this was a build must have contained OpenSSL 1.0.1c (1.0.1c was merged on 25th, but I wasn't able to check before updating.
Update to latest available snapshot: Thu Feb 7 18:03:44 EST 2013, last commit: dfac167caa70ca76dfee8101571eeedd0e034406, /usr/local/bin/openssl version says 1.0.1d

Issue:

Previously LDAP autentication (mainly used for admins) worked with and without SSL LDAP communication
When LDAP was unavailable I was able to fall back to local authentication
Now testing LDAP only works with plaintext LDAP communication (I had to viconfig the config.xm, and disable LDAP auth to break into the Web interface with local admin)l
It can bind with LDAP, but fails to fetch the OUs, previously this worked too
When LDAPS was enabled, local authentication on the Web-UI was not possible

We had to install a root certificate from our AD CA and have a certificate for the pfSense box issued from this CA. I'm positive that the certificates are fine since I tested it with pointing LDAP config to a CNAME of our DC and it failed since the certificate on the AD DC didn't contain it in its name (which BTW is well done guys since I know a couple of applications who just don't validate certificate data!)

While our AD/LDAP servers yet accept non-SSL LDAP communication, I'd consider it ugly to go back to non-SSL LDAP authentication (and I'm yet unsure if LDAP auth yet even works right now).
Can I provide you with some valuable debug data - is it even OpenSSL related, ?

jimp

I don't recall what handles that specifically, it may yet be openssl, or not. It should give some details/error in the system log though.

msi

Thanks Jim, hope to get more info after weekend. (better not completely break things before) ;-)

jimp

I wonder if it's related to this…
http://lists.freebsd.org/pipermail/freebsd-ports/2013-February/081259.html

They say 1.0.1e is coming soon because 1.0.1d was broken in various ways.

msi

Jim, concerning LDAP - the weird thing is that it can't get the LDAP OU even without SSL so I'm not sure whether it's only an OpenSSL issue.
But first I need to get onto a snapshot with fixed OpenSSL & working route addition (other thread) before I dare test LDAP again. ;-)

kejianshi

I was just sitting here thinking how important it be that my CAs be valid in 2038…
Because we all will be on the stuff we build today in 2038.

firewalluser

Dont know if this has been reported.

Trying to create a new Internal-CA
Key Length 4096
Hash SHA512
Days 3650
CountryCode: Mil

Fill in the rest of the fields and you will get this error message.
The following input errors were detected:

openssl library returns: error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too long

If you dont choose Mil you can create an internal CA.

FWIW.