Category Archives: Systems

L’infrastructure de CAcert se prépare pour le futur

Samedi passé, le 13 juillet 2019, dans une opération coordonnée, les équipes Infrastructure et Interventions Critiques de CAcert ont mis à jour avec succès le système d’opération de notre infrastructure, localisée en Hollande. Le système repose désormais sur la version Buster de Debian, version déclarée stable la semaine passée par le projet Debian.

[this blog post is in French – for English, see here]

Déroulement de l’opération
Les équipes ont démarré leur travail ce matin vers 9:30 CEST et achevé toutes les mises à jour à 16:30 HAEC. Certaines de nos applications n’ont été rétablies qu’un peu plus tard. L’ensemble de nos systèmes est à présent revenu à son fonctionnement optimal.

Quelles améliorations en découlent?
La mise en service d’une version moderne du système d’exploitation, dont dépend toute notre infrastructure, garantit pour le futur un fonctionnement meilleur de nos applications:

  • La technologie de containers LXC est ainsi passée de la version quelque peu anti-diluvienne 0.8.0 pre-release à la version 3.0.3, qui offre désormais une API bien définie, une sécurité améliorée, et qui sera beaucoup plus facile à manipuler pour les administrateurs de nos applications.
  • Le pare-feu et la translation d’adresses devraient avoir été accélérés, par rapport à ce que parvenait à faire l’ancienne configuration iptables. Nous continuons à utiliser ferm comme wrapper, mais l’équipe Infrastructure de CAcert envisage déjà son remplacement par des règles nftables natives, qui offriront une analyse du trafic aussi sûre mais plus rapide.
  • On peut retrouver sur notre liste de discussion d’autres détails de cette importante mise à jour.

Le leader de l’équipe Infrastructure de CAcert, JanDD, a fait part de sa grande satisfaction d’avoir vu s’accomplir enfin cette mise à niveau cruciale, offrant une solidité accrue de nos services aux membres de notre communauté. Dans un commentaire publié en fin d’après-midi, il remerciait chaleureusement Wytze, leader de l’équipe des Interventions Critiques, pour l’apport de sa compétence tout au long de la journée.

Les bénévoles dont sont formées ces deux équipes ont ainsi délivré un travail en continu pendant 7 heures et demi aujourd’hui samedi, pour pérenniser nos systèmes. Joignez-vous à nous pour les en remercier et marquez votre soutien par un don à l’association [x]. Les dons collectés sont exclusivement destinés à couvrir le coût de notre infrastructure (hébergement des serveurs sur site sécurisé et consommation électrique). “Par ma contribution financière, j’encourage le travail de Jan et Wytze; c’est ma façon de leur dire merci”.

Si vous observiez un dysfonctionnement consécutif à cette récente mise-à-jour, n’hésitez pas à nous en faire part sur https://bugs.cacert.org/ (suivre les onglets “Infrastructure” >
“Infrastructure hosts”).

Si vous cherchez à rejoindre l’une de nos équipes techniques, abonnez-vous à la liste de discussion de nos développeurs, ou contactez directement notre secrétaire.

CAcert’s infrastructure ready for the future

On saturday, 13th of July 2019, in a joint operation, CAcert Infrastructure Team and CAcert Critical Team updated the operation system of CAcert’s infrastructure in the Netherlands sucessfully. The system is now running on the Debian Buster OS release that has been released by the Debian project last weekend.

Timing

The teams started this morning at around 9:30 CEST and finished the upgrades at 16:30 CEST, some of our applications turned back to service afterwards. The system is running smoothly now.

What is new?

The new OS release provides some features that are important for our infrastructure and will allow better operation of our applications in the future:

  • LXC has been upgraded from the somewhat primitive 0.8.0 pre-release to LXC 3.0.3 that has a proper API, better security and which will help application administrators
  • Firewalling/forwarding/NAT should now be faster then the old iptables setup. We still use ferm as a wrapper but the CAcert Infrastructure Team is already considering switching to native nftables rules that will provide a similar but faster rule set.
  • Further details about this major update can be read on our mailing list.

CAcert Infrastructure Team Lead JanDD is happy that we could finish this big upgrade and that we could implement all these changes for you. In a statement made on the early saturday evening, he thanked again to Wytze from CAcert Critical Team for his great support during the day.

