Category Archives: Systems

Updated: Information about Heartbleed-bug in OpenSSL 1.0.1 up to 1.0.1f

Leave a reply

German version below

There is news about a bug in OpenSSL that may allow an attacker to leak arbitrary information from any process using OpenSSL.

Good news:

Certificates issued by CAcert are not broken and our central systems did not leak your keys.

Bad news:

Even then you may be affected.
Although your keys were not leaked by CAcert your keys on your own infrastructure systems might have been compromised if you were or are running a vulnerable version of OpenSSL.

To elaborate on this:

The central systems of CAcert and our root certificates are not affected by this issue. Regrettably some of our infrastructure systems were affected by the bug. We are working to fix them and already completed work for the most critical ones. If you logged into those systems, within the last two years, (see list below) you might be affected!
But unfortunately given the nature of this bug we have to assume that the certificates of our members may be affected, if they were used in an environment with a publically accessable OpenSSL connection (e.g. Apache webserver, mail server, Jabber-Server, …). The bug has been open in OpenSSL for two years – from December 2011 and was introduced in stable releases starting with OpenSSL 1.0.1.
When an attacker can reach a vulnerable service he can abuse the TLS heartbeat extension to retrieve arbitrary chunks of memory by exploiting a missing bounds check. This can lead to disclosure of your private keys, resident session keys and other key material as well as all volatile memory contents of the server process like passwords, transmitted user data (e.g. web content) as well as other potentially confidential information.
Exploiting this bug does not leave any noticeable traces, thus for any system which is (or has been) running a vulnerable version of OpenSSL you must assume that at least your used server keys are compromised and therefore must be replaced by newly generated ones. Simply renewing existing certificates is not sufficient! – Please generate NEW keys with at least 2048 bit RSA or stronger!
As mentioned above this bug can be used to leak passwords and thus you should consider changing your login credentials to potentially compromised systems as well as any other system where those credentials might have been used as soon as possible.
An (incomplete) list of commonly used software which include or link to OpenSSL can be found at related apps.

What to do?

  • First ensure that you upgrade your system to a fixed OpenSSL version (1.0.1g or above).
  • Only then create new keys for your certificates.
  • Check what services you have used that may have been affected within the last two years.
  • Wait until you think that those environments got fixed.
  • Then (and only then) change your credentials for those services. If you do it too early, i.e. before the sites got fixed, your data may be leaked, again. So be careful when you do this.

What we are doing:

  • We are updating the affected infrastructure systems and and create new certificates for them.
  • We use this opportunity to upgrade to 4096 bit RSA keys signed with SHA-512. The new fingerprints can be found below. 😉
  • We will contact all members, who had active server certificates within the last two years.
  • We will keep you updated, here.

Press release

CAcert-PM-Heartbleed-en

Update:

There is a website where one can check if a domain is affected:
http://filippo.io/Heartbleed/ (Use on your own risk)
We checked our systems against it, it looks like most of the systems we classified as affected are not actually affected. But we decided to update them, anyway and provide them with new certificates, as well.

Status of CAcert Infrastructure systems:

Not affected / Nicht betroffen:

  • main website (www.cacert.org)
  • certificate signer (the system doing the actual certificate issuing)
  • email system (inbound and outbound mail servers)

Fixed/Behoben:

blog.cacert.org
SHA1 Fingerprint=7A:13:19:98:1E:FB:9F:F9:9A:E6:3D:E5:7D:F0:42:E1:BE:56:B9:79
board.cacert.org
SHA1 Fingerprint=9B:30:44:3D:A8:8C:F5:5E:50:07:68:70:D6:A1:83:44:F9:7D:00:D6
bugs.cacert.org
SHA1 Fingerprint=E1:2C:12:7F:66:DF:2E:9D:F6:BC:FB:6F:BC:F1:2E:A0:10:5F:8E:BA
cats.cacert.org
SHA1 Fingerprint=2E:0B:08:6E:F1:48:FB:76:69:D6:6D:51:8F:E9:B3:2C:C3:4B:14:25
community.cacert.org
SHA1 Fingerprint=9B:8E:0A:68:96:E5:C8:E6:E6:8E:D8:10:31:3F:7C:2C:A8:4E:E1:3F
email.cacert.org
SHA1 Fingerprint=27:AB:9B:90:51:9B:BA:60:51:B3:84:54:FF:C7:09:94:63:86:68:FA
git.cacert.org
SHA1 Fingerprint=87:47:41:6D:C1:32:C7:22:00:E5:DA:E5:3C:4B:28:A2:2B:8A:F3:E4
irc.cacert.org
SHA1 Fingerprint=57:F4:0F:38:1E:53:D0:83:DC:D2:40:0A:13:98:B7:06:55:EA:A7:19
issue.cacert.org
SHA1 Fingerprint=82:33:D3:AE:32:56:C5:AD:9E:BF:D1:84:62:56:EA:95:31:7E:64:8C
lists.cacert.org
SHA1 Fingerprint=6A:AE:16:90:A2:1F:CC:1B:B7:93:71:C0:1B:BD:2E:14:68:69:45:EA
svn.cacert.org
SHA1 Fingerprint=D5:00:0A:15:17:04:2F:50:5B:09:3C:DD:B9:0A:57:DD:B3:BE:3D:B4
translations.cacert.org
SHA1 Fingerprint=B7:59:B9:BA:46:64:E2:D4:C8:73:20:50:45:9B:08:5E:2B:DF:D0:1B
wiki.cacert.org
SHA1 Fingerprint=87:07:59:30:30:64:27:15:6E:39:C3:66:09:CA:7A:90:7D:2F:32:32
cacert.eu
SHA1 Fingerprint=A2:7A:CB:E7:91:0A:ED:7E:63:9F:D1:97:01:96:E9:7B:F0:9E:43:3D

Affected/Betroffen:

  • Testserver-management-system (you should have not used correct data there)

Deutsche Fassung:
Ein Bug in OpenSSL wurde gefunden, der es einem Angreifer erlaubt beliebige Informationen jedes Prozesses zu erlangen, der OpenSSL nutzt.

Die gute Nachricht:

Die von CAcert ausgestellten Zertifikate sind nicht kaputt und unsere zentralen Systeme waren auch nicht angreifbar und hat keine Schlüssel verraten.

Die schlechte Nachricht:

Dennoch kann jeder betroffen sein!

Um ins Detail zu gehen:

Die zentralen Systeme und die Stammzertifikate von CAcert sind von diesem Problem nicht betroffen. Leider sind einige unserer Infrastruktur-Systeme durch den Fehler betroffen.
Wir arbeiten daran diese zu fixen und haben dies auch schon für die meisten erledigt. Jeder, der sich auf diese Systeme in den letzten zwei Jahre eingelogt hat kann betroffen sein!
Aufgrund der Art des Fehlers, müssen wir leider davon ausgehen, dass die Zertifikate unserer Mitglieder betroffen sind, wenn sie sich in eine Umgebung eingelogt haben, die über öffentliche OpenSSL-Verbindungen zugänglich war (z.B. Apache Webserver, Mail Server, Jaber-Server, …). Dieser Fehler war zwei Jahre lang in OpenSSL – seit Dezember 2011 – und kam beginnend mit Version 1.0.1 in die Stabilen Versionen.
Angreifer, die einen verwundbaren Service erreichen, können die TLS-Erweiterung “heartbeat” ausnutzen, um beliebige Abschnitte aus dem Speicher zu erlangen, indem sie eine fehlende Bereichsprüfung ausnutzen. Das kann zur Offenlegung von privaten Schlüsseln, im Speicher abgelegte Sitzungsschlüsseln, sonstige Schlüssel genauso wie jeglicher weiterer Speicherinhalt des Server-Prozesses wie Passwörter oder übermittelte Benutzerdaten (z.B. Webinhalte) oder andere vertrauliche Informationen führen.
Die Ausnutzung dieses Fehlers hinterlässt keine merklichen Spuren. Daher muss für jedes System, auf dem eine angreifbare Version von OpenSSL läuft (oder lief), angenommen werden, dass zumindest die verwendeten Server-Zertifikate kompromittiert sind und deswegen durch einen NEU generierte erstetzt werden müssen. Einfach die alten Zertifikate zu erneuern, reicht nicht aus! – Bitte NEUE Schlüssel mit 2048 Bit RSA oder stärker generieren!
Wie oben erwähnt kann dieser Fehler ausgenutzt werden, um Passwörter zu entwenden. Daher sollte jeder überlegen, alle Zugangsdaten zu möglicherweise betroffenen Systemen und allen Systemen bei denen diese sonst noch verwendet worden sein können, so bald wie möglich auszutauschen.
Eine (unvollständige) Liste an weit verbreiteter Software die OpenSSL verwendet kann z.B. unter folgendem Link gefunden werden.

