CAcert intends to disable SSL3 and 3DES support for its main website www.cacert.org by December 1, 2014.
The main CAcert website is currently still supporting the SSL3 protocol for secure connections. However, in https://www.openssl.org/~bodo/ssl-poodle.pdf it is shown that SSL3 is susceptible to certain cryptograhical attacks. While www.cacert.org does support the recommended TLS_FALLBACK_SCSV option to protect clients with that same protocol option against unintended downgrades to SSL3, this still leaves plain old SSL3 clients vulnerable for the new attack.
Similarly, www.cacert.org is currently still supporting the 3DES cipher suite for encyrpting secure connections. However, this provides only 112 bits of security, which is below the currently recommended number of 128. Hence we should disable it to protect CAcert’s clients.
In practice, the only client known to negotiate SSL3 with www.cacert.org is Internet Explorer 6.0 as found in Windows XP. Thus disabling SSL3 will block https access for these clients only. Similarly, 3DES will only be negotiated by IE 6 and IE 8 running on Windows XP. Since Windows XP is no longer supported by its vendor, and the widely circulated advice to all its users is to switch to a more recent operating system (or switch at least to a more current browser), announcing termination of support for SSL3 and 3DES by CAcert on December 1, 2014 does not seem unreasonable, and is fully in line with our mission to support the security of its users.
If you want to discuss this issue further, please use the bug tracker created for this issue (https://bugs.cacert.org/view.php?id=1314).
On July 23, the CAcert webdb server will be unavailable for most services from 10:00 CEST until approximately 11:30 CEST.
The reason for this is the need to convert the database from MyISAM format to InnoDB format, to address https://bugs.cacert.org/view.php?id=1172
We cannot predict exactly how long this conversion will last, but it is estimated to be less than 90 minutes. During this time, the server will remain up and running. The web frontend will also remain up and running, but with very limited functionality only (no user logins), due to the database being offline.
We apologize for any inconvenience caused by this major but necessary operation.
The CAcert OCSP and CRL services are temporarily unavailable due to a problem with our firewall, which cannot be fixed remotely. Therefore a site visit has been planned to remedy the problem.
The problem started on May 4 around 8:20 CEST, and will hopefully be fixed by May 6 around 15:30 CEST.
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.
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:
$ 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
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!