Today, the public learned of another failure by a Certificate Authority–one of of companies that certifies SSL-encryption for our internet communications. (See the end of this post for a catalogue of our past writing on problems with this “CA” system.) This time, the company Turktrust was revealed to have issued two subordinate certificates (also known as “intermediate” certificates) to entities that should not have had them. Subordinate certificates are very powerful. They give the holder the ability to issue SSL certificates for any domain name as though they have control of the parent CA’s “root” certificate. In this case, Google discovered that one of Turktrust’s previously undisclosed subordinate certificates had issued SSL certificates for the domain gmail.com, and that these certificates had been used to intercept Gmail users’ traffic… somewhere. This is where the details get foggy, but Turktrust has begun to describe their version of events.
There is a less paranoid and a more paranoid way of interpreting what happened.
But first, for the geeks, here are the contents of the subordinate certificate that issued the gmail.com certificate. I don’t believe that this has been posted publicly so far (hat tip to Alex Halderman and his genius students/colleagues).
According to Turktrust, they made some configuration errors in late 2011 that caused them to inadvertently hand out subordinate certificates to two entities–the Turkish government and a Turkish bank. They claimed that these users expected to receive ordinary SSL certificates that could be used to secure their own web sites, not what amounts to a master “skeleton key” to the internet. This assertion is somewhat supported by the fact that one of these certificates appears to have been used for precisely that until recently, at www.ego.gov.tr (which seems to be the web site for the capital city of Ankara or one of its offices, but I’m sure that Zeynep will clear this up in the comments). Turktrust says that the certificate was used by the government to provide SSL-encrypted webmail–presumably for government employees (As a further side-note, it is unclear whether deploying subordinate certificates as though they are ordinary SSL certificates will cause some or all browsers to generate an error, but perhaps it worked for them). In any case, Turktrust says that a government system administrator recently loaded the certificate onto a “firewall” that proceeded to perform man-in-the-middle attacks on individuals who attempted to browse to secure web sites like gmail.com. It’s not clear what network this device was on (although it was evidently manufactured by Check Point), and which individuals were affected. The least paranoid version of suggests that the device sat between the government’s internal network and the public internet, and that the only individuals affected were government employees in that office.
The more paranoid version of events is perhaps less likely, but it helps to highlight some fundamental shortcomings in the Certificate Authority system. Subordinate certificates have long been identified as a point of weakness in the CA system. They are typically granted unconstrained power to issue certificates for any domain name. Thus, a leak of one subordinate certificate is seen as equivalent to a leak of authority equivalent to all CAs combined. Worse, subordinate certificates need not be explicitly trusted by the software that authenticates encrypted SSL connections (typically your web browser). They inherit their trust from the explicitly trusted CAs that have been vetted by your browser vendor. Browser vendors have slowly been trying to reign in the practices of CAs that issue subordinate certificates to third parties. For instance, when CA Trustwave admitted that it had been selling subordinate certificates to third parties for the purpose of performing man-in-the-middle attacks, Mozilla made clear that this was unacceptable. That being said, depending on your browser, there may be a couple hundred trusted CAs. Hoping that they all comply with a policy is probably not enough. I have spent the past couple of years trying to convince Mozilla to strengthen their requirements so that CAs must disclose all subordinate certificates that they have issued, so that researchers can better map the risk landscape and so that users can make more informed trust decisions and detect unexpected subordinates. They’re getting closer, but it is taking an awfully long time. Several years ago, security researchers Christopher Soghoian and Sid Stamm described the “compelled certificate creation attack” in which a government would compel a local CA to produce a subordinate certificate that it would then use to conduct mass or targeted man-in-the-middle surveillance on its citizens.
We are justified in indulging in a bit of professional paranoia, given that the Turktrust subordinate certificate in question was controlled by the Turkish government, and that it was used to perform man-in-the-middle attacks. It also happens to be the case that Turktrust satisfied its annual compliance audits by having the Turkish government audit their operations, as opposed to the more common practice of obtaining an audit from a commercial auditing firm (although they claim to have recently obtained a commercial audit, they have yet to publish any documentation of this as far as I can tell). Turktrust has begun to give some answers, but it’s worthwhile to keep probing.
Mozilla revoked trust in one of Turktrust’s three “root” CA certificates, as did Google–but oddly the revoked root is not the certificate that issued the subordinate certificates in question. It is a new root certificate (included in Firefox only in beta releases so far), and it is intended to be used only for issuing higher-standard “extended validation” certificates. It appears that the browsers’ strategy is to provide some mild punishment to Turktrust without disrupting the operation of legitimate sites that have obtained standard SSL certificates from them in the past. Representatives from both browser vendors have stated that it is unclear how they will proceed, and one can imagine that they would restore trust in this root at some point in the future. Is Turktrust’s behavior sufficient that trust in all three of their roots should instead be removed permanently? The facts are still emerging.
There is a less paranoid and a more paranoid way of interpreting what happened.
But first, for the geeks, here are the contents of the subordinate certificate that issued the gmail.com certificate. I don’t believe that this has been posted publicly so far (hat tip to Alex Halderman and his genius students/colleagues).
According to Turktrust, they made some configuration errors in late 2011 that caused them to inadvertently hand out subordinate certificates to two entities–the Turkish government and a Turkish bank. They claimed that these users expected to receive ordinary SSL certificates that could be used to secure their own web sites, not what amounts to a master “skeleton key” to the internet. This assertion is somewhat supported by the fact that one of these certificates appears to have been used for precisely that until recently, at www.ego.gov.tr (which seems to be the web site for the capital city of Ankara or one of its offices, but I’m sure that Zeynep will clear this up in the comments). Turktrust says that the certificate was used by the government to provide SSL-encrypted webmail–presumably for government employees (As a further side-note, it is unclear whether deploying subordinate certificates as though they are ordinary SSL certificates will cause some or all browsers to generate an error, but perhaps it worked for them). In any case, Turktrust says that a government system administrator recently loaded the certificate onto a “firewall” that proceeded to perform man-in-the-middle attacks on individuals who attempted to browse to secure web sites like gmail.com. It’s not clear what network this device was on (although it was evidently manufactured by Check Point), and which individuals were affected. The least paranoid version of suggests that the device sat between the government’s internal network and the public internet, and that the only individuals affected were government employees in that office.
The more paranoid version of events is perhaps less likely, but it helps to highlight some fundamental shortcomings in the Certificate Authority system. Subordinate certificates have long been identified as a point of weakness in the CA system. They are typically granted unconstrained power to issue certificates for any domain name. Thus, a leak of one subordinate certificate is seen as equivalent to a leak of authority equivalent to all CAs combined. Worse, subordinate certificates need not be explicitly trusted by the software that authenticates encrypted SSL connections (typically your web browser). They inherit their trust from the explicitly trusted CAs that have been vetted by your browser vendor. Browser vendors have slowly been trying to reign in the practices of CAs that issue subordinate certificates to third parties. For instance, when CA Trustwave admitted that it had been selling subordinate certificates to third parties for the purpose of performing man-in-the-middle attacks, Mozilla made clear that this was unacceptable. That being said, depending on your browser, there may be a couple hundred trusted CAs. Hoping that they all comply with a policy is probably not enough. I have spent the past couple of years trying to convince Mozilla to strengthen their requirements so that CAs must disclose all subordinate certificates that they have issued, so that researchers can better map the risk landscape and so that users can make more informed trust decisions and detect unexpected subordinates. They’re getting closer, but it is taking an awfully long time. Several years ago, security researchers Christopher Soghoian and Sid Stamm described the “compelled certificate creation attack” in which a government would compel a local CA to produce a subordinate certificate that it would then use to conduct mass or targeted man-in-the-middle surveillance on its citizens.
We are justified in indulging in a bit of professional paranoia, given that the Turktrust subordinate certificate in question was controlled by the Turkish government, and that it was used to perform man-in-the-middle attacks. It also happens to be the case that Turktrust satisfied its annual compliance audits by having the Turkish government audit their operations, as opposed to the more common practice of obtaining an audit from a commercial auditing firm (although they claim to have recently obtained a commercial audit, they have yet to publish any documentation of this as far as I can tell). Turktrust has begun to give some answers, but it’s worthwhile to keep probing.
Mozilla revoked trust in one of Turktrust’s three “root” CA certificates, as did Google–but oddly the revoked root is not the certificate that issued the subordinate certificates in question. It is a new root certificate (included in Firefox only in beta releases so far), and it is intended to be used only for issuing higher-standard “extended validation” certificates. It appears that the browsers’ strategy is to provide some mild punishment to Turktrust without disrupting the operation of legitimate sites that have obtained standard SSL certificates from them in the past. Representatives from both browser vendors have stated that it is unclear how they will proceed, and one can imagine that they would restore trust in this root at some point in the future. Is Turktrust’s behavior sufficient that trust in all three of their roots should instead be removed permanently? The facts are still emerging.
No comments:
Post a Comment