The volunteers from these two teams worked for seven and a half hours today, Saturday, to keep our systems up to date. Join us in thanking them and donate now at your own discretion. Your donation will only be used to pay for the infrastructure (hosting, electricity in the data center). «I say thank you to Jan and Wytze and their team with a donation!»

If you find any issues that might be caused by the upgrade feel free to file bugs on https://bugs.cacert.org/ (at project Infrastructure > Infrastructue hosts).

If you want to join one of our teams, please join the development mailing list or write to the secretary.

Service interruption for a major system upgrade for a brighter future of CAcert on Sat, 13-07-2019

The CAcert Infrastructure Team will perform a major system upgrade of our infrastructure host tomorrow, 13th of July 2019, starting at 8am UTC/10am CEST. Wytze van der Raay of the critical infrastructure team will assist via remote console if necessary.

We expect the upgrade to run for at least 4 hours and some services might need fixes that will require even longer.

Most services will be unavailable at least for parts of the upgrade session. We will try to keep the downtime of essential services (email, emailout, lists, blog, wiki) as short as possible. We hope to not cause to many inconvenience but we cannot wait longer to perform these long needed update. The Debian Buster stable release last week and the recently acquired knowledge on how to use the remote console system of infra02 inspired us to perform the upgrade now.

Jan Dittberner
CAcert Infrastructure Team Lead

Please support the hudge work of the volunteers of our Infrastrucutre Team, please donate to continue to run this service. Thank you.

CAcert erneuert Stammzertifikate

CAcert hat endlich die Stamm- und Class 3-Zertifikate von der alten MD5-Kodierung auf die moderne SHA-256 aktualisiert. Ihre Browser werden uns wieder mögen! Die neuen Zertifikate wurden am 10. April an “den üblichen Orten” installiert. Sie können auf unsere Homepage https://www.cacert.org gehen, und auf der rechten Seite, drei Zeilen von oben, finden Sie “Root Certificates”. Der kurze Weg dorthin ist https://www.cacert.org/index.php?id=3.v

Wir möchten uns bei allen Mitgliedern des Softwareteams für die geleistete Arbeit bedanken. Alle Teams bestehen aus Freiwilligen. Wenn Sie die Arbeit des Software-Teams, einschließlich der Überprüfung, unterstützen möchten, spenden Sie bitte, um diesen Service weiter zu betreiben. Danke.

Stability of e-mail verification strongly improved

The e-mail verification on the CAcert web server has recently led to repeated support requests. An analysis of the log files in our data center showed that the corresponding error occurred more frequently. So we have to conclude that many CAcert users have been negatively affected. In order to avoid further negative effects, an emergency
patch was deemed necessary by the Critical System Administrator Team.

The standardised review and testing of the emergency patch implemented yesterday is carried out by the regular teams in the aftermath, which can result in a formal blessing for this patch or a request for additional code or configuration changes. We would like to thank the Critical System Administrator Team for their quick and decisive action. All teams consist of volunteers. If you want to support the work done by the Critical System Administration Team and the review by the Software Team, please donate, to continue to run this service. Thank you.

E-Mails signieren ist eine sichere Sache

Nach Angaben des deutschen Bundesamtes für Sicherheit in der Informationstechnik sind die von CAcert propagierten Methoden der digitalen Signatur und der E-Mail-Verschlüsselung eine sichere Sache – selbstverständlich bei korrekter Implementierung und Konfiguration.

Sicherheit von e-Mail Clients (Stand Sommer 2018)

Sicherheit von e-Mail Clients (Stand Sommer 2018)

Die nebenstehende Übersicht zeigt die Sicherheitsstufe der bekanntesten E-Mail-Clients. Aber was ist, wenn Ihr Korresponenzpartner eine Software mit einer roten Flagge verwendet? Kennen Sie denn die Software, die andere benutzen? Diese Fragen zeigen einmal mehr, wie wichtig das Vertrauen in der Kommunikation ist. Weitere Informationen über das Vertrauensnetz (Web of Trust) von CAcert.

Neben dem sorgfältigen Umgang mit dem geheim zu haltenden privaten Schlüssel kann auch die Sicherheit der verwendeten E-Mail-Programme und deren Konfiguration entscheidend.

  • Lassen Sie E-Mails im HTML-Format grundsätzlich nicht anzeigen oder generieren.
  • Insbesondere die Ausführung von aktiven Inhalten, d.h. die Anzeige von E-Mails im HTML-Format und das Nachladen von externen Inhalten, sollte ausgeschaltet werden.
  • Bietet ein E-Mail-Anbieter über die Einstellungen seiner Webmail-Anwendung die Möglichkeit dazu, sollten auch hier entsprechende Maßnahmen ergriffen werden.

