Tag Archives: Certificate

Liebe Frau Merkel

Liebe Frau Merkel, liebe CDU, liebe SPD, liebe gehackten deutschen Politiker

Wie konnte das nur passieren mit diesem Datenklau im Dezember? Da hatten Sie doch die besten Services und die teuerste Software – und nun das! Das ist ärgerlich, in der Tat. Dabei müssen wir uns zwei Dinge bewusst sein:

  • Erstens: Weil eine Mehrheit der Wähler Ihnen das Vertrauen geschenkt hat, heißt das nicht zwingend, dass Sie in IT-Fragen den besseren Durchblick haben, als die Mehrheit der Wähler. Nur, wenn Herr Kreti oder Frau Pleti gehackt werden, interessiert das niemanden einen alten Hut, bei Ihnen kommt es groß in den Nachrichten und ist womöglich von strategischer Bedeutung.
  • Zweitens: Die großen Anbieter sind amerikanische Großfirmen, wie Microsoft, welche von ihrer Regierung verpflichtet sind, denen eine Hintertür offen zu lassen. Hintertüren sind jedoch immer Schwachstellen.

Die Alternative ist quelloffene Software. Fairerweise nicht einfach irgendwo heruntergeladen und gratis genutzt, sondern sowohl finanziell, als auch in der Weiterentwicklung unterstützt. Spielen wir einmal mit den Gedanken und stellen alle IT-Spezialisten des Bundes und der Länder einen haben Tag pro Woche frei, um an einem spezifischen Projekt mitzuentwickeln. Das können Standardanwendungen sein wie LibreOffice (statt Microsoft Office) oder dienstspezifische Spezialsoftware. Wer der Einfachheit halber – wie Ihre Kollegen in Bern – seine Verwaltung mit Skype telefonieren lässt, kann gerade so gut jedes e-Mail per CC an Donald Trump senden lassen.

Sie haben Recht, wenn Sie einwenden, dass quelloffene Software nicht per se sicherer ist, als kommerzielle Angebote; aber da die Quellen offen liegen, ist die Wahrscheinlichkeit wesentlich höher, dass Mängel entdeckt werden – vor allem auch, wenn Ihre besten Spezialisten regelmäßig danach suchen und wie oben skizziert Zeit haben, mit anderen Spezialisten sie dann umgehend zu beheben. Da sparen Sie nicht viel Geld, bekommen jedoch einen wesentlich höheren Mehrwert für die eingesetzten Steuergelder.

In einigen Schweizer Kantonen sind Clouddienste für Schulen aus Sicherheitsgründen verboten. Auch wenn wir keine Freund von Verboten sind, ist der Ansatz insofern bedenkenswert, den Mehrwert der ständigen Erreichbarkeit gegen die Sicherheit aufzuwiegen. Die Antwort wird ebenso unbequem sein, wie bei den Passwörtern: je einfacher, desto unsicherer (oder umgekehrt: Sicherheit kann man nicht aus dem Ärmel schütteln).

Freundliche Grüße vom anderen Ende des Erdballs

PS. Wenn Sie uns im Rahmen Ihrer Opensourcestrategie für eine gewisse Zeit einen Auditor und einen Programmierer abdetachieren, wird Ihre Regierung schon bald über die sichersten Zertifikate verfügen.

—-

Unterstützen Sie unsere Freiwilligen, indem Sie sich an den laufenden Kosten unseres Rechenzentrums in den Niederlanden beteiligen. Mehr Sicherheit, weniger Phishing dank digitaler Signatur mit kostenlosem X.509-Zertifikat.

Spenden Sie die Kosten für einen knappen 1 Tag (5€)      Spenden Sie einen freien Betrag          Spenden Sie die Betriebskosten des Rechenzentrums für 1 Woche (50€)                             IBAN DE50 2019 0003 0008 5478 07 “CAcert”

Certificate Login for CAcert wiki

Within the last days I ran some tests using the certificate login for https://wiki.cacert.org/.

This evening I activated this function on our wiki server.

Trying to login to https://wiki.cacert.org/ using an unknown email-adress will NOT create a new account: You have to create an account first using the email-adress, which is listed in your client certificate.

If the certificate-authentication fails (no matter, if you use no client certifcate, an expired one or a certificate, which does not match your email-adress) you can use the normal “classic” username/password-credentials to login.

While installing the client certificate login for CAcert wiki I updated the root-certificate there to the resigned one.

Kind regards,

Dirk Astrath (CAcert wiki admin)

Safer Internet Day 2016

On 2016-02-09 is this year’s Safer Internet Day[1] asking its participants to “Play your part for a better internet!”

