Should we implement a CA-Knockout Add-On? 
Tuesday, September 6, 2011, 04:39 PM
Posted by Administrator
I consider to implement a Mozilla Firefox/Thunderbird/SeaMonkey Add-On with the following functionality.
I'm striving for something that I (or we) could implement within a minimum amount of time, like 24-48 hours.

(1) it embeds my personal Code Signing certificate ("cert pinning").

(2) it (daily) pings a given URL, e.g.

The URL delivers plain text data, 3 rows.
- line 1: version number 1
- line 2: the number of the most recent knockout certificate (a steadily increasing number starting with 1)
- line 3: a base64 encoded signature, which signs the text contained in line 2

(3) the Add-On keeps track of the most recently download knockout certificate

(4) if the signature of the most recent knockout number is confirmed, then the addon will download all missing knockout certs
Let's say, the addon had previously downloaded knockout number 1, and the server now says latest knockout is number 3.
Then the Add-On will download the following URLs:

In particular we can use prefs like "most-recent-known-knockout-number"
and "most-recent-imported-knockout".

(5) Retry downloading each of them in order, until successful and until
most-recent-known-knockout-number equals most-recent-imported-knockout.

(6) the contents of the knockout files like 2.txt is plain text data, 3 rows:
- line 1: version number 1
- line 2: the knockout number (e.g. 2), a single space, and a base64 encoded certificate that should be marked as not trusted
- line 3: a base64 encoded signature, which signs the text contained in line 2

(7) import each knockout certificate that can be verified

(8) Add another feature to the Add-On - allow users to import the files like 2.txt and 3.txt directly, e.g. by copying the text into a dialog. With this feature, if a user is in an environment that blocks connections to host - then users could obtain the knockout instructions via other channels, such as email from friends, or any other source.

(9) make Add-On available and suggest that users install it

view entry ( 3892 views )   |  permalink   |  $star_image$star_image$star_image$star_image$star_image ( 3 / 4377 )

NSS changes to address the DigiNotar incident 
Monday, September 5, 2011, 06:28 PM
Posted by Administrator
Last week I helped to get the DigiNotar incident addressed in Mozilla's applications, and also in the NSS library. Today I was asked to explain in detail what we did inside NSS. Thanks a lot to Gervase Markham who helped as an editor of the following text.

This is an interim statement, and represents the personal understanding of me, Kai Engert. It has not been reviewed by other members of the NSS team. If necessary, a checked version of this message will be provided after the US/Canada public holiday. However, I have been involved in creating the patches that we used to address the DigiNotar incident.

The NSS team has issued a new version of the NSS module that contains
trust information for CA certificates, NSSCKBI version 1.87. We believe it removes all trust in the DigiNotar root and in all known
cross-certificates and in the DigiNotar-controlled intermediates in the Staat der Nederlanden hierarchy. We have shipped a new release of NSS, containing the same code as the previous release and the updated trust store. It can be found here:

I have been asked about the NSS crypto library. Because of this, I will skip what has been added at the application level in Mozilla's products (on top of NSS).

Note that the NSS library consists of several modules, which use their own sub-version numbers. For example, NSS contains a binary module that embeds CA certificates and trust information, according to the Mozilla CA policy. This list is stored in a binary module named NSSCKBI, and certificates within it are referred to as builtin certificates.

For the DigiNotar incident, we didn't produce a new NSS library release. Instead, we released newer versions of the NSSCKBI module.

Last week, in our immediate reaction, we simply removed the "DigiNotar Root CA" certificate and its trust from the NSSCKBI module. We used version number 1.85 for that older release of NSSCKBI. This release wasn't published separately, but it was used in Firefox version 6.0.1 and other Mozilla updates released at the same time.

Later, we noticed this approach wasn't sufficient, because other
intermediate CA certificates exist that are cross-signed by other
non-DigiNotar CAs that we still trust. We started to work on a better
approach, but this was delayed until Mozilla made final decisions
regarding the intermediates being used by the Dutch Government.

On Friday/Saturday, after the decision was made to completely remove all trust from CA certificates related to DigiNotar, the following approach was used as a better blocking mechanism.

We attempted to identify as many CA certificates as possible, and
inspected each of them carefully. Because the NSS library does not yet have the ability to actively mark a specific certificate as completely untrusted, in a way to prevent other trust paths to become active, we used a workaround.

We manually manipulated the binary structure of the known CA
certificates, and created special knockout certificates. The following procedure was used to create them:

- start with the original certificate

- manipulate the serial number to a new number, that is unlikely to
collide with other existing certificates (we used 0x*FFFFFFF)

