Tag Archives: Software

Upcoming Changes for www.cacert.org

Today we switched the connection to our main website as a preparation for a “bigger” change. Unfortunately this (temporary) change is not IPv6-capable, so only IPv4 is working currently.

Over the weekend we plan to move www.cacert.org to another server for a more recent environment and add a second firewall to our rack. During this server-transition you may face some issues while using www.cacert.org, after the weekend the services should be normal again.

Early next week we’ll enable IPv6 again for our main website (maybe by using a new IPv6-Address, but that’s not yet decided).

All other services (like blog/wiki/bugs/…) should remain active as usual as there is currently no planned update.

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 renewed root certificates

CAcert has finally upgraded the Root and Class 3 certificates from the old MD5 encoding to the modern SHA-256. Your browsers will like us again! The new certificates were installed in “the usual places” on April 10th. You may go to our web site home page, https://www.cacert.org, and over on the right-hand side, three lines from the top, is “Root Certificates.” The short way to get there is https://www.cacert.org/index.php?id=3.

We would like to thank all software team members for the job they did. All teams consist of volunteers. If you want to support the work done by the Software Team, including the review, 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.

CAcert a renouvelé ses certificats racine

CAcert a finalement mis à jour les certificats Root et Class 3 de l’ancien encodage MD5 vers le moderne SHA-256. Vos navigateurs nous apprécieront à nouveau ! Les nouveaux certificats ont été installés dans “les lieux habituels” le 10 avril. Vous pouvez vous rendre sur la page d’accueil de notre site Web, https://www.cacert.org, et sur le côté droit, à trois lignes du haut, se trouve “Root Certificates”. Le chemin le plus court pour s’y rendre est https://www.cacert.org/index.php?id=3.v

Nous aimerions remercier tous les membres de l’équipe du logiciel pour le travail qu’ils ont fait. Toutes les équipes sont composées de bénévoles. Si vous souhaitez soutenir le travail effectué par l’équipe du logiciel, y compris la révision, veuillez faire un don pour continuer à faire fonctionner ce service. Merci.

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.

New CAcert for New Year

English | Deutsch | Français | Português

Don’t miss new functions, new possibilities and the new forward strategy of CAcert in 2019. In 2018 we started again support, software team and arbitration. Now, board and active members of the community are hard workng on the next steps. Support our volunteers by contributing to the running costs of our data centre in the Netherlands. More security, less phishing thanks to digital signature with free X.509 certificate.

Donate the costs of allmost one day (5€)                 Donate as much as you want                     Donate the running costs of one week (50€)                                                                                    IBAN DE50 2019 0003 0008 5478 07 “CAcert”

Verpassen Sie nicht neue Funktionen, neue Möglichkeiten und die neue Vorwärtsstrategie von CAcert im Jahr 2019. Im Jahr 2018 haben wir Support, Software-Team und Arbitration wieder aufgebaut. Jetzt arbeiten Vorstand und aktive Mitglieder der Gemeinschaft hart an den nächsten Schritten. 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”

Ne manquez pas les nouvelles fonctions, les nouvelles possibilités et la nouvelle stratégie d’avenir de CAcert en 2019. En 2018, nous avons recommencé le support, l’équipe logicielle et l’arbitrage. Aujourd’hui, le comité et les membres actifs de la communauté travaillent d’arrache-pied aux prochaines étapes. Soutenez nos bénévoles en contribuant aux frais de fonctionnement de notre centre de données aux Pays-Bas. Plus de sécurité, moins de phishing grâce à la signature numérique avec certificat X.509 gratuit.

Offrez-nous les coûts opérationnels d’une petite journée (5€)                                               Donnez un montant à votre volonté   Offrez-nous les coûts opérationnels de 1 semaine  (50€) IBAN DE50 2019 0003 0008 5478 07 “CAcert”

Não perca novas funções, novas possibilidades e a nova estratégia de avanço do CAcert em 2019. Em 2018 iniciamos novamente o suporte, a equipe de software e a arbitragem. Agora, a diretoria e membros ativos da comunidade estão trabalhando arduamente nos próximos passos. Apoie os nossos voluntários contribuindo para os custos de funcionamento do nosso centro de dados na Holanda. Mais segurança, menos phishing graças à assinatura digital com certificado X.509 gratuito.

 

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”

New Software: Modernising the Web Frontend

With today’s post we continue the blog series about our “New Software”.
1. Rewriting the software driving our site
2. Modernising the Web Frontend
3. The Heart of Gold
As outlined in the previous post there were quite a few things to decide upfront, which doesn’t make actual implementation any easier as we will see today when going into more details with the web front end. Beware of the details though as this (and the next part) are going to be much more technical.

Modernising the Web Frontend

With the last post New Software: Rewriting the software driving our site you got a glimpse of why we are rewriting our software. Today we’re going to elaborate a bit more on the front-end part and will provide more in-depth information on the technical changes and news to expect. The main aim of the rewrite is to strengthen the security and to improve maintainability of the source code. On the other hand we aim to avoid showing too much changes to our users.

With choosing Java as the language for the front end we are taking the advantage to develop a modular design based on Object Orientated Programming. This should help to get a better transparency of the source code, which the old PHP source both was lacking. In addition to these basic aspects the use of Java allows for easier packaging of the final application as well as for reworking the code when there is need to do so. This can be aided with several refactoring and code management tools available for Java as the general tooling support is quite good here. One such example is the nice integration of static analysis using tools such as FindBugs to automatically find issues that a static analysis of the code can find, e.g. null-pointer dereferences, misused APIs, thread safety issues, …

As a continuous integration process units test are introduced to test all new features directly while writing the source code. Our tool for this is Jenkins. The unit tests do not only cover the new applied features, the whole source code is tested as well, so that side effects can be discovered in an early stage of the development. Right now there are about 250 test cases running, with many more still to come.