The Safer Internet Day was first celebrated in 1999 to strengthen the awareness for security within and on the internet.

CAcert’s share in this effort is providing everybody the means to protect their communication by sending encrypted emails or using free client certificates for authentication.

So take a moment and think about taking part in one of the several events and help to promote email encryption with CAcert S/MIME certificates.

And stay safe on the internet!

[1] https://www.saferinternetday.org/

Selection of hash algorithm during certificate creation

[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.

Sichere E-Mails mit Zertifikaten von CAcert / Secure emails with certificates from CAcert

[English Version below]

Sicherer Mailverkehr ist zurzeit in aller Munde. Mittlerweile stehen mehrere kostenpflichtige Dienste zur Verfügung mit denen Anwender größtenteils pseudo-sichere oder bei einigen Angeboten teilweise auch sichere Mails versenden können.
Tatsächlich sichere E-Mails bedeutet den Einsatz von Ende-zu-Ende-Verschlüsselung, doch auch die kostenpflichtigen Anbieter bieten an dieser Stelle auch keine Hilfestellung für den Benutzer. Wichtig ist, dass die Verschlüsselung im E-Mail-Programm des Anwenders eingerichtet wird.
Übersehen wird dabei oft, dass Sicherheit kostenlos zu haben ist. Und dafür braucht auch kein neues E-Mail-Konto eingerichtet werden: Client-Zertifikate von CAcert integrieren sich nahtlos in alle gängigen E-Mail-Programme unter Windows, Mac und Linux.
PM-Sichere-Emails-de

[English Version]
Secure sending and receiving of email is currently highly demanded. There are a number of paid services nowadays offering pseudo-secure (which turns finally out to be non-secure) or sometimes even secure mails.
But secure mails actually mean end-to-end-encryption. But even services with costs are not able to support users at this point. Important is, that encryption is set up in the mail program of the user.
It is often overseen, that security is available for free. And it even works with the email provider of your choice: client certificates of CAcert integrate seamlessly into most well-known mail programs under windows, mac and linux.
PR-Secure-Emails-en

CAcert enforces rules for signing certificates / CAcert verschärft die Regeln beim Signieren von Zertifikaten

[German version below]

The software team released a patch which forces the user to use a key strength of at least 2048 bit for the certificate. The key strength is given by the CA/Browser forum baseline requirements [1].
During the test prior of the implementation it showed up, that keys using DSA with at least 2048 bit are not processed by the used OpenSSL configuration.
Since there is no easy way to verify the used key parameters for ECDSA are in conformance with the needed security level it has been decided not to support the singing of ECDSA keys until there is a proper solution.
Therefore no keys using DSA or ECDSA will currently be signed.
If a certificate is renewed and an error pointing to the key strength is given you need to create a new certificate with the apropriate key strength and method which is currently only RSA with at least 2048 bit key strength.

[German]
Das Software-Team hat einen Patch veröffentlicht, der den Anwender auffordert, bei der Erstellung eines neuen Zertifikats mindestens eine Schlüsselstärke von 2048 Bit zu verwenden. Diese Einschränkung beruht auf den Baseline Requirements des CA/Browser Forum [1].
Während des Testens vor der Auslieferung ist aufgefallen, dass mit der benutzten OpenSSL-Konfiguration DSA-Schlüssel mit einer Schlüsselstärke von mindestens 2048 Bit nicht korrekt signiert werden können.
Da ferner für ECDSA keine einfache Möglichkeit besteht, die verwendeten Schlüsselparameter auf das Sicherheitsniveau hin zu überprüfen, wurde entschieden, bis eine vertretbare Lösung gefunden ist, keine weiteren ECDSA-Schlüssel zu signieren.
Daher können bis auf weiteres keine DSA- und ECDSA-Schlüssel signiert werden.
Falls beim Erneuern eines Zertifikates ein Fehlerhinweis mit dem Thema nicht ausreichende Schlüsselstärke angezeigt wird, muss ein neuer Schlüssel mit der passenden Methode und Schlüsselstärke erzeugt werden. Zur Zeit sind das nur RSA Schlüssel mit mindestens 2048 Bit Schlüsselstärke.

[1] https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf

Members with Lavabit email accounts remember to change address

Lavabit has closed down its services as announced on Lavabit homepage, Silent Circle and maybe others have followed or will follow. Since CAcert requires members to be reachable by their primary email address we ask our members with Lavabit account to change their email address quickly. Just setup a second email address if you have not already done so and choose this to become the primary one. Do not delete your old email address because it will automatically revoke all your client certificates which contain this email address.