TL;DR : If you are a system administrator for infrastructure using X.509/PKI certificates, please check that your infrastructure doesn't depend on the following CA certificates to be trusted. Although their validity dates indicate they are still valid, they will be removed in upcoming software updates. If you depend on them, you are likely to experience failures. Talk to your CA and make sure you refresh affected certificates on your systems.


In order to avoid weak signing keys in the PKI trust infrastructure used by the global web, several CA certificates with weak 1024-bit keys have been removed by the maintainers of the Mozilla CA certificate list.

The current cleanup of 1024-bit keys affects the CA certificates with the following properties:

CN=Entrust.net Secure Server Certification Authority,OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),O=Entrust.net,C=US
SHA1 Fingerprint: 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39

E=info@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 1 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation Network
SHA1 Fingerprint: E5:DF:74:3C:B6:01:C4:9B:98:43:DC:AB:8C:E8:6A:81:10:9F:E4:8E

E=info@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 2 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation Network
SHA1 Fingerprint: 31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6

E=info@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 3 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation Network
SHA1 Fingerprint: 69:BD:8C:F4:9C:D3:00:FB:59:2E:17:93:CA:55:6A:F3:EC:AA:35:FB

These removals happened in version 2.1 (2014) of the CA certificates list, which has been published as part of the NSS release 3.16.3 and which has been amended in 3.16.4.

The upcoming Firefox 32 release, which is expected around September 2nd, 2014, will use this cleaned up list.

Since many other open source software packages or operating systems have chosen to use the Mozilla CA list as the base for global Internet trust, the list is widely distributed, and you should expect software updates with these removals. For example, this affects the ca-certificates package in the Fedora Linux distribution.

To analyze if you depend on the CA certificates listed above, for example, you could check which trust chain is presented when connecting to your server. For example, you could try to use a command like this to retrieve the certificates sent by the server:

$ openssl s_client -showcerts -connect kuix.de:443

Update 2
The output of the above command will display the issuer and subject names of all certificates sent by the server. If one of the issuer names matches with a name in the removal list, then you could be affected. The full check requires additional effort. It depends on your software, whether it will build a trust-chain to one of the removed CA certificates - which will fail after the removal. The names alone cannot tell, because replacement intermediate CA certificates might exist, with identical names, but different (good) properties.

When in doubt, check with your CA. Alternatively, you could configure a test system to no longer trust the removed CA certificates, and see if a connection (or a certificate validation) fails.

