Category Archives: Information

General news/information to the CAcert community or about security in general

CAcert applies to become “Interested Party” for the CA/Browser forum

Leave a reply

CAcert Inc. board decided with the motion m20140706.3 to apply at the CA/Browser forum [1] as “Interested Party”. The CA/Browser forum is responsible for the guidelines how to use X.509 certificates.

The reasons are:

  • get the latest ideas and hints how the the certificate business is developing
  • get the chance to show how CAcert Web of Trust works and that it might be an alternative for the commercial registry authority approach

CAcert nominated Benedikt Heintel as contact person to the CA/Browser forum.

[1] https://cabforum.org/

The policy group has started a new vote on “CCA – Update” (CAcert Community Agreement)

Leave a reply

CAcert-vote p20140709After a long period of inactivity on the policy side, we are back in
in business again.

In February board nominated a Policy Officer (Eva Stöwe) and this was later
confirmed by a Policy Group vote.

At about the same time an intensive discussion regarding changes to the CCA
started.

There are a lot of changes, some of them being just cleanups or
rephrasing, but there are also some bigger changes.

The central changes are:
– The CCA can be accepted by more ways than currently allowed.
– How CCA may be terminated was greatly rephrased, it now also covers
death of members.
– A clear obligation to answer truthfully before and to help arbitration
was added.

If you want to follow the discussion visit the archive on
https://lists.cacert.org/wws/arc/cacert-policy.

The actual version of the proposal is located here:
http://svn.cacert.org/!svn/bc/2568/CAcert/Policies/CAcertCommunityAgreement_20140708.html

Every community member is also invited to participate by joining the
policy group. Just subscribe the mailing list cacert-policy@lists.cacert.org

The state of the voting can be found at https://wiki.cacert.org/PolicyDecisions#p20140709

The voting stays open until Sunday 27th of July 2014.

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.

ATE-Wiesbaden, 22. Mai 2014

Leave a reply

Am Donnerstag, 22. Mai 2014 findet in den Räumen des CCCMZ e.V. in Wiesbaden das nächste ATE in der Region Rhein-Main statt.

  • Was hast du auf dem CAP Formular hinzuzufügen, wenn du Minderjährige überprüfst ?
  • Warum solltest du dir die 3 Buchstaben: R/L/O einprägen ?
  • Wie verhälst du dich, wenn du ein fremdes Ausweis Dokument zum ersten mal prüfst ?

Continue reading →

CAcert at LinuxTag 2014 in Berlin, Germany

Leave a reply

This years’ LinuxTag goes from may, 8th till 10th. Main topics this year are professional working with Linux and OpenSource, mobile devices and security. For the first time, it takes place in the STATION, quite in the center of Berlin at Gleisdreieck. Our booth is located in hall 6.

We’re pleased to talk to customers, to CAcert community members, Assurers and networkers for information exchange and knowledge transfer. And we’re liking to take the chance to talk about recent development at CAcert.

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 appoints internal auditor

Leave a reply

[German version below]

CAcert gets down to business to the next step for reopening the audit process and has appointed Benedikt Heintel as internal auditor in last december. The goal is the acceptance of CAcert as trustworthy certificate authority. Benedikt Heintel cares for the compliance of internal process flows with the rules and thereby for the reliability and trustworthiness of the CA overall. With the beginning of this year Benedikt Heintel has started with the first checks within the scope of the internal audit.
Quite a while ago CAcert has appointed co-auditors who check the quality of CAcerts’ web-of-trust with which identities of persons are verified. With this check co-auditors do the preliminary work for the internal auditor. These to different subject areas are the basis of CAcert and its secure certificates.

CAcert-PM-Internal-Auditor-en

[German version]

CAcert macht Ernst mit dem nächsten Schritt zur Wiederaufnahme des Audit-Verfahrens und hat im vergangenen Dezember Benedikt Heintel als internen Auditor ernannt. Ziel ist die Anerkennung von CAcert als vertrauenswürdige Zertifizierungsstelle. Benedikt Heintel kümmert sich um die Einhaltung sauberer Prozessabläufe bei CAcert und damit um die Vertrauenswürdigkeit der Arbeit der CA insgesamt. Anfang des Jahres hat er mit den ersten Überprüfungen im Rahmen des internen Audits begonnen.
Vor geraumer Zeit hatte CAcert bereits Co-Auditoren ernannt, die das CAcert-Web-of-Trust prüfen, mit dem die Identität von Personen sichergestellt wird und dem internen Auditor auf diese Weise zuarbeiten. Diese zwei unterschiedlichen Themen machen zusammen erst CAcert und seine sicheren Zertifikate aus.

CAcert-PM-Interner-Auditor-de

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