Another important change is the separation from the source logic and the HTML output. While PHP encourages you to intermix HTML templates and executable source, it threatens you to bite you whenever you are not cautious enough. To make it harder to be careless we decided to reduce the power our templates have: The templates are reduced to simply printing values and very easy conditions and loops. An additional safety measure with the template engine is the implicit escaping that is caused for every string that should be printed – if you need to output preprocessed HTML to the template you have to explicitly state so in the template.
The HTML output is based on HTML5 and formatted with CSS3 using LESS to support responsive design patterns and accessibility. Additionally we completely switched to use Unicode, having UTF-8 as our standard encoding.

There is also a change in the URL structure. The new URL concept is based on REST and can easily be scaled to a RESTful API in the future. No more ?id=42 or other meaningless numeric IDs for the various actions.

To avoid SQL injections we opted to use implicit escaping for all data sent to or retrieved from the database; similar to the implicit escaping used with all inputs to the template engine. This way we can process raw data internally and have the necessary conversions and escaping operations whenever the context of the information changes allowing us to concentrate on the actual processing and logic instead of caring about the security implications.

Looking at security we invested some work in reworking the way authentication is handled. While the old system only supported password-based authentication and client certificate login using X.509 there was no chance of combining multiple factors as a requirement for successful login to an account. This lack of multi-factor authentication caused some trouble in the past. To avoid this and to provide more flexibility for our users we want to change the authentication to allow for any combination of login methods, as long as at least one “strong” authentication (like password login, secure token, client certificate) in addition to an optional “multi-factor” authenticator is provided (additional factors may be older TOTPs, single access tokens, ping tokens).

To raise the security level of the password storage we will use with SHA2-256 to store passwords in a save manner. This ensures an attacker can’t easily parallelise brute-forcing or attacking the password hashes as SCrypt guarantees through its design that an attacker needs a certain memory and amount of computational power to calculate the hash value. A switch to SCrypt-SHA2-512 or other even more secure methods later on is already laid out in the source code and can be activated transparently upon next successful password login of the user.

While discussing the authentication of the user let’s take a short break to look at some other security features the new system will implement. As one of the most critical parts with transmitting any information on a secure channel is getting the channel secured we’ll be activating HSTS or also known as HTTP Strict Transport Security. Using HSTS as a baseline we ensure that everyone visiting the site to access sensitive information can benefit of protection from eavesdroppers for future visits. Even if this brings no security on its own – except for mitigating SSL stripping attacks, it sets up the stage for the second mechanism: HPKP. Using Public Key Pinning we not only enforce browsers who had a once good, encrypted channel, to enforce encryption on subsequent visits (as HSTS does), but in addition also tell what valid keys for such a good connection are. Like with HSTS also HPKP suffers the issue of being inline to the connection and thus vulnerable to a determined attacker. With DNS-based Authentication of Named Entities (or for short: DANE) we introduce a second vector for verification a browser can use when determining acceptable security certificates. And even with these mechanisms deployed there is still a lot of room for determining if the connection is secure, some of which will sure follow in a later step.

But apart from ensuring the browser of the user talks to the correct server it is equally important to secure the display of information against mistakes our systems might be doing. One of the options we choose to implement was restricting ourselves using CSP (Content Security Policy) and a separation of our content delivery hosts. Basically to avoid an attacker executing any JavaScript not authorized we split execution of scripts to a subdomain which only carries static script files, while all content that might be under control of the attacker (e.g. the field containing the user name) is delivered on a strictly No-JavaScript subdomain. Thus even XSS was possible it would harden ourselves ill side-effects. To additionally avoid being framed (no pun intended) we will be including various HTTP headers like X-Frame-Options to explicitly prohibit loading within a frame on the attackers website. Also we ask the user’s browser to handle files in the way we specify which, among others, includes disabling of MIME type sniffing. With these security mechanisms in place it raises the bar for an attacker quite a lot and – on the other side – allows us self-testing the application as CSP allows for reporting violations on its rule set. Explicitly triggering such reports can even test the browser and thus determine the protection level the application can expect from the client (e.g. if images which are included for the sole purpose of triggering a report are loaded rather than ignored we know that the client does not properly implement CSP).

Another change will be introduced for the registration of domain names. In the future there are at least 2 ownership checks required to activate a new domain with our system. There will be a choice between the long known email pings, the verification with a DNS-TXT entry, verification with reading HTTP-content from a special addressed file and the verification with CAcert server certificates securely running on internet based services like HTTP, SMTP or XMPP. The way those tests were designed ensures that someone just observing traffic might notice the checks taking place, but won’t gain any information from such observations. All identifiers in these tests are chosen randomly thus simply searching for a particular filename or content of a file with an internet search engine won’t provide you any means to impersonate that domain.

In addition to the checks during the registration of a domain there will be continuous checks to check a domain is still active. If less then two tests succeed the account owner will be informed that there is a verification problem that should be solved within a grace period before all certificates containing that domain will be revoked automatically.

All posts send from the new software will be digitally signed using S/MIME to ensure that these messages are really generated by the CAcert systems and are not SPAM. This has been planned for a long time for the existing code but we did not manage to introduce it there due to complexity and security when realising this function in PHP.

One last but not least interesting feature to be mentioned is the rework of the certificate issuing process in the front end. While in the old software the process was to get all data from the database and check it against the values given in the CSR, this is turned around for the new software: Now first the given CSR is checked and the data gained from the CSR is checked against the records in the database to pre-fill the certificate request form. Changing the way the issuing works we were able to simplify the interface while allowing for new features to come.

After the discussion on why we choose our coding framework and today’s post about the ideas for the new front end the next post will have a closer look at the details of the ideas of the new signer.