- manipulate the NotBefore and NotAfter embedded in the certificates,
change them to be in the future when compared with the original ones

This has the following effect: When the NSS library attempts to verify a certificate, it will search the list of known/available certificates. If there are multiple candidates with the same subject names, NSS will prefer the ones that are more recent. This means, our knockout certs will be preferred.

Because of an implementation detail of NSS and Firefox, we made an
additional change to the certificates. Mozilla has asked that software users, when visiting an SSL site that uses a certificate issued by one of the DigiNotar CAs, should still be able to override the default trust decisions made by NSS. Because of this, we had to prevent NSS from checking the signature of our knockout certificates. The signatures obviously were no longer correct after our manual modifications.

The easiest way to prevent this was to apply another binary modification to the knockout certificates, in order to make them appear to be self-signed. This means, while several of the original certificates had different fields for subject name and issuer name, we removed the issuer name and inserted another copy of the subject name.

After these modifications, we added the knockout certificates to the
NSSCKBI module and marked them as not trusted.

We have released NSSCKBI version 1.87 which contains a knockout
certificate for the "DigiNotar Root CA" certificate, and 5 knockout
certificates for intermediates. We published a combination of the latest stable release of NSS 3.12.11 with this newer roots module at

The following is the set of intermediates known to us:

Issuer: C=NL, O=DigiNotar, CN=DigiNotar Root
Subject: C=NL, O=DigiNotar, CN=DigiNotar Root
Serial Number: 0c:76:da:9c:91:0c:4e:2c:9e:fe:15:d0:58:93:3c:4c
Not Before: May 16 17:19:36 2007 GMT
Not After : Mar 31 18:19:21 2025 GMT

Issuer: C=US,, incorp. by ref.
(limits liab.), OU=(c) 1999 Limited, Secure
Server Certification Authority
Subject: C=NL, O=DigiNotar, CN=DigiNotar Services 1024
Serial Number: 1184640176 (0x469c2cb0)
Not Before: Jul 26 15:59:00 2007 GMT
Not After : Aug 26 16:29:00 2013 GMT

Issuer: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc.,
CN=GTE CyberTrust Global Root
Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber
Serial Number: 120000525 (0x727100d)
Not Before: Oct 4 10:54:11 2006 GMT
Not After : Oct 4 10:53:11 2011 GMT

Issuer: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc.,
CN=GTE CyberTrust Global Root
Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber CA
Serial Number: 120000505 (0x7270ff9)
Not Before: Sep 20 09:45:32 2006 GMT
Not After : Sep 20 09:44:06 2013 GMT

Issuer: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc.,
CN=GTE CyberTrust Global Root
Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber CA
Serial Number: 120000515 (0x7271003)
Not Before: Sep 27 10:53:32 2006 GMT
Not After : Sep 27 10:52:30 2011 GMT

Issuer: C=NL, O=Staat der Nederlanden, CN=Staat der Nederlanden Overheid CA
Subject: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Overheid en
Serial Number: 20015536 (0x13169b0)
Not Before: Jul 5 08:42:07 2007 GMT
Not After : Jul 27 08:39:46 2015 GMT

Issuer: C=NL, O=Staat der Nederlanden, CN=Staat der Nederlanden
Organisatie CA - G2
Subject: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Organisatie
- G2
Serial Number: 20001983 (0x13134bf)
Not Before: May 12 08:51:38 2010 GMT
Not After : Mar 23 09:50:04 2020 GMT

And what follows are the details of the knockout certificates we have
created. We believe this smaller list is sufficient to handle all the
intermediates listed above, because some of them have identical subject

Issuer: C=NL, O=DigiNotar, CN=DigiNotar Root
Subject: C=NL, O=DigiNotar, CN=DigiNotar Root
Serial Number: 0f:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
Not Before: Jul 27 17:19:37 2007 GMT
Not After : Mar 31 18:19:22 2025 GMT

Subject: C=NL, O=DigiNotar, CN=DigiNotar Services 1024
Issuer: C=NL, O=DigiNotar, CN=DigiNotar Services 1024
Serial Number: 268435455 (0xfffffff)
Not Before: Jul 26 15:59:01 2007 GMT
Not After : Aug 26 16:29:01 2013 GMT

Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber
Issuer: C=NL, O=DigiNotar, CN=DigiNotar Cyber
Serial Number: 268435455 (0xfffffff)
Not Before: Oct 4 10:54:12 2006 GMT
Not After : Oct 4 10:53:12 2011 GMT

Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber CA
Issuer: C=NL, O=DigiNotar, CN=DigiNotar Cyber CA
Serial Number: 268435455 (0xfffffff)
Not Before: Sep 27 10:53:53 2006 GMT
Not After : Sep 20 09:44:07 2013 GMT

