Category Archives: Systems

CAcert fingerprints via DNSSEC

Leave a reply

Recently we got several questions about automated installers for our certificates. While the new ca-cacert package in Debian Testing is a nice way for a verified installation it isn’t perfect. One issue is the initial download of the certificates when the source package is built by the maintainer; the second issue is that not everybody is using Debian.

As for a long time there was no way to automate the check of the trust anchor with tools you already have we used cryptography to make it work: DNSSEC. While you can’t directly download the certificates directly from DNS – the information would be to huge and hardly manageable – you still get enough information to bootstrap the verification from DNS. All you need is a way to query and validate TXT RRs from DNS, a way to download files via HTTP and a way to calculate some hashes.

The information about the fingerprints is stored in the DNS zone _fp.cacert.org – the underscore indicates non-host information. For each generation of root certificates a new sub-directory will be created. The current one is “g1”. To list all available certificates of a specific generation you can query the label _certs for that sub-directory given a DNS query for _certs.g1._fp.cacert.org yielding the two names “root class3” as the certificates. Each of those references in turn provides both an URL (“_url”) and a set of fingerprints (_md5, _sha1, _sha256) needed for the verified download of that certificate. To download the current (g1) root certificate you’d thus look for the download URL at _url.root.g1._fp.cacert.org and verify the SHA2-256 fingerprint given at _sha256.root.g1._fp.cacert.org. Fingerprints are always uppercase and without any delimiters.

For further technical details have a look into the Wiki [1]

[1] https://wiki.cacert.org/HowToDocuments/FingerprintsViaDNSSEC

Next language translated to 100%

Leave a reply

Special thanks to alaks who made Czech the sixth language which is now available with a 100% translation rate. In addition I want to thank all translators who did a tremendous work over the past years.

To show how far the various languages have been translated here a short statistic overview covering languages with more than 30% of progress

Language Progress
Spanish 100%
German 100%
French 100%
Italian 100%
Dutch 100%
Czech 100%
Portuguese (Brazil) 83%
Swedish 64%
Hungarian 43%
Finnish 37%
Japanese 36%

It would be great if even more people could be helping to translate the software. We are especially looking for Portuguese (Brazil), Swedish, Hungarian, Finnish, Japanese. Of course any help for the other languages that CAcert is offering is appreciated.

If you want to help just create an account on CAcert’s translation server
http://translations.cacert.org

For more information look at
https://wiki.cacert.org/Translations
or join the translation mailing list
https://lists.cacert.org/wws/info/cacert-translations

Thanks to all who already helped with the translation!

CAcert Community Agreement (CCA) Rollout finished

Leave a reply

[German Version below]
A long lasting software project – the CCA rollout – is nearing its end!

With today’s software update the last step for the CCA Rollout was deployed.

From now on every member who wants to use his CAcert account needs to have his CCA acceptance recorded.

The software has already been tracking this for some time which means that most active members will have their acceptance recorded by now. The CCA acceptance is recorded when:
– creating a new account
– entering an assurance for the assurer and the assuree
– creating a new certificate (client, server, GPG)

THE NEWS is that, for all users for whom no acceptance is yet recorded, a redirect to the CCA acceptance page is now forced. Once the CCA acceptance is recorded, this page will not be shown again.

Some historical facts:
The foundation was laid in 2007 by developing the policies and the CCA. The rollout started in 2009 by introducing the CCA to the community. In summer 2009 the acceptance of the CCA was required for creating a new account but it was not recorded.
In 2012 the acceptance of the CCA was required while entering an assurance but it was not recorded.
Starting from September 2013 the acceptance is recorded both on creating an account and while issuing a new certificate.
Since January 2014 the acceptance is recorded when entering an assurance too.
In September 2014 a new CCA was accepted by Policy Group.

[German Version]
Ein lange währendes Software-Projekt – der CCA-Rollout – nähert sich dem Ende!

