Recent headlines  about government-sponsored surveillance of Internet traffic/data has (rightfully) caused some introspection among the information security industry about how we should go about advising our customers (from a business as well as a personal perspective) in light of these events.
Leaving aside the prickly ethical/moral issues surrounding these events, what can we do to reduce the risk that government (or other non-state but powerful) entities can access our private data, whether it be at rest or in transit ?
The ‘Surveillance Self Defence’ project established by the EFF (http://ssd.eff.org) provides excellent practical guidance on how to minimize your Internet footprint, making it harder for governments (or anyone else for that matter) to access your private data. While written specifically in the context of the US legal system, the advice is applicable to all individuals who value privacy but still want to interact in today’s on-line world. Common-sense advice such as ‘prefer phone communications’ (which typically are not copied/stored in contrast to email or SMS) and prefer POP to IMAP/webmail (POP’s default mode of operation downloads the mail locally and deletes it from the server ) abounds on this site and it’s well worth spending an hour reading through the advice and seeing if you can apply it to your daily on-line routine.
While the SSD site mentioned above does have some advice relating to the security of data ‘on the wire’, the section concerning encryption of web traffic can be summarised as ‘use HTTPS wherever possible’. While this is good advice, recent events have shown that the system of trust underlying HTTPS (or rather SSL/TLS) is coming under increasing pressure. Modern browsers are pre-configured to trust a huge number of CA certificates. Have a read through the slides  from the EFF SSL Observatory (https://www.eff.org/observatory) to get an idea of the current (poor) state of the system. The main problem is that any CA can issue a certificate for any domain. Thus a single compromised (or state-entity-cooperating) CA has the potential to undermine the security of all HTTPS sites on the Internet by issuing trusted certificates for arbitrary hostnames and permitting parties who have access to those keys/certificates to man-in-the-middle communications to those HTTPS hosts (assuming they have access to the relevant network path) .
It’s happened before
This is exactly the sad state of affairs which occurred in the infamous Diginotar ‘hack’. In summary, the Diginotar CA was compromised and over 500 certificates were issued for names such as *.google.com, *.torproject.org (see  for the full list).
The first indication that the issued certificates may have been used by state entities to intercept communications was when users in Iran started reporting that their Chrome browser was issuing warnings about the google.com certificate when they were trying to access their Gmail accounts (read the section below on Certificate Pinning to get an idea of how Chrome was able to detect the ‘fraudulent’ certificates).
A similar event occurred  when the TurkTrust CA mistakenly issued sub-CA certificates instead of regular end-entity certificates for an entity which were subsequently used to issue more fraudulent *.google.com certificates.
So what’s to be done?
If a compromised or incompetent CA can potentially cause such global damage, what about the CAs who voluntarily (or are coerced by legal means) issue certificates for use by intercepting authorities? What can be done to detect these ‘fraudulent’ certificates, which are completely legitimate as far as your web browser is concerned? Well, there are 2 practical steps we can start taking right now to identify fraudulent certificates being used in man-in-the-middle attacks: the DANE TLSA protocol (RFC6698) and ‘Certificate Pinning’ or ‘Certificate Stapling’.
Aside: “DANE” stands for DNS-based Authentication of Named Entities. “TLSA” does not stand for anything; it is just the name of the DNS Resource Record type used for DANE. Anyhow…
The idea behind DANE (RFC6698)  is to use secure DNS to bind the certificate association between the end-entity certificate (or it’s issuer) and the DNS hostname. Specifically, during the TLS handshake, the client makes a DNS request for the TLSA record for the server hostname. The response will (securely) indicate one of 3 ways that the legitimate certificate can be validated:
- By giving the certificate (or even just the public key), or hash thereof, of the ‘legitimate’ server certificate which is sent from server to client as part of the normal TLS handshake.
- By giving the certificate (or hash thereof) of the ‘legitimate’ issuing CA which was used to sign the ‘legitimate’ server certificate.
- By giving the certificate (or hash thereof) of a CA certificate which _must_ be used as a trust anchor when performing PKIX validation of the server’s certificate.
This TLSA record is hosted/signed by the domain owner. Providing that the DNS response is secured by DNSSEC, the client can be assured that the server certificate presented during the TLS handshake has been correctly identified by the domain owner, rather than relying only the browser’s built-in trust store.
While all this is great in theory, the practical roll-out of TLS clients supporting RFC6698 (published in Aug 2012) has been almost non-existent to date:
- Firefox has native support pencilled into their security roadmap, but there is no active development on the feature at this stage .
- Chrome has mentioned of forth-coming support for RFC6698 in GIT , but it’s not there yet.
- Internet Explorer doesn’t support it, but Microsoft thinks the idea ‘is a great one!’ 
- OpenSSL (the core library of many SSL-enabled applications) has support in a development branch which should make it’s way into the 1.0.2 release .
- Postfix v2.11 supports DANE for SMTP client connections using TLS.
In other words, no stable releases of major web or email clients (browsers or libraries) support DANE TLSA yet. However, all is not lost! For Firefox at least, there is are 2 plugins  which provides support for certificate verification of HTTPS connections using DANE and these can be used in the interim until the major browsers have DANE supported natively.
An alternative (albeit not scalable) alternative to using DNSSEC to securely advertise certificates or their fingerprints is to hard-code them into the client itself (!) and update them as browser updates are pushed out. This is precisely how Chrome was able to detect and prevent the Diginotar and TurkTrust ‘attacks’ – the certificate fingerprints for all of Google’s HTTPS ‘sites’ have been baked into Chrome since Chrome 13 . If the fingerprints of any certificate purporting to be issued to a Google hostname do not match anything on the built-in whitelist, Chrome will display an error.
Great – Chrome will detect MITM attacks using fraudulently-issued certificates against Google sites, but what about the rest of us ? Can we get the sites we care about on that whitelist too ? Turns out you can . Used in conjunction with HSTS headers on the server side(to prevent downgrade attacks), commandline options can be passed to Chrome to indicate which sites and certificate fingerprints to add to the whitelist, thus ensuring that fraudulent certificates can be detected if they are presented.
What about the other major browsers ?
- Firefox has this feature on the roadmap , but no confirmed landing date.
- Internet Explorer (or rather the underlying Windows client TLS libraries) can be configured to use certificate pinning via the Enhanced Mitigation Experience Toolkit (EMET) .
The certificate pinning feature is a great way to detect the use of fraudulent certificates when connecting to high-value HTTPS sites. The main downside is that the sites/thumbprints must be managed manually (the thumbprints will need to change every time the server certificate is re-issued (e.g. due to expiry)) so this technique is not as scalable as the DANE-based one.
To sum up
While authentication based on X.509 certificates is going strong inside the enterprise (with certificates issued by Enterprise CAs which are significantly more trustworthy than ‘public’ CAs), the situation out ‘on the Internet’ is more precarious due to trust issues which are becoming more apparent as time passes. The use of DANE TLSA (in combination with DNSSEC) will mitigate most of these issues by letting domain owners assert their own valid certificates (or issuing CAs) in addition to or instead of the public Certificate Authorities. Until DANE TLSA is more widely supported in browsers, the use of certificate pinning is a good interim measure to protect against CA misuse/abuse.
 ABC report
 Of course, the price to pay for this is that you have to maintain backups of your own mail rather than relying on your external mail provider, but most people probably have an established backup routine for all their other data in any case.
 The aforementioned slides state that Macao has it’s own CA certificate in the trust
store of Windows XP, but that SSL certificates issued by that CA were nowhere to be
seen on the Internet despite extensive scanning. If it’s not being used to sign
certificates for legitimate sites, where is it being used and by whom ?
 Mozilla firefox
 OpenSSL ticket
 Firefox plugin #1
 Firefox plugin #2
 Chrome pinning
 EMET cert pinning