Subject: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Overheid en
Issuer: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Overheid en
Serial Number: 268435455 (0xfffffff)
Not Before: Jul 5 08:42:08 2007 GMT
Not After : Jul 27 08:39:47 2015 GMT

Subject: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Organisatie
- G2
Issuer: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Organisatie - G2
Serial Number: 268435455 (0xfffffff)
Not Before: May 12 08:51:39 2010 GMT
Not After : Mar 23 09:50:05 2020 GMT

If you have copies of additional intermediates that you would like to
see blocked, please send us full copies of the certificates, and we will see if further action is necessary.

Kai Engert

view entry ( 5132 views )   |  permalink   |  $star_image$star_image$star_image$star_image$star_image ( 3 / 3724 )

SSL/TLS renegotiation vulnerability still widely unpatched 
Monday, June 20, 2011, 01:38 PM
Posted by Administrator
In November 2009 a Man-In-the-Middle vulnerability for SSL/TLS/https was made public (CVE-2009-3555), and shortly afterwards demonstrated to be exploitable. In February 2010 researchers published RFC 5746 that described how servers and clients can be made immune. Software that implements the TLS protocol enhancements became available shortly afterwards. Most modern web browsers are patched, but the solution requires that both browser developers and website operators take action.

Unfortunately, 16 months later, many major websites, including several ones that deal with real world transactions of goods and money, still haven't upgraded their systems.

Even worse, for a big portion of those sites it can be shown that their operators failed to apply the essential configuration hotfix. They support the style of handshakes that can allow a MITM attacker to inject attack data into the transaction stream.

Here is a list of patched and unpatched popular sites, along with more background information. The patched sites demonstrate that patching is indeed possible.

Given that attackers could execute malicious transactions with a customer's credentials, customers should demand that this security issue gets resolved quickly. What can we do to remind service providers that fixing this issue deserves a high priority?
view entry ( 4505 views )   |  permalink   |  related link   |  $star_image$star_image$star_image$star_image$star_image ( 2.8 / 25 )

Man-In-The-Middle experience in Warsaw 
Thursday, June 16, 2011, 03:17 PM
Posted by Administrator
This is a report about a Man-In-The-Middle (MITM) situation that I experienced a couple of days ago while travelling.

I spent the night in a hotel in Warsaw, Poland. I bought access to the Internet WiFi. When my Thunderbird email client started, it automatically checked my various email accounts.

