SSL/TLS IN A POST-PRISM ERA
This is a collection of information related to the security of Transport Layer Security (TLS and SSL). The aim of this page is to keep track of the current limitations and security problems in SSL/TLS and HTTPS. The biggest unsolved problem is the trust model of the Certification Authorities.
All of these problems have been known for some time. These problems are mainly discussed and talked about at special security conferences to an audience that only contains security experts. These issues are rarely discussed with the general public or developers who use SSL/TLS in their projects. We aim to raise awareness of these problems outside of the security community.
- ROOT-CA Security Breaches
- Letter to EU Commission on French CA abuse
- Browser Manufacture failed us
- Other Problems
- Summary of best known immediate solution
- Further Reading
1.1. What is SSL/TLS and CA
There are 600+ Certification Authories (CA's) in 52+ different countries. Many of them with different commercial and geopolitical interests.
The total number of CA's is not known and hard to estimate.
The optimist counts the different organizations in the browser's CA store. This number does not include many intermediate CA's. (An intermediate CA has the power to generate a google.com certificate which is trusted by the browser without the intermediate CA having to be included in the Browser's CA store (Yes)).
The number further increases if you include all the organizations which do not control their own CA key but who have the capability to sign (or submit for signing) _any_ certificate for _any_ domain including certificates with BasicConstraints CA:True flag set. This flag creates an intermediate-intermediate CA (which again can create any certificate for any domain including and intermediate-intermediate-intermediate CA ..and so on and so on...). We are easily in the thousands if not higher.
The number increases further if all the organizations who purchases Monitoring-Proxies are included. The monitoring proxies contain a mini-CA which can create certificates for _any_ domain on the fly (for SSL monitoring purposes at larger corporations.).
The number 600 is from the EFF's 'best educated guess' from the SSL Observatory Project and is significantly lower than the estimate by other academic whitepapers.
http://ssrn.com/abstract=2277806 Puts the number at 907
https://jhalderm.com/papers/ Puts the number at 683
1.2. The biggest problem with SSL/TLS
- Accidentally bad CA's: Any of the 600+ CA's in the 52+ different countries can sign SSL certificates for any domain name. In other words, anyone can request a SSL certificate for www.google.com with any CA, even though this CA is not an organization Google itself has contracted to sign its SSL certificate.
Deliberately bad CA's: Rogue CA's can also generate their own key and sign this key to create a valid certificate for www.google.com without the knowledge of Google Inc.[2-Weis]
Once a certificate is issued by a CA that certificate is accepted by any browser without warning to the user that the connection is not secure. Insecure connections can be intercepted and have been in the past (on a massive scale).
2. ROOT-CA Security Breaches
2.1. Dutch CA DigiNotar
In mid July 2011 a hacker supposedly sympathizing with the government of Iran compromised DigiNotar's ROOT-CA key. This compromised key was used by criminals to create 531+ false certificates.
The attacker was able to intercept secure communication between the user and sensitive domains such as google.com, facebook.com, update.windows.com and cia.gov.
ENISA, the European Network and Information Security Agency, speaks of breached communications of ‘millions of citizens’, particularly connected to the *.google.com certificate, and notes that some experts believe that the lives of Iranian activists have been put at risk (ENISA, 2011).
Etisalat is a telecommunications company and Certification Authority headquartered in the United Arab Emirates. In July 2009, Etisalat allegedly abused a code-signing certificate trusted by Research In Motion (the manufacturer of BlackBerry).
Etisalat allegedly issued a malicious firmware update to approximately 143,000 of its BlackBerry subscribers which contained surveillance software.
It was never proven beyond doubt that Etisalat was behind the attack. These are the fact:
- At the time Etisalat was pressing RIM to give Etisalat a way to spy on its users. Etisalat threatened to disable all Blackberry services in UAE if RIM did comply.
- The Etisalat spy software contained IP addresses (10.116.x.x) which Etisalat was using at that time in its internal network.
- The spy softare was pushed to the users by SMS/MMS via the Etisalat network.
- Etisalat did not comment on or investigate the incident to the best of our knowledge.
2.3. NSA's PRISM project
There is mounting evidence that the NSA had a copy of several ROOT-CA keys to perform SSL/TLS interception on a massive scale.
2.4. Other Incidents
Other Root Certification Authorities had security breaches or allowed the abuse (willingly or unwillingly) of the ROOT CA Key for spying purposes:
Comodo (InfoSecurity, 2011). Not once, but multiple times.
VeriSign (2010), Compromised, only disclosed in 2012.
CA GlobalSign (Incident Report).
- Trustwave (issued rogue certificates to third parties for interception purposes)
- StartSSL (2008)(2011 attempt)
DigiCert Sdn. Bhd. (Malaysian)
Another source on the History of Risks & Threat Events to CAs and PKI: http://wiki.cacert.org/Risk/History
Some of the above breaches allowed the attacker to get a valid Intermediate CA Certificate (BasicConstrain CA:True). This gave the attacker a certificate which is as powerful as the ROOT CA key (e.g. can sign an unlimited amount of certificates for any domain even after the attacker lost access to the compromised CA servers or Hardware Security Module (HSM)).
This list is incomplete. It is important to note that any one of the above breaches enables an attacker to create a rogue certificate (key & signature) for '''any''' domain name (e.g. google.com) without the knowledge of the domain owner (e.g. Google Inc.). Even if another Certificate Authority as already issued such a certificate. An attacker can use such a certificate to silently and unnoticeable intercept HTTPS traffic between a user and a secure site (e.g. google.com).
- Comodo 2008
StartSSL 2008: http://schmoil.blogspot.de/2009/01/nobody-is-perfect.html
- ANSSI 2013
3. Letter to EU Commission on French CA abuse
Dear EU Commission, The French Ministry of Finance used technology to spy on its employees. The Ministry installed a special product to decrypt Internet traffic for spying purposes. Google found out about it: http://googleonlinesecurity.blogspot.co.uk/2013/12/further-improving-digital-certificate.html And it is hitting the news: http://gigaom.com/2013/12/09/google-catches-french-finance-ministry-pretending-to-be-google/ http://www.theregister.co.uk/2013/12/10/french_gov_dodgy_ssl_cert_reprimand/ ANSSI, the Certification Authority released a questionable press statement: http://www.ssi.gouv.fr/en/the-anssi/events/revocation-of-an-igc-a-branch-808.html Technical details are available here: http://technet.microsoft.com/en-us/security/advisory/2916652 https://bugzilla.mozilla.org/show_bug.cgi?id=946351 Please be so kind and comment below with respect to the possibility to investigate the incident by the EU Commission and if existing laws or policies have been violated. 1. Was the Ministry of Finance/France allowed to spy on its employees, including spying on and decrypting traffic to google.com? 2. Did ANSSI or its intermediate CA's violate or neglected security policies or laws by creating a CA key to be used in a spy-product that is powerful enough to decrypt all secure web traffic (HTTPS, TLS, SSL)? thanks & regards, Ralf Skyper Kaiser The Hackers Choice http://www.thc.org Tw: @hackerschoice
4. Browser Manufacture failed us
There is ongoing effort by the browser manufacture to solve the TLS/CA problem.
- Regulate Certification Authorities and to force them to comply with security policies.
- HSTS, pinning, ....
Especially Chrome and Mozilla are doing a fine job on a technical level.
4.1. Bad Player Etisalat is trusted
Certificate Revocation was designed to deal with compromised CA keys. It fails terribly when dealing with a CA that abuses some but not all of its CA keys. There is no policy or understanding how to deal with an abusive CA.
A 'Bad Player Revocation Policy' that revokes a Bad Player and not just a bad certificate does not exist.
There is no evidence that Etisalat abused the ROOT CA key that is used to sign HTTPS certificates.
Instead there is mounting evidence that Etisalat is a bad player who does not warrant the trust of the Internet.
Etisalat allegedly eavesdropped on 143,000 blackberry users. HTTPS certificates signed by Etisalat are trusted by Mozilla, Chrome, etc. Etisalat is a fully trusted ROOT Certification Authority. Etisalat has the power to spy on secure HTTPS connections to google, facebook, yahoo, etc.
Verizon never revoked the Etisalat key.
The browser manufacture never took any action either.
Mozilla’s position is that Verizon should deal with Etisalat’s behaviour:
[...] the behavior of Etisalat is subject to the contract between Verizon and Etisalat, and should be dealt with by Verizon. (https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/OBrPLsoMAR8)
Mozilla states that their current policy allows what Etisalat did:
We are not aware of a code signing certificate that was issued in a manner that does not meet the requirements of the Mozilla CA Certificate Policy. (https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/OBrPLsoMAR8)
The contractual liability (damage, indemnification, ..) between Verizon vs. Mozilla and the world is zero.
4.2. No clue how many sub CAs exists
Unfortunately there no requirement for a CA to declare or reveal how many sub CA it has created. A sub CA has the same power (security wise) as the Root CA and can again create an unlimited amount of sub CAs.
There is no public information available how many sub CA's a CA has created or who they are.
It would be desirable to see a complete list of entities that posses the power to spy on secure HTTPS connections to google, facebook, etc.
4.3. CAs are not accountable
The Root Certification Authority is not requires to disclose or investigate an incident.
CAs have a commercial interest which is at odds with the security interest of the user.
5.1. Self Signed Certificates
Problem 1: Self-signed certificates trigger a pop-up warning at the user's end.
Research has shown that human beings don't understand certificate warnings and often click through them. Usually, when we get error messages about them, the errors have innocent causes, and the rational response is to click through the warning to get to the site you're trying to visit. But what this means is that certificate warnings don't offer much protection when they are trying to tell people about a real, serious attack.
Problem 2: Self-signed certificates are not pinned to the site even when manually accepted and permanently stored by the user. So whenever you click on the 'Save this self-signed certificate permanently' pop-up it does not really add security. It merely gets rid of the warning pop-up and will allow the server certificate to change without warning the user (as long as it verifies against any of the 600+ Root CA Keys).
- Attack 2a: A valid certificate (issued by a real CA or created from a compromised CA key) is accepted by any browser without any warning even when the user previously accepted (and permanently stored) a self-signed certificate for the site.
- Attack 2b: A malicious self-signed certificate will trigger a pop-up warning at the user's end, again allowing the user to accept the certificate and continue even that a different self-signed certificate has previously been associated with this domain. An attacker can craft the bogus self-signed certificate to look identical (City, Issuer, Subject, Valid time and domain name) to the legitimate self-signed certificate, making it impossible for the user to distinguish between them.
A tool to automatically create a self-signed certificate (on-the-fly) for any newly intercepted SSL/TLS connection has been in circulation since 2001 ( created by stealth of team-teso and doug song of w00w00). The bogus certificates created contain identical Subject information elements as the legitimate SSL certificate.
5.2. SSL Strip
An attacker mounts a Man-in-the-Middle attack between the user and the secure site. The browser's first connection to a site defaults to the unprotected http protocol. The attacker makes a connection to the site and retreives the requested web page. The attacker then parses this web page and replaces all references to https with http (plaintext) before sending the page to the user. The attacker therefore removes all secure https links.
A tool (sslut) has been circulating in the underground since 2004. This tool was used to intercept communications to yahoo, google, citibank and other sites.
Moxie Marlinspike developed sslstrip which was released to the general public in 2009. Moxie also published a detailed video about the risk of sslstrip.
6. Other Problems
6.1. Weak Certificate Keys
Admins and domain owners seem to struggle to generate secure certificates.
http://eprint.iacr.org/2012/064.pdf "Ron was wrong, Whit is right-paper". Bad RSA keys on the Internet
https://www.schneier.com/blog/archives/2008/05/random_number_b.html The Debian bug with bad randomness caused thousands of insecure certificates to be signed and used.
The Certification Authorities should step up their checks and stop signing certificates with 'insecure' RSA public keys.
6.2. Disconnected Security Community
Over the last few weeks we have joined several developer mailing lists and have spoken to developers of jabber, jitsi, pidgin, firefox and others.
Some security professionals are in complete denial that any CA ROOT keys have ever been stolen or compromised. Others believe that replacing connect() with SSL_connect() is sufficient to make the connection secure.
Some developers do not understand that SSL_verify() has to be called and the CN matched against the domain. They were also unaware of the implications regarding self-signed certificates.
The people working in the hacking/security sector are excited about finding the problems but are not excited in solving them. Security problems are disclosed at private security conferences (such as ADMcon and THCcon) but are not reported to the application developers.
The security community and the application developer community are disconnected.
7.1. Online Certificate Status Protocol
OCSP is insufficient and only works if the compromise is detected. It is assumed that most CA ROOT KEY compromises are never detected, made public or that a long attack window exists between detection and revocation (VeriSign 2+ years, DigiNotar 3+ month).
7.2. CA Regulation
The current regulatory regime and auditing obligations have proved quite ineffective. The qualified certificate practices of DigiNotar were strictly regulated and passed the periodic audits based upon regulation and internationally recognized industry standards.
They were hacked regardless.[7-Diginotar and Iran]
Certification Authorities can not be secured enough to warrant the trust of the Internet.
7.3. HTTP Strict Transport Security
HSTS is a web security policy mechanism whereby a web server declares that a complying web browser (firefox, IE, Chrome, etc) are to interact with it using only secure HTTPS connections.
HSTS can be enabled on most web servers (apache, IIS, ..) with a single line in the configuration and does not require a software update on the server and is supported by all major browser vendors.
The web browser learns about the HSTS capability of a web server on its first secure HTTPS connection. All future connections to the web server will use secure HTTPS even when the user enters or clicks on an unsecure HTTP link.
HSTS mitigates sslstrip and similar attacks and adds overall security, however this method is only effective after a user has visited the HTTPS site once.
THC encourages other sites to enable HSTS.
7.4. EFF HTTPS Everywhere
HTTPS-Everywhere is a firefox plugin. This plugin forces a secure HTTPS connection to any web-server that is known to support secure HTTPS.
THC believes that a list of the most common HTTPS enabled web-servers (google, facebook, ...) should be shipped with all browsers by default. Any connection to a server that is in the list should default to secure HTTPS. Chrome already does this for some popular sites.
7.5. Certificate Pinning
Pinning is the process of associating a site with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a site, the certificate or public key is associated or 'pinned' to the site.
THC truly hopes that only the public key (subjectPublicKeyInfo) is pinned and not the entire certificate or just the RSAPublicKey/DSAPublicKey part of the certificate.
THC further hopes that the TLS Version is also pinned to prevent a downgrade attack. (Sad as it is, in order to work on public Internet all browsers implement TLS fallback: in the event of a handshake failure (or TCP-RST) they will retry the connection with a lesser SSL/TLS version)
(Ask us why on https://ircs-web.thc.org)
7.6. Double Signed Certificates
Pinning and HSTS do not help if the ROOT CA that signed the key becomes compromised or the ROOT CA solicits with a government to intercept the traffic (NSA PRISM scenario).
In this solution a web server key could be signed by not one but two or more CAs. The web-server admin could pick two CAs with different geopolitical interest and different security policies. This would dramatically raise the bar for an attacker as the attacker would require to compromise or solicit multiple CAs.
7.7. Reverse Fingerprint
Reverse fingerprint can help make popup warnings more secure.
Assumption: A secure HTTPS connection where the certificate's CommonName (CN) does not match the URL is not permitted by the browser. No warning pop-up occurs and the page does not load (good).
This reduces the number of scenarios for a warning pop-up about an untrusted SSL/TLS connection to these specific scenarios:
- The web server administrator made a mistake.
- The user is the victim of a man-in-the-middle attack.
- The pinned part of the certificate (Key + key-meta data) has changed
- The CN (*.google.com) has no certificate pinned to it. (Regardless if self-signed or CA-signed certificate).
In all current web browser implementations a pop-up warns the user of an unknown HTTPS connection attempt. A fingerprint is displayed to the user and the user is encouraged to verify the fingerprint (by magical means) before clicking 'continue'.
We know that users click 'continue' without verifying the fingerprint. The pop-up warning does not protect the user.
The process should be the other way around:
- No fingerprint should be displayed to the user.
- The user should be asked to insert the correct fingerprint.
- The connection should only continue once the user has inserted the correct fingerprint and fail in all other cases.
THC wishes this idea to become part of certificate-pinning.
7.8. SSL Sovereign Keys
THC does not favour this solution as it relies on the integrity of the append-only data (there is no append-only storage. Ask a hacker.).
7.9. RFC 6962 Certificate Transparency
(Similar idea as SSL Sovereign Keys.)
Step into the right direction. Makes (some) attacks harder. Puts a lot of trust into the entity which runs the log-server (google at this point). (trust in the sense of availability, security, integrity, resistance to geopolitical power and resistance against government to request for a record to be altered, ... ohh dear...). Can anyone clarify this please? contact me.
7.10. SSL Convergence
A distributed strategy to replace the current CA trust model. Convergence authenticates connections by contacting external notaries. Convergence notaries can use a number of different strategies beyond network perspective in order to reach a verdict.
The core idea behind convergence is to use 'network perspectives' to determine whether the certificate you're receiving is the same certificate that everyone else has.
THC believes that this approach adds security at the cost of complexity and slow adoption by the industry.
...only shifts the CA problem without solving it. (Ask us why on https://ircs-web.thc.org or email)
Phillip Hallam-Baker on perpass/IETF ML also points out a geopolitical problem:
What is unique in the case of the DNSSEC is that there is only one root and thus a government can perform a denial of service attack against TLDs.For example asserting that signing the Cuba or Palestine roots would breach existing sanctions legislation or passing new legislation.
...only shifts the CA problem without solving it. (Ask us why on https://ircs-web.thc.org or email)
Skyper's example why DANE won't be sufficient for jabber: http://email@example.com/msg23512.html
8. Summary of best known immediate solution
8.1. BCP or RFC
The IETF should release a RFC or BCP annually. This document should contain security recommendations for the top 10 Internet applications (e.g. Web browsers, email clients, Instant messanger clients, etc).
8.2. for HTTPS
Assume the following scenario:
- A freshly installed browser which has never connected to the Internet.
- Default setting for the browser is to use insecure HTTP.
- Site uses HSTS
- Site uses certificate pinning.
this can be secured if the browser follows this process:
- User enters site name without specifying http or https:
Site is in browsers list for HTTPS connect -> Browser establishes a secure HTTPS connection.
Site is not in browsers list -> Browser establishes an insecure HTTP connection for the first time.
- HTTPS connection has to be verified:
Pinned key is not available -> Use classic CA model to establish first trust (+Double Signed certificates for extra security) or accept self-signed certificate for site (+Reverse Fingerprint for extra security). Pin the key.
Pinned key is available and matches received key -> All Good (self-signed or CA-signed certificates!)
Pinned key is available but does not match -> Use Reverse Fingerprint.
- Store site in HSTS list.
This proposed solution requires:
- 50 lines of source code to be changed in the browser
- A 1 line configuration change at the server
This solution works with existing and already issued certificates and does not require any additional infrastructure. It dramatically raises the bar for an attacker with minimum to no impact to the user.
8.3. For Certificate Verification in General
Prevent Self-Signed Problem 2.
- Support seperate CA locations (CAfile or CApath) for different applications or purposes.
- Implement certificate pinning.
8.4. for applications in general
Implement a Lockdown setting similar to Private Browsing setting available in most browsers.
Lockdown: Security enabled by default. Does not allow the user to circumvent the security even when trying.
For Jitsi/Pidgin/Jabber this would mean:
- OTR plugin: encrypt messages by default (private messaging). Have non-obvious option to disable encrypted private messaging (including a pop-up warning asking if the user knows what he is doing when disabling encryption)
- Default setting to use TLS.
Accept (self-signed) certificates. Pin Subject Public Key Info (SPKI) to server domain name.
- Runtime feature to select CAfile storage location
- Runtime feature to force client to disable logging
- Inform server that user is using lockdown (so that server can reject all clients which do not).
- Runtime Lockdown option: Automatically sets a variety of security preferences to "known good" settings. Once lockdown option is set the user should not be able to change any of the 'locked' security preferences until lockdown is disabled again (e.g. gray out the option). Disconnect when lockdown option changes and reconnect to all servers.
9. Further Reading
https://www.eff.org/observatory HTTPS statistics and research.
http://www.ivir.nl/publications/arnbak/paper_WEIS_2013.pdf Fine paper Why CA's did not work out.
http://blog.cryptographyengineering.com/2012/02/how-to-fix-internet.html Good read on the CA problem.
https://www.eff.org/https-everywhere/deploying-https Simple read of how to do HTTPS correctly
https://www.eff.org/deeplinks/2011/10/how-secure-https-today Simple read of the current state of HTTPS security.
https://www.eff.org/deeplinks/2011/11/sovereign-keys-proposal-make-https-and-email-more-secure Simple read on the pitfalls of current HTTPS implementation.
https://productforums.google.com/d/topic/gmail/3J3r2JqFNTw/discussion The Iranian DigiNotar hack Part 1
https://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html The Iranian DigiNotar hack Part 2
https://www.imperialviolet.org/2013/10/07/chacha20.html How Google disables old SSLv3 in Chrome for Google sites and implements strict TLS 1.2 (thumbs up!).
Special thanks goes to Gamma, Jornt and Brnocrist for helping.