Für sensible Informationen, die per E-Mail versendet werden müssen, kann das folgende Verfahren angewendet werden: Entschlüsseln Sie S/MIME- oder PGP-E-Mails in einer separaten Anwendung außerhalb Ihres E-Mail-Clients. Entschlüsseln Sie eingehende verschlüsselte E-Mails durch Kopieren und Einfügen des Chiffretextes in eine separate Anwendung, die die Entschlüsselung für Sie übernimmt. Auf diese Weise können die E-Mail-Clients keine Exfiltrationskanäle öffnen. Dies ist derzeit die sicherste Option mit dem Nachteil, dass der Prozess stärker involviert wird.

Auch Webmail ist sicher, wenn Sie Mailvelope oder PEP verwenden.

CAcert.org ist eine gemeinschaftsgeführte Zertifizierungsstelle, die kostenlos Zertifikate für die breite Öffentlichkeit ausstellt. Diese Zertifikate können verwendet werden, um E-Mails digital zu signieren und zu verschlüsseln, Benutzer zu authentifizieren und zu autorisieren, die sich mit Websites verbinden, und um die sichere Datenübertragung über das Internet zu gewährleisten. CAcert hat mehr als 360 000 Nutzer, wird von Freiwilligen betrieben und durch Spenden finanziert.

Spenden Sie die Kosten für 25 Zertifikate (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”

Updates for blog and bugs

We just updated some of our servers to the latest updates:

https://blog.cacert.org/ to the latest WordPress-release.

https://bugs.cacert.org/ to the latest mantis-release.

Furthermore the client certificate login on https://bugs.cacert.org was activated by today for Class-3 certificates. To login you have to enter your username or email-adress of your mantis-account.

Trying to login to https://bugs.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 you already have an account at https://bugs.cacert.org/ you may change the email-adress of your account to the first email-adress in your client-certificate.

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

If you try to use a Class-1-client certificate, you currently will may probably receive an error-message like “ERR_BAD_SSL_CLIENT_AUTH_CERT”. In this case please login without a client certificate or create a Class-3-certificate.

In case you face any issues don’t hesitate to contact us for help.

Kind regards,

dirk astrath (CAcert blog admin/CAcert software assessor)

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)

Successful Root-Re-Sign

On March 12th 2016 CAcert performed the Root Re-Signing at our data center in Ede, NL. After the initial attempt[1] had to be postponed on short notice.

The process followed the procedures that are available in the Wiki[2]/SVN[3] along with the tooling[4] used.

The re-signing was conducted by two CAcert critical administrators, a secure-u access engineer, and supervised by CAcert’s internal auditor.
Its execution has been announced on the cacert-systemlog mailing list[5]. The execution report by the critical team has been published there too[6]. The report of the auditor is published in our Wiki[7].

We want to send special thanks to all who helped in preparing and testing the procedures and tools for the process and thus made this smooth execution possible.

CAcert Inc. board tried to have the part for creation of the needed software to be held in public but was overruled by some of the involved teams.

As the re-signed root certificates are available to CAcert the next steps are to publish them to the public. This will need some time as the software team needs to prepare the code changes[8][9][10] and have them reviewed. Once this is done the publishing of the re-signed root certificates will be announced on the blog and all community members will get informed via e-mail.

[1] https://blog.cacert.org/2015/12/re-signing-root-certificate/
[2] https://wiki.cacert.org/Roots/Class1ResignProcedure
[3] https://svn.cacert.org/CAcert/SystemAdministration/signer/re-sign-2016/implementation.txt
[4] https://github.com/CAcertOrg/cacert-procedures/tree/root-resign-sha256/rootResignSHA256
[5] https://lists.cacert.org/wws/arc/cacert-systemlog/2016-03/msg00001.html
[6] https://lists.cacert.org/wws/arc/cacert-systemlog/2016-03/msg00002.html
[7] https://wiki.cacert.org/Audit/Results/session2016.1
[8] https://bugs.cacert.org/view.php?id=1305
[9] https://bugs.cacert.org/view.php?id=1254
[10] https://bugs.cacert.org/view.php?id=1194

CAcert fingerprints via DNSSEC

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