Was ist zu tun?

  • Als erstes müssen die eigenen Systeme auf eine fehlerbereinigte Version von OpenSSL aktualisiert werden (Version 1.0.1g oder neuer).
  • Danach neue Schlüssel für die Zertifikate erstellen. Jetzt ist es sicher das zu tun.
  • Überprüfen, welche fremden Dienste in den letzten zwei Jahren besucht worden sind.
  • Warten, bis dort wahrscheinlich der Fehler behoben wurde.
  • Dann (und erst dann) die Logindaten für diese Dienste erneuern. Vorsicht: Wenn das zu früh getan wird, also wenn der Dienst noch nicht bereinigt wurde, können die Daten wieder abgegriffen werden.

Pressemitteilung

CAcert-PM-Heartbleed-de

Update:

Es gibt eine Webseite, bei der man seit kurzem checken kann, ob eine Domäne angreifbar sind:
http://filippo.io/Heartbleed/ (Benutzung auf eigene Gefahr)
Wir haben unsere Systeme dagegen geprüft und es sieht so aus, als wären nicht alle, die wir als potentiell angreifbar eingestuft haben tatsächlich angreifbar, aber wir haben uns dennoch dafür entschieden die entsprechenden Systeme aufzurüsten und die Zertifikate zu erneuern.

Was wir tun:

  • Wir arbeiten daran, alle Infrastruktur-Systeme auf den neuesten OpenSSL-Stand zu bringen und für diese neue Zertifikate zu generieren.
  • Wir nutzen diese Gelegenheit, um dabei auf 4096er-Schlüssel, die mit SHA-512 signiert sind aufzurüsten. Die neuen Fingerabdrücke können oben gefunden werden. 😉
  • Wir werden alle Mitglieder kontaktieren, die in den letzten zwei Jahren aktive Server-Zertifikate benutzt haben.
  • Wir werden neue Informationen an dieser Stelle veröffentlichen.

CAcert with high user gain and new server / CAcert mit hohem Benutzeranstieg und neuem Server

Leave a reply

[German version below]
The NSA scandal shows: Secure communication on the internet is highly
important for many! CAcert has nowadays a high number of new user
registrations: In 2013 we had about 27.500 new registrations and all year
long a much higher number of new members than in the years before.
Now in the first months of this year, we find even 100 new registrations
approx. per day.
This is the highest count of new members since founding of CAcert and
shows impressively that people desire secure communication and trust
CAcert as an independent certificate authority.
CAcert offers its services for free, because we believe that security must
be available charge-free. To be able to deliver our services quick,
especially the highly demanded ones like wiki, blog and translation system
amongst others, the german server hardware supplier Thomas Krenn has
donated us a new server as part of their open source sponsorship. This
server is now in place and ready to deliver the demands of our users.
CAcert-PM-User-Server-en
[German Version]
Der NSA-Skandal zeigt: Sichere Kommunikation im Internet ist für viele von großer Bedeutung! Das drückt sich auch in den Registrierungen neuer Benutzer bei CAcert aus: Bereits 2013 haben sich mit 27.500 Neuregistrierungen über das Jahr hinweg wesentlich mehr Benutzer registriert, als in den Vorjahren, sind es in den ersten Monaten dieses Jahres sogar im Durchschnitt 100 neue Nutzer täglich bei CAcert!
Das ist der höchste Benutzerzuwachs seit Bestehen von CAcert und zeigt eindrucksvoll, dass die Menschen sichere Kommunikation wünschen und gleichzeitig CAcert, als unabhängigen Zertifikatsanbieter, viel Vertrauen schenken.
CAcert bietet seine Dienstleistung kostenfrei an, denn unser Ansatz ist, dass Sicherheit kostenlos erhältlich sein muss. Um unsere Dienste, insbesondere die nutzungsstarken Systeme Wiki, Blog und das Übersetzungssystem, sowie einige weitere Dienste schnell und gleichzeitig energieeffizient anbieten zu können, hat uns der Serverhersteller Thomas Krenn im Rahmen seiner Open Source Förderung einen geeigneten Server zur Verfügung gestellt. Seit kurzem können die Anwender nun besonders schnell und ressourcenschonend Zertifikate für sichere digitale Kommunikation erstellen und einsetzen.
CAcert-PM-User-Server-de

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