Mit dem heutigen Software-Update wurde der letzte Schritt des CCA-Rollouts vollzogen.

Ab sofort wird für jedes Mitglied beim Login abgefragt, ob die Zustimmung zur CCA vorliegt. Falls nicht wird diese beim Anmelden erfragt und eingetragen.

Die Software zeichnet schon seit einiger Zeit bei diversen Aktionen die CCA-Zustimmung auf:
– Anlegen eines neuen Benutzerkontos
– Beim Eintragen einer Assurance sowohl für den Assurer und den Assuree
– Beim Erstellen eines neuen Zertifikats (Client, Server, GPG)

Wichtig: ab jetzt muss jeder User, dessen Zustimmung zur CCA noch nicht aufgezeichnet wurde, der CCA einmalig explizit zustimmen. Liegt bereits eine aufgezeichnete Zustimmung zur CCA vor, entfällt die explizite Aufforderung zur Zustimmung.

Einige historische Angaben:
Gestartet wurde das Projekt im Jahr 2007 mit dem Erstellen der Policy-Dokumente und der CCA. Das Rollout wurde 2009 mit der Veröffentlichung der CCA begonnen.
Ab dem Sommer 2009 wurde die Zustimmung zur CCA beim Anlegen eines neuen Kontos verpflichtend. Diese Zustimmung wurde allerdings nicht aufgezeichnet.
Seit 2012 wurde die Zustimmung zur CCA Bestandteil der Assurance. Diese Zustimmung wurde nicht in der Software aufgezeichnet.
Ab September 2013 wurde die Zustimmung zur CCA beim Anlegen eines neuen Kontos und bei der Erzeugung eines Zertifikats aufgezeichnet.
Seit Januar 2014 wird die Zustimmung auch beim Eintragen einer Assurance protokolliert.
Im September 2014 wurde eine neue Version der CCA durch die Policy Gruppe verabschiedet.

Disabling SSL3 and 3DES support to improve security for CAcert’s users

1 Reply

CAcert intends to disable SSL3 and 3DES support for its main website www.cacert.org by December 1, 2014.

The main CAcert website is currently still supporting the SSL3 protocol for secure connections. However, in https://www.openssl.org/~bodo/ssl-poodle.pdf  it is shown that SSL3 is susceptible to certain cryptograhical attacks. While www.cacert.org does support the recommended TLS_FALLBACK_SCSV option to protect clients with that same protocol option against unintended downgrades to SSL3, this still leaves plain old SSL3 clients vulnerable for the new attack.

Similarly, www.cacert.org is currently still supporting the 3DES cipher suite for encyrpting secure connections. However, this provides only 112 bits of security, which is below the currently recommended number of 128. Hence we should disable it to protect CAcert’s clients.

In practice, the only client known to negotiate SSL3 with www.cacert.org is Internet Explorer 6.0 as found in Windows XP. Thus disabling SSL3 will block https access for these clients only. Similarly, 3DES will only be negotiated by IE 6 and IE 8 running on Windows XP. Since Windows XP is no longer supported by its vendor, and the widely circulated advice to all its users is to switch to a more recent operating system (or switch at least to a more current browser), announcing termination of support for SSL3 and 3DES by CAcert on December 1, 2014 does not seem unreasonable, and is fully in line with our mission to support the security of its users.

