Suggested roadmap for updating OpenSSL on Fremantle
 

Here is a suggested roadmap for what we should do in order to properly use the newest OpenSSL (and related features) on Maemo Fremantle:
1.Get the latest OpenSSL (or LibreSSL) building and working properly on Fremantle (including all the newest algorithms and features and protocols as well as correct debian packaging, optimization flags etc for Fremantle)

2.Examine the OpenSSL 0.9.8n source code for Maemo (in the SDK repos) and identify any local patches vs upstream 0.9.8n and if those patches are actually necessary, forward-port them to the new OpenSSL version from #1 (or otherwise deal with them)

3.Put this new OpenSSL version into CSSU as "openssl", "libsslx.y.z", "libssl-dev" and "libsslx.y.z-dbg" (depending on the exact version we are porting or whatever)

4.Ensure that the root certificates in https://github.com/community-ssu/maemo-security-certman are up-to-date and match with what they should be for best security

5.Recompile/Port-to-new-OpenSSL-version/Put into CSSU maemo-security-certman, maemo-security-certman-applet, xorg-server, clinkc, loudmouth, microb-eal, sofia-sip, qt4-x11 and curl. (as well as anything else using OpenSSL that is FOSS and isn't present on a stock root filesystem). If bringing in a newer (but still ABI compatible) curl is easier, do that.

6.Update any security defaults or other things chosen by libcurl and libqt4-network so that they are only using things considered secure (e.g. dropping SSL2/SSL3/TLS1.0)

7.Identify any cases in the APIs where its possible for a user of libcurl or libqt4-network to specify security settings so we can audit for users of those functions and make sure nothing (especially closed source things) is doing anything insecure that should be updated.

8.Remove obsolete packages nokiamessaging and sharing-service-ovi (they are now useless and they use OpenSSL)

9.Audit the use of OpenSSL by as-daemon-0, tablet-browser-ui, osso-wlan-security, connui-iapsettings, adobe-flashplayer, location-proxy, osso-backup, ota-settings and signond0 and figure out which uses are a potential security risk and figure out what to do about those cases (e.g. cloning things)

This should cover all the things we need to do if we want the newest OpenSSL on Maemo Fremantle (and we want software to be using that new version)

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Xserver needs openssl only just for sha1 hash function which is used for hashmap of glyphs. See this Christ's sake email thread: http://lists.x.org/archives/xorg-dev...ne/042757.html

Xserver can be recompiled with other libs for sha1 support (instead openssl). Maybe we should choose different lib now?

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Or revert that commit in xserver which removed internal sha1 implementation as written in: http://lists.x.org/archives/xorg-dev...ne/042774.html

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

TLS1.0 is still quite secure, please do not drop it as many server will need it.

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

+ add sha256 support?

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Ok, I wasn't sure if the current recommendation was to switch off TLS1.0 or not.

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

NIST (And PCI-SSC) certainly disagrees on that statement.

http://nvlpubs.nist.gov/nistpubs/Spe...P.800-52r1.pdf

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

afaik gmail still offers SSL only?
At least that was a few months ago.

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Anyone know where I can get source code to debian OpenSSL 0.9.8n-1 (the version Maemo Fremantle OpenSSL is based on)? If I can get that, I can do a diff between the 2 and see whats new in Maemo Fremantle that might need to be forward ported to whatever OpenSSL/LibreSSL version we end up taking (which IMO should probably be whatever Debian ships these days)

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Google still offers ssl3 on its sites because of backwards compatibility (i.e. many people using ancient versions of Intercrap Exploder that either don't support TLS at all or have it off-by-default for some stupid reason)

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Hi there,

I've managed to download debian's sid latest openssl (1.0.2e) and have backported its debian/ directory so this package now builds on scratchbox. I've succesfully installed generated libssl1.0.2 .deb package on N900 and it passes the tests openssl includes. Note that these tests result in a segmentation fault when run on scratchbox, it's probably a fault of qemu.

So we've got now a really good start.

Changes I've made are available on https://github.com/agamez/maemo-openssl-1.0.2 This work is not finished but it's a start.

I've found original openssl 0.9.8n-1 source used by debian on top of which maemo built its own library here https://launchpad.net/debian/+source/openssl/0.9.8n-1 so we can check which differences are between what is on maemo and upstream.

Best regards!

EDIT: I can't see any relevant difference between debian's original source code and that on maemo (apt-get source openssl=different_versions_on_repos...). I am almost completely sure that the only differences are in packaging, but there are no new patches. For a library like openssl that would be, in fact, a very very bad idea, so even if there are some differences, changes are they are for bad instead of for benefit of the security of the system.

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

I have taken Debian OpenSSL 0.9.8n-1 source from http://snapshot.debian.org/package/openssl/0.9.8n-1/ and Maemo OpenSSL 0.9.8n-1+maemo4+0m5 source from http://repository.maemo.org/pool/mae...ree/o/openssl/. I have renamed the patches in the Debian source to match the names in the Maemo source.

The diff of the resulting folders is attached to this post:

The following changes exist in the Maemo tree vs the Debian tree:
1.Change PERL path in Configure
2.Remove Makefile (its automatically generated from Makefile.org)
3.Change PERL path in a bunch of PERL scripts
4.Remove apps/CA.pl (its automatically generated from apps/CA.pl.in)
5.Add a commented out #ifdef to crypto/ec/ectest.c
6.Comment out an #ifdef in crypto/o_init.c
7.Remove crypto/opensslconf.h and its symlink include/openssl/opensslconf.h (its automatically generated from crypto/opensslconf.h.in)
8.Added various entries to debian/changelog
9.Changed debian/compat from 3 to 5
10.Added a debian/debian.tar.gz file containing an unknown changelog/compat/rules file
11.Change debian/libssl0.9.8.postinst to use sh instead of bash
12.Add headers to various patches
13.Rename the patches (and add an 00list file instead of the series file)
14.Add a new patch 20_load-cert.dpatch
15.Add a new patch 21_configure-cflags.dpatch
16.Add a new patch 22_openssl-psk-0.9.8n-lib.dpatch
17.Add a new patch 23_openssl-psk-0.9.8n-test.dpatch
18.Add a new patch 24_openssl-psk-0.9.8n-doc.dpatch
20.Remove patch kfreebsd-pipe.patch
21.Remove patch rc4-amd64.patch
22.Add lines to debian/rules for include /usr/share/dpatch/dpatch.make, build: patch-stamp build-stamp and clean: unpatch
23.Add include/openssl/cms.h symlink to crypto/cms/cms.h
24.Add include/openssl/jpake.h symlink to crypto/jpake/jpake.h
25.Add a commented out #ifdef to test/ectest.c
26.Make a bunch of changes to test/jpaketest.c
27.Remove tools/c_rehash (its automatically generated from tools/c_rehash.in)

Now we need to figure out the following:
1.Whether any of the above changes (the 5 Nokia patches or the changes made directly to the source code) are still necessary for our OpenSSL 1.0.2e port
2.Whether there is anything removed from OpenSSL (stock or Debian) between 0.9.8n and 1.0.2e that we need on Maemo
and 3.Whether there is anything added to OpenSSL (stock or Debian) between 0.9.8n and 1.0.2e that we dont need on Maemo (i.e. that we need to remove for Maemo)

I suspect there is likely to be nothing satisfying #2 and #3 above (and that its not even worth looking)

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Is this of any use to you: http://abi-laboratory.pro/tracker/timeline/openssl/

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

This looks like Nokia forked at Debian version 0.9.8g-10 and then merged at 0.9.8g-13, 0.9.8g-15 and 0.9.8n-1.

Are there older Nokia versions available anywhere?
(Edit: I see openssl_0.9.8g-15maemo4 in the maemo5.0 pool, it might be worth examining a diff there too)

Could be a mistake in the Debian packaging. I think this should have been bumped when converting to source format 3.0 (quilt).

Could be a mistake in the Nokia packaging.

This looks like Debian converted to source format 3.0 (quilt) after the fork and then Nokia reverted to source format 1.0 for the merge.

The Maemo builders have been able to cope with source format 3.0 (quilt) for some years now.

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Debian converted to source format 3.0 (quilt) in 0.9.8m-1:
I can't see any explicit mention of bumping the compat level to 5, only a bump to level 9 in 2013:

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

This one really seems to be maemo specific, but I'm not even sure it's relevant in Maemo5, since I can't find libcst on my device (or in SDK).
See http://maemo-developers.maemo.narkiv...libcst-sources for more info on libcst.

If it tries to dlopen (!) a library that is no longer available, I think we can safely drop it...

Those have been upstreamed.
See openssl commit ddac1974 and openssl-1.0.0 release changelog.

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

libcst was renamed to libmaemosec, see:

https://github.com/community-ssu/mae...ddc9521c847ced

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Ah, thanks.
Looks like they didn't bother updating the openssl package though... and I don't see how this dlopen() could work the way it is :)

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Looks like that function is not in fremantle version. Something from diablo or bora. I suggest to drop that patch.

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Going over the list of differences between Maemo and Debian, I think we can ignore #2, #4, #7 and #27 since they just remove things that get autogenerated by the build process.
We can ignore #20 and #21 also as those 2 patches only touch things related to x86_64.
We can ignore #16, #17 and #18 because they are already in the latest OpenSSL
We can ignore #12 and #13 and #22 because they are just changing the patch format
We can ignore #10 since its clearly never used in building the Maemo OpenSSL
We can ignore #6 since its just adding changelog entries
We can ignore #14 since its looking for a library that doesn't exist (and also I doubt any file with the right filename is going to get passed to X509_load_cert_file or X509_load_cert_crl_file)
We can probably ignore #9 (in that whatever we need to set debian/config to in the new OpenSSL will be whatever we need to set it to and what the old code does doesn't matter)

No idea about the CRYPTO_MDEBUG stuff (#5, #6 & #25), the PERL changes (#1 and #3), the postinst change (#11), the cflags patch (#15), the include symlinks (#23 and #24) or the jpaketest.c changes (#25)

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Ok so we need someone who knows how the maemo-security-certman stuff works to take a look at http://mxr.mozilla.org/nss/source/li...s/certdata.txt (mozilla root certificate list) and figure out what needs to be done to the root CAs in https://github.com/community-ssu/maemo-security-certman

I dont know how the maemo-security-certman certificate stuff works otherwise I would give this a go myself :)

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

List of things that link to (but may not actually call) the maemosec libs: (this relates to the discussion earlier in IRC about certificate stuff). Not counting maemosec-certman-tools in this list.

libmaemosec.so.0:
as-daemon (as-daemon-0, closed source)
browser.launch (tablet-browser-ui, closed source)
eapd (osso-wlan-security, closed source)
libconnui_iapsettings.so.0.0.0 (connui-iapsettings, closed source)
libiap_dialog_gtc_challenge.so (connui-conndlgs-wlan, open source)
libiap_dialog_mschap_change.so (connui-conndlgs-wlan, closed source)
libiap_dialog_private_key_pw.so (connui-conndlgs-wlan, open source)
libiap_dialog_server_cert.so (connui-conndlgs-wlan, open source)
libiap_dialog_wps.so (connui-conndlgs-wlan, closed source)
libiap_wizard_wlan.so (connui-iapsettings-wlan, closed source)
libinternetsettings.so (connui-iapsettings, closed source)
location-proxy (location-proxy, closed source)

libmaemosec_certman.so.0:
as-daemon (as-daemon-0, closed source)
browser.launch (tablet-browser-ui, closed source)
eapd (osso-wlan-security, closed source)
libconnui_iapsettings.so.0.0.0 (connui-iapsettings, closed source)
libiap_dialog_gtc_challenge.so (connui-conndlgs-wlan, open source)
libiap_dialog_mschap_change.so (connui-conndlgs-wlan, closed source)
libiap_dialog_private_key_pw.so (connui-conndlgs-wlan, open source)
libiap_dialog_server_cert.so (connui-conndlgs-wlan, open source)
libiap_dialog_wps.so (connui-conndlgs-wlan, closed source)
libiap_wizard_wlan.so (connui-iapsettings-wlan, closed source)
libinternetsettings.so (connui-iapsettings, closed source)
location-proxy (location-proxy, closed source)

libmaemosec_certman_dialogs.so.0:
browser.launch (tablet-browser-ui, closed source)
libconnui_iapsettings.so.0.0.0 (connui-iapsettings, closed source)
libiap_dialog_gtc_challenge.so (connui-conndlgs-wlan, open source)
libiap_dialog_mschap_change.so (connui-conndlgs-wlan, closed source)
libiap_dialog_private_key_pw.so (connui-conndlgs-wlan, open source)
libiap_dialog_server_cert.so (connui-conndlgs-wlan, open source)
libiap_dialog_wps.so (connui-conndlgs-wlan, closed source)
libiap_wizard_wlan.so (connui-iapsettings-wlan, closed source)
libinternetsettings.so (connui-iapsettings, closed source)

As for NSS, libmaemosec-certman0 postinst diverts libnssckbi.so (normally part of NSS source tree) and replaces it with a symlink to libmaemosec_certman.so.0. The only user of libnssckbi.so is libnss3.so.

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Looks like the source for the ca-certificates package from debian contains python script to convert mozilla certificates file to the format we need (certdata2pem.py) so that should make things easier.

The last commit from anyone Nokia (the Nov 27 2011 commit) matches the Mozilla NSS certificates file as of mozilla-central changeset 2432457fa32b

Does anyone know where the filenames for the certificates (e.g. 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem) come from? What is that string of numbers?

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

It's the x509 Subject Key Identifier, which AFAIK, is a way to identify the public key of the certificate.

openssl x509 -in <cert.pem> -text -noout

will show you that information (and a bunch more).

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

Ok, my suggestion for how to proceed with updating the certificates is as follows:
1.Take certdata2pem.py from the debian ca-certificates package
2.Modify certdata2pem.py so it spits out files named as required for maemo (creating files in either the blacklist and common-ca directories as appropriate as well as adding the certificates to certman.blacklist and certman.common-ca files via cmcli)
3.Run the result on the certdata.txt as of mozilla-central commit 2432457fa32b (which should match the fc21ae95be7f44189be2360d445f4fe3f10ab712 commit in maemo-security-certman)
4.Make sure the output matches the fc21ae95be7f44189be2360d445f4fe3f10ab712 commit in maemo-security-certman (this will verify that there are no special certs in there that Maemo has but Mozilla does not as well as verifying that we get the expected output from the modified python script)
5.Run the script on the latest certdata.txt from Mozilla.
6.If step 4 showed any special certificates that are only found in Maemo (or for that matter, any certificates Mozilla no longer trusts but that Maemo needs to trust for some reason), add those manually
7.Verify that it correctly blacklisted the certificates from maemo-security-certman 0be038825a98dae2d80fd411a02cb4c86ed1b36a and correctly ordered the certificates from maemo-security-certman 2cbd96e89d7529e1ce25801824fb76f39b05b836
8.Stick all the results into Git and the new maemo-security-certman into CSSU
and 9.Stick the tools and notes into Git somewhere so we can keep maemo-security-certman up to date with the latest Mozilla certs going forward

I would do this except I dont know the first thing about Python...

Or of course we can try and track down Juhani Mäkelä and ask him to share whatever tools and tricks he used to update the certificates :P

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

I was able to track down Juhani Mäkelä (original Nokia developer for maemo-security-certman) who sent me a parse-certdata-txt.c file that parses the Mozilla certdata.txt file. Now I am waiting to see if he can help me with the exact steps to take the output of parse-certdata-txt and get it into the right place in the maemosec-certman-common-ca package.

So it looks like there should be no problem getting the latest set of root CAs into CSSU

Re: Suggested roadmap for updating OpenSSL on Fremantle
 

In future you can use http://deriv.debian.net/Maemo/patches/ website. E.g. here is debian diff for openssl: http://deriv.debian.net/Maemo/patches/o/openssl/