(In an earlier version of this blog post, I had suggested a check that doesn't work. It doesn't work to compare fingerprints of certificates sent by a server, with fingerprints shown in the list, because servers don't send the root CA certificate, but only intermediate CA certificates. I apologize for my earlier mistake in thinking.)
end of Update 2

If you find a certificate shown in the above list, then you should work with your CA to get a replacement certificate quickly, and update the configuration of your infrastructure. In some scenarios it may be sufficient to replace the intermediate CA certificate configured on a server, which allows clients to find an alternative chain of trust to a different server. Please ask your CA for details, if such an intermediate CA certificate is available, or if you must update to a refreshed server certificate (including the respective, different intermediate CA certificates).

As an example, several web sites have been found to still use an intermediate CA certificate with the following subject:

CN=USERTrust Legacy Secure Server CA,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US

which had been issued by the removed Entrust.net CA certificate. (Note that Entrust.net hasn't been removed completely, only an older certificate with a weak 1024-bit key.)

In order to limit the impact of the removal, this CA has issued a replacement intermediate CA certificate, which has been signed by another CA certificate with a stronger key. This intermediate certificate has been included in the Mozilla CA policy list, with neutral trust settings, intended as a helper certificate, that can allow software to find the path to a different trusted root.

However, only a limited number of software libraries performing X.509 certificate validation are able to make use of this helper certificate in their default configuration. For example, the NSS library will notice the replacement intermediate CA certificate being present in the certificate store, and because the replacement certificate has been configured by the CA to contain newer validity timestamps, it will be preferred by NSS, and the chain to another CA certificate with a stronger 2048-bit key will be found.

It seems that applications based on OpenSSL and GnuTLS typically don't use the replacement intermediate certificate, even if it's available in a certificate store during the validation. Therefore it's important to configure servers to send the correct intermediate CA certificate.

Note this is a first batch of removals of 1024-bit CA certificates. The Mozilla CA certificate list still contains entries with weak 1024-bit, and there are plans to remove them in future updates. If you'd like to learn more or discuss these changes, please refer to Mozilla's dev-security-policy discussions list.

Please help to distribute this information. Thank you.


UPDATE

While we have your attention, here is a list of additional weak 1024-bit CA certificates that are planned to be removed at a later time. If you depend on them, make sure you start to work with your CA to get them refreshed by your CA, too.

GTE CyberTrust Global Root, GTE CyberTrust Solutions, Inc., GTE Corporation, US
SHA1: 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74

Thawte Consulting cc, Certification Services Division, Thawte Server CA
SHA1 Fingerprint: 23:E5:94:94:51:95:F2:41:48:03:B4:D5:64:D2:A3:A3:F5:D8:8B:8C

Thawte Consulting cc, Certification Services Division, Thawte Premium Server CA
SHA1 Fingerprint: 62:7F:8D:78:27:65:63:99:D2:7D:7F:90:44:C9:FE:B3:F3:3E:FA:9A

VeriSign, Inc., VeriSign Trust Network, VeriSign Class 3 Public PCA – G2
SHA1 Fingerprint: 85:37:1C:A6:E5:50:14:3D:CE:28:03:47:1B:DE:3A:09:E8:F8:77:0F

Equifax Secure Inc., Equifax Secure eBusiness CA-1
SHA1 Fingerprint: DA:40:18:8B:91:89:A3:ED:EE:AE:DA:97:FE:2F:9D:F5:B7:D1:8A:41

Equifax Secure Certificate Authority, Equifax Secure CA
SHA1 Fingerprint: D2:32:09:AD:23:D3:14:23:21:74:E4:0D:7F:9D:62:13:97:86:63:3A

Equifax Secure Inc., Equifax Secure Global eBusiness CA-1
SHA1 Fingerprint: 7E:78:4A:10:1C:82:65:CC:2D:E1:F1:6D:47:B4:40:CA:D9:0A:19:45

I've started yet another project to solve "the right key" problem.

DetecTor is an open source project to implement client side SSL/TLS MITM detection, compromised CA detection and server impersonation detection, by making use of the Tor network.

In short, make use of the existing Tor network, perform multiple
connections to the destination server through multiple routes, check for consistency in the use of certificates, and either fail or proceed automatically, without user interaction.

The detailed description of the idea, including suggestions for the handling of edge cases, can be found at http://detector.io/

Looking forward to your feedback.

If your flight takes to you Frankfurt (FRA) airport and you've got a few hours to spend, you could do the following to make use of it do to some sightseeing:

Go to the regional train station below Terminal 1, take regional train S8 (S-Bahn), exit at Taunusanlage station.
Look at nearby Alte Oper from outside,
walk through FressGass which starts right next to it,
walk through Goethestraße,
then walk to nearby MainTower for a nice view from above,
the only skyscraper allowing visitors on top of the building
(airport-like security screening when entering).
http://www.maintower.de/hlb/generator/S ... er.en.html

Afterwards walk to Paulskirche, then Dom/Römer with its historical buildings and tourist souvenir shops, and you have the essentials covered.
You could continue to the nearby river Main, cross the Eiserner Steg pedestrian bridge, and head to the right for lots of museums and Schweizer Straße with traditional applewine restaurant Wagner http://www.apfelwein-wagner.com/

Have fun, Kai

Once you understand how Internet communications work on the technical level, it becomes obvious that spying is possible. As data flows between computer systems, anyone with full access to the involved computers can potentially read or copy all unprotected information.

For example, a criminal, working as an computer administrator at an Internet Service Provider company, could spy on customers, potentially reading corporate secrets that are exchanged by email, and could secretly sell such information to the customer's competitors.

There are many additional scenarios where it's reasonable to ensure that information remains protected against spying. And the most important scenario is that people have the right of privacy.

With the recent events we (apparently) have learned, that spying isn't limited to those with criminal intentions, but that spying is also performed by secret government agencies, justified as being necessary for providing security to the people.

At the very least, this (apparently) confirms what has been rumoured or anticipated.

However, it depends on the point of view, whether you call such spying legal or criminal. If you have two countries A and B, and each of them spies on the other one, then probably each of them calls their own activities legal, and describes the actions of the other country as criminal.

What happens if you're a citicen of country A, and both countries A and B are technically able to spy on you? Even if you decided that it might be acceptable for your own country to spy on you for the purposes of national safety, neither you nor your government might like the idea that your data is being accessed by country B.

This is one example why it makes sense to protect your information, making it either impossible or very difficult (and requring a targeted effort) to read your information, instead of allowing them to read your data with zero cost.

The above should show why it's in your own interest to invest resources into the protection of your data.

After the existence of the Prism and Tempora systems became known, it triggered the question, whether government agencies should be allowed to do it or not. That's a good question, and in my opinion, in democratic countries, a government should be obligated to inform its citicens about such operations, enabling the people to use their voting powers to acknowledge or resist such operations.

However, there are arguments why it might be irrelevant what the public decides. Even if country A decided that mass surveillance performed by country A is unacceptable, you still risk being spied on by country B. For example, an Internet Provider operator could be controlled by country B, but offering services in country A. Or country B has agents working at an Internet Provider in country A, that help to spy.

We can also look at it from another angle. I don't know how realistic the numbers are, but I've read that several hundert thousand people might have access to the data being processed by the Prism/Tempora systems. In my opinion, it's very likely that at least some of those people are foreign agents. As we have seen, people with high security clearance may become whistleblowers. Essentially, you don't know what people might do, regardless how many background checks you've made. It wouldn't surprise me if a few employees of such agencies secretly query the databases, on demand, selling the information to a different country. Since this action has a much lower risk for detection than becoming a whistleblower, I don't think we can rule out this possibility. I'd conclude, by spying in your own country, you enable foreign agents to benefit from the information, too.

In my opinion, because spying is technically possible, it won't be sufficient to implement laws that forbid it.

The only solution is to make spying impossible, or very difficult. And that's what all of us should be doing, by using encryption technology and, where encryption isn't possible, such as in places dedicated to sharing information with other's, at least following a strategy of data austerity, and only providing as much information as absolutely necessary (or deliberately considered harmless).

You might say, by encouraging people in country A to use encryption technology, you make it more difficult for the secret agency in country A to do their job. Well, I think that's exactly what we should do, and is acceptable, because more difficult doesn't mean impossible.

The state authorities will still have their classic ways of investigation. They still can secretly tap a suspect, for example by secretly entering an apartment and physically installing a keyboard logger on the target's computer system, installing video cameras, etc. However, because of the required effort and because of limited resources, very likely this will only be done to real suspects, not to every citizen.

Since individual people cannot control what the powerful agencies might do, their only chance is to protect themselves.

As a consequence, in my opinion, we should actively teach all Internet users how to use encryption enabled software, and how to avoid centralized service providers, and improve the software used by people, to make it more difficult for agencies or criminals to automatically spy on them.

The internal microphone on my Linux system didn't work. In order to enable it, I had to disable the driver for the internal analogue (classic) modem.

In order to check, if you might potentially be affected from the same issue, open a terminal, and run the following command:
* lsmod |grep snd_hda_codec_conexant

If the above command produces output, then your system has that particular Linux kernel module loaded, and might be blocking the internal microphone.

The solution is to prevent the system from loading the kernel module on startup. You can use the following commands:
* echo "blacklist snd_hda_codec_conexant" > /tmp/modem-blacklist.conf
* sudo cp /tmp/modem-blacklist.conf /etc/modprobe.d/

Now restart your computer and test if your microphone works.