If you want to discuss this issue further, please use the bug tracker created for this issue (https://bugs.cacert.org/view.php?id=1314).

Downtime for www.cacert.org on July 23, 2014

Leave a reply

On July 23, the CAcert webdb server will be unavailable for most services from 10:00 CEST until approximately 11:30 CEST.

The reason for this is the need to convert the database from MyISAM format to InnoDB format, to address https://bugs.cacert.org/view.php?id=1172

We cannot predict exactly how long this conversion will last, but it is estimated to be less than 90 minutes. During this time, the server will remain up and running. The web frontend will also remain up and running, but with very limited functionality only (no user logins), due to the database being offline.

We apologize for any inconvenience caused by this major but necessary operation.

Change when adding an assurance

Leave a reply

The software team pushed a new patch to production that has an impact on the way how new assurances have to be entered into the system.

Starting today, besides entering the primary email address further information has to be provided in order to gain access to assurance relevant data of the assuree. Additionally the date of birth of the assuree has to be stated by the assurer, before any data of the assuree is displayed for the assurance process.

This change was made for data protection reasons to ensure nobody is able gain access to personal data entrusted to CAcert by mere guessing of email addresses.

It hopefully will also reduce the number of problems with assurances that contain a wrong date of births.

Selection of hash algorithm during certificate creation

1 Reply

[German version below]
The software team recently released a patch which enables users to choose the hash algorithm used during the creation of a new certificate. Since the deprecation of SHA-1 earlier this year only certificates using SHA-512 for the signature could be issued. Now the available choices have been extended to SHA-256, SHA384 and SHA-512 where SHA-256 is the current default. Due to some organisational issues, the choice of SHA-384 will for now silently use SHA-512 instead.

The default hash algorithm has been selected as SHA-256 for compatibility with Debian systems using GNU TLS 2.12, which fails to operate correctly when a certificate signed with anything but SHA-256 has been used. This decision may be reviewed in the near future once the new Debian (Jessie) is released.

The move away from SHA-1 had to be made as the National Institute of Standards and Technology (NIST) disallowed certificates with SHA-1 algorithm issued after 2013-12-31 [1]. If your software still needs a SHA-1 signed certificate, get in contact with your vendor and request a software update, to cope with SHA-2 signatures. The use of SHA-1 had been deprecated since 2011.

N.B.: The software team still needs your help to test the remaining parts of the patch and get it released in a timely manner. The same is true for all our other patches that are waiting to be released. Feel free to drop by in the IRC channel or ask your questions on our mailing list.

[1] http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf;

[German]
Das Software-Team hat einen Patch herausgegeben, der es Nutzern erlaubt, die Stärke des bei der Erstellung des Zertifikates benutzten Hash-Algorithmus auszuwählen. Seit Anfang des Jahres ist die Nutzung von SHA-1 geächtet. Daher wurden die Zertifikate bisher mit SHA-512 ausgestellt. Jetzt stehen die Algorithmen SHA-256, SHA-384 und SHA-512 zur Auswahl, mit SHA-256 als Standardeinstellung. Aus organisatorischen Gründen, benutzt SHA-384 intern derzeit allerdings noch SHA-512.

Der Standard-Hash-Algorithmus wurde mit SHA-256 gewählt, um kompatibel mit Debian-Systemen zu sein, die noch GnuTLS 2.12 nutzen und Schwierigkeiten haben andere, als mit SHA-256 signierte Zertifikate zu verwenden. Diese Vorgabe wird überarbeitet werden, sobald das nächste Debian (Jessie) veröffentlicht wird.

Der Wechsel weg von SHA-1 wurde notwendig, da Zertifikate, die nach dem 2013-12-31 ausgestellt werden und SHA-1 nutzen, vom National Institute of Standards and Technology (NIST) als unsicher eingestuft werden [1]. Falls Ihre Software noch ein Zertifikat mit SHA-1 erfordert, fragen Sie bei dem Hersteller Ihrer Software nach, warum die Software noch nicht angepasst wurde, da SHA-1 bereits seit 2011 nicht mehr eingesetzt werden sollte.

P.S.: Das Software-Team benötigt weiterhin Unterstützung, um die verbleibenden Teile dieser Änderung zu testen, damit diese zeitnah freigegeben werden können. Das gleiche gilt auch für weitere Änderungen, die auf ihre Freigabe warten. Jeder ist eingeladen, sich in unserem IRC-Channel zu melden oder auf unserer Mailingliste seine Fragen loszuwerden.