1 Reply

[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

Infrastructure Services Moved to New Server

2 Replies

If you have used any infrastructure services (like wiki, blog, translation system, bug tracker) in the last days, you’ve probably noticed that they feel much more responsive. That’s because we have moved those services to a new machine, kindly donated by Thomas Krenn as part of their open source initiative. The donation actually took place some months ago, but we needed some time for preparation so that it’s finally online now. That was about time, because the old machine only had about 1.2 Gigabytes of storage left and those poor services were screaming for help.

Thank you Thomas Krenn for the hardware and also thanks to the admins, especially Jan Dittberner but also all other people involved, for preparing the move.

CAcert server move completed on December 12, 2013

4 Replies

The move of all existing CAcert servers  to a new smaller rack at the current hosting centre has completed, mostly successful, on December 12 at 23:00 UTC. All main services are available again now, but we still have some smaller problems to sort out, mostly due to the switch-over to a new much more compact firewall with a completely new architecture.

So please bear with us while we iron out the remaining problems, and feel free to report any issues you are still encountering.

Please join me in expressing thanks to the team that worked very hard over four hours after an already stressful day to get this major job completed: Stefan Kooman, Mendel Mobach, Martin Simons.

All CAcert services offline due to move on December 12, 2013

Leave a reply

On December 12 2013, we are planning to move all existing CAcert servers to a new smaller rack in the current hosting centre. In this new rack we will also have a new much more compact firewall installed, and a new energy-efficient infrastructure server.

All good news, but the downside is that all CAcert servers and services will be unavailable for a couple of hours. This outage will take place between 18:00 and 23:00 UTC on December 12, and of course we are striving to keep this downtime as short as possible,

In any case, critical services will be working again on leaving the hosting center, but in the case of unexpected complications, it is possible that non-critical services may only be restored the next day.

See also https://lists.cacert.org/wws/arc/cacert-sysadm/2013-12/msg00000.html for further details. We apologize for any inconvenience caused by this major but necessary operation.

Efficient method for frequent retrieval of CRLs

Leave a reply

Preferred protocol: OCSP

To verify the validity of a certificate issued by CAcert, the recommended method is to consult the OCSP responder running at ocsp.cacert.org. Many software packages have integrated support for the OCSP protocol, which is quite efficient in two ways:

  • very little data needs to be exchanged between client and server
  • the answer is always up-to-date because the server has the most recent Certificate Revocation List (CRL) on hand

Fall-back method: CRL

However, sometimes older software versions may lack working support for the OCSP protocol. But they often do have the ability to verify a given certificate against the Certificate Revocation List (CRL) published by the certificate issuer (CAcert in our case). For this to work, the client software requires a fairly recent copy of the CRL. Traditionally, such a copy can be obtained by an HTTP request for http://crl.cacert.org/revoke.crl and/or http://crl.cacert.org/class3-revoke.crl. Doing this regularly causes a lot of network traffic because the CRLs are quite large: revoke.crl is currently 5.6 MB, while class3-revoke.crl is 0.6 MB.

Improved fallback method: RSYNC

As of today a much more efficient method is available for maintaining a reasonably up-to-date local copy of the CAcert CRLs: the rsync protocol. After the initial retrieval of the full CRL, subsequent updates are orders of magnitude faster because only the small differences with the previous version need to be transmitted. The service can be used like this:

Initial setup:

$ mkdir crl-dir
$ rsync -avz crl.cacert.org::crl crl-dir

Regular update (e.g. via cron):

$ rsync -avz crl.cacert.org::crl crl-dir

Recommendation

Only if you cannot use OCSP and  really do need local up-to-date copies of CAcert’s CRLs, please consider the use of the rsync method outlined above. By saving bandwidth use on the crl.cacert.org server everybody benefits from better response times. Your cooperation is appreciated!

CAcert signing server service restored

Leave a reply

[29.08.2013 – 18:30] The operation of the CAcert signing server has been restored. It has been down from 28.08.2013 13:30 CEST until 29.08.2013 18:30 CEST.
By replacing a repeatedly failing primary disk drive, we expect that no more service outages will occur soon. All pending signing and revocation requests have been picked up and processed automatically after the restoration of the service this evening,