For the SSL connection to (also known as at port 993, Thunderbird warned me about a certificate error. The certificate presented by IP address was issued to

Subject: C=US, ST=California, L=Mountain View, O=Google Inc,

and it was issued by

Issuer: C=US, ST=California, L=Sunnyvale, O=Fortinet, OU=Certificate Authority, CN=FortiGate CA/

Given that Google's computers usually use certificates from Certificate Authorities that are trusted by Thunderbird, and given that this particular is not, this appeared to be a MITM attack.

The next question was, who is it that sends this unknown certificate to me? Is it sent by Google's IP address, or is it sent to me by another computer that is physically present on the route between me and Google?

I started an analysis. I made remote connections to other computers, including my server located in Germany. I repeated the connection attempt from my server to the same IP For this connection, things looked good, I received a valid certificate from a CA trusted by Thunderbird. A friend of mine, who lives in Warsaw, repeated the test using his home Internet connection. Again, things looked good.

The conclusion is, someone along the route between me (sitting in the hotel) and the server, was using a MITM software or hardware to hijack my connection.

Luckily I noticed it, thanks to the automatic checks used by Mozilla Thunderbird.

So, who is it that performed the attack on me? That's not easy to tell.

Without blaming anyone, I'm naming the involved parties:
- I was in the Metropol Hotel Warsaw
- the Internet provider appears to be
- anyone else in control of one of IP addresses on the route between the hotel and Google:

$ traceroute
traceroute to (, 30 hops max, 60 byte packets
1 ( 4.169 ms 4.206 ms 4.287 ms
2 * * *
3 ( 15.412 ms 15.578 ms 15.712 ms
4 ( 15.903 ms 16.043 ms 16.239 ms
5 ( 38.372 ms 38.978 ms 39.663 ms
6 ( 40.449 ms ( 30.391 ms ( 40.327 ms
7 ( 90.287 ms 65.451 ms ( 43.865 ms
8 ( 134.331 ms 134.560 ms ( 124.102 ms
9 ( 139.958 ms 140.091 ms ( 136.167 ms
10 ( 140.229 ms ( 140.453 ms ( 129.356 ms
11 ( 134.299 ms ( 130.482 ms ( 127.593 ms
12 ( 128.946 ms 130.188 ms 129.702 ms

The first step on identifying the potential attacker was to inspect the certificate that was presented by the MITM. The certificate claimed to be issued by FortiGate CA. What does this mean?

FortiGate is a product sold by Fortinet, Inc. It is a device that can be used to perform a various set of actions on Internet connections. For example, a company could use it to block connections, for example to disallow employees to access their private email. Another use is being able to watch the contents of encrypted connections between a browser and Internet services.

It is debatable whether the use of such appliances is acceptable. There might be scenarios where this is acceptable. For example, one could think of a governmental agency that allows its employees to make private connections to the Internet, but at the same time all employees have agreed to never publish any confidential information, and employees might have agreed that all their actions are being watched while at work, in order to verify that no confidential data is being published. This might be an acceptable scenario.

In my opinion, using such a MITM appliance, for the purpose of hijacking connections of hotel guests to Email service providers, is clearly not acceptable. Other's have to decide whether this is a criminal situation, but I think it might be.

I've talked to a representative of the German office of Fortinet. I was told, by default the FortiGate appliances come with a zero configuration. Any blocking or MITM behaviour of the FortiGate appliance must be deliberately enabled by the customer.

In my understanding, we cannot blame Fortinet. They appear to have provided the tool being used to perform an attack, but it appears that someone else has installed and abused that tool.

Unfortunately I don't know whom to blame. This would have to be decided by an investigation.

The important lesson that we can take away from this story:

Don't lightheartedly ignore security warnings. They can be real attacks. In my scenario, if I had decided to connect anyway, the person performing the MITM would have been able to hijack my password to one of my accounts.

(Also, I have a technical question about the kind of connection used by Android's Google Mail application. Does it use IMAP with SSL on port 993? I hope it does not. When I connected the Android phone to the hotel wifi, it successfully connected. I did not get any security warning. This might be OK, depending on which protocol is being used by the software. If know what it uses, please let me know. Thanks. (To be on the safe side, I had immediately changed my password using a non-MITM client.))

[Update 1] (My separate worry about the Android app was unfounded. Meanwhile I've been in contact with a representative from Google. I've been told that the "Google Mail / Gmail App" on Android always uses https on port 443. This port was not affected by the MITM attack. The attack was limited to imap/ssl on port 993.) [/Update 1]

FYI, I saved the MAC address of the Wireless Access point that I've been connected to, and can provide it to authorities. It looked like 00:4F:62:xx:xx:xx. There were other Access points in the hotel. Unfortunately only this one AP's signal was strong enough to keep a connection to it from my room.

[Update 2] This scenario appears to happen more frequently.

After reading the article, Stephen Davidson found the following two discussions on the web, which appear to report the same issue:
- report 1 (experienced at a hotel, probably located in the USA, because the author mentioned Sprint)
- report 2 (seems to be happening at a school in the US, last comment indicates probably caused by an accidental misconfiguration)

I was able to find some additional reports:
- report 3 - report 4 - report 5 - report 6 - report 7 (search that page for "")

There's one detail that surprises me most: I am able to find several reports about MITM for mentioning a FortiGate CA, but I cannot find reports mentioning Fortigate and IMAP in combination with some other imap server. Is the explanation that Gmail is the most popular imap service on the web, and that users of other imap servers are aware of the fact that they are being monitored by their environment? [/Update 2]

[Update 3] Clarification: The MITM experience was only seen in one combination of host and port (out of the combinations I tried). In my opinion, if the box accidentally ran an incorrect configuration by mistake, I would have expected it to equally affect all connections on a set of port numbers. However, access to other IMAP/SSL hosts on port 993 (including my own mail server) were NOT affected and used trusted certs. The MITM appears to have been specifically targeted to a certain (set of) host(s). [/Update 3]

MITM used this cert:
Version: 3 (0x2)
Serial Number:
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=Sunnyvale, O=Fortinet, OU=Certificate Authority, CN=FortiGate CA/
Not Before: Apr 22 20:17:57 2010 GMT
Not After : Apr 22 20:27:57 2011 GMT
Subject: C=US, ST=California, L=Mountain View, O=Google Inc,
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption

view entry ( 49258 views )   |  permalink   |  $star_image$star_image$star_image$star_image$star_image ( 3 / 4631 )

<<First <Back | 1 | 2 | 3 | 4 | 5 |