Risks of SSL

This page is about the risks of relying on browser based encryption (SSL/TLS) - which is currently the only universal encryption protocol supported by all web browsers when connecting to websites (the web browser typically displays then a lock on the address bar - trying to convince the user of the security of the connection - and may also show the protocol name 'https').  This page should interest people who are being marketed browser based email encryption solutions which do not need any software on user's computer.

On march 2017 Wikileaks published leaks from the hacking arsenal of the CIA (Central Intelligence Agency of USA). In some of those documents there is advice to malware writers of CIA: 'DO NOT solely rely on SSL/TLS to secure data in transit. Numerous man-in-middle attack vectors and publicly disclosed flaws in the protocol.' and  'Because this outer layer may be decrypted by an attacker (e.g., SSL Man-in-the-Middle) any transport encryption must be used for  traffic blending only and not for secrecy.'.

Previously on November 2011 the Wall Street Journal published the ‘Surveillance Catalog’ and  the WikiLeaks organization provided a list of International surveillance companies and their equipments on the ‘WikiLeaks Spy Files’ publication. Some examples from the brochures that describe the properties of the equipments: “It can also decrypt SSL traffic if installed in MITM (man-in-the-middle) configuration  ...”; “Track the suspect’s encrypted communication using Gmail, Hush mail etc., Track the suspects banking transactions etc.”; “Intercept any communication within Secure Socket Layer (SSL) or Transport Layer Security (TLS) sessions. Once in place, devices have the capability to become a go-between for any TLS or SSL connections ... users are lulled into a false sense of security afforded by web, e-mail or VoIP encryption.”;”But with a ‘man in the middle,’ the … technology is able to intercept the traffic and the certificate and send along its own fake certificate to the computer, making the computer think traffic is flowing normally.”

Read below a detailed explanation of how this is possible.

When a browser connects to a HTTPS - SSL or TLS server, the server sends a certificate to the browser which ensures to the user that he really is connecting to the wanted server. How can a certificate do that? The owner of the server has – before starting his services - contacted a Certificate Authority (CA) and proved to him that he owns and controls the server.  The owner of the server has sent a public key of the server to the CA and the CA has signed this public key using the private key of the CA. 

All computers doing SSL/TLS have a special store that keeps the public keys of  CAs. These public keys are inside certificates that are called the root certificates. When an incoming certificate from a web server is checked its validity ultimately depends on this root certificate  - there must be a valid cryptographic signature chain from the root certificate to the incoming certificate.  

Now anybody who knows the private key of a root certificate in user's computer can impersonate, decrypt and modify the SSL/TLS stream from every website to this specific computer using a technique called Man-In-The-Middle (MITM) - it will be explained later. So, by design of the certification infrastructure, every publicly accepted  Certificate Authority can - if it turns evil - do that to every SSL/TLS capable computer on this planet. It simply issues a certificate for a server and gives the used public key's private key to an attacker - who now can attack this one server in question. The evil turned CA could also give the private key of the root certificate or a CA certificate signed by the root certificate to the attacker - who can now attack every SSL/TLS server by issuing fake certificates as the need arises. 

One can argue that if the data that should be protected is sensitive enough then it is too big risk that one of the about 600 CA's e.g. turns evil, is hacked, has a bribed employee, or is forced by some government to reveal a private key. The Certificate Transparency project started by Google tries to minimize this kind of problem - it is explained later.

Certificate Authority Trustwave admitted on February 4, 2012 that they had given one private customer a CA certificate signed by Trustwave's root certificate inside a special machine which used a given private key to generate certificates for any website. This was done to decipher and monitor all of company’s online SSL/TLS communication regardless whether the users' devices used were company provided or not – because the certificate was issued by a Certificate Authority no additional certificates were needed on users’ computers. See https://www.theregister.co.uk/2012/02/14/trustwave_analysis/ .

Now also every other root certificate generated by anybody placed somehow into the certificate store of user's computer causes the nullification of protection to the specific computer in question if the certificate's private key falls to wrong hands. 

The attacker can place his certificate to the store e.g. by forcing the user to do this, by evil maid, by evil customs officer or by malware. Some antivirus and parental control programs intercept and decrypt SSL/TLS by placing their own root certificate to the store. There have been situations where the private key of this certificate is the same for every user of the program - this compromises them all, a user finds the private key from his own computer and then can compromise the others. 

Researches published a study on the problems created non-public CAs (which they call 'hidden root certificates') on the root store in paper "Rusted Anchors: A National Client-Side View of Hidden Root CAs in the Web PKI Ecosystem. In CCS ’21, November 15–19, 2021, Virtual Event, Republic of Korea". They conclude that "Through cooperation with a leading browser vendor, we analyze certificate chains in web visits, together with their verification statuses, from volunteer users in 5 months. In total, over 1.17 million hidden root certificates are captured and they cause a profound impact from the angle of web clients and traffic. Further, we identify around 5 thousand organizations that hold hidden root certificates, including fake root CAs that impersonate large trusted ones."

The placing of a certificate to the root store technique is mentioned in the leaked material of Hacking Team company that sells spyware to governments and law enforcement agencies who can easily perform the MITM attack by compelling the internet service providers to place the MITM machines at proper places. Also wifi hotspots and internet cafes can do the MITM attack if they have access to a proper private key.

On July 17, 2019 the government of Kazakhstan started enforcing a policy where web browser users are forced to install a specific root certificate on their computers. When a selected user tries to connect to a selected server the connection is not allowed by the internet service provider unless the government issued certificate is being used. According to a study by the lab Censored Planet from the University of Michigan (https://censoredplanet.org/kazakhstan) the decryption targets included e.g. Gmail, Google, Facebook, Messenger, mail.ru, translate.google.com, Instagram and Youtube.

It can be very dangerous to use unknown computer's web browser to connect to a web server - the computer may have a special root certificate installed which enables MITM attacks and the computer may also route the internet traffic to a MITM machine.

There is also an attack using the DNS system of internet: the attacker succeeds in changing the DNS records in some of internet's DNS servers. After that the attacker requests new certificates for targeted domains from a CA. It can now act as the proper server. The attacker can also redirect the targets' traffic to attacker's servers. This kind of attack was revealed on November 2018 and targeted 50 Middle Eastern companies and government agencies. Use the term 'DNSpionage' to search for more information, see also https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/ by Brian Krebs.

Interesting attack scenario is also when the private key of the server has been exposed. The private key can e.g. be hacked, leaked by evil employee or can be forcefully obtained by authorities.  If the server has not been configured to use Perfect Forward Secrecy (PFS) the attacker recorded old SSL/TLS sessions can be decrypted. If PFS is used a man-in-the-middle attack is required at session time for decryption of the traffic. The attack is now easier to do since no additional certificate is needed on user's computer since server’s private key is known.

The U.S. government forced an email service Lavabit to hand over SSL private keys probably to gather evidence against Edward Snowden. See https://www.wired.com/2013/10/lavabit_unsealed/

The Heartbleed vulnerability in popular OpenSSL that was found in April 2014 exposed server’s memory (private keys etc.). The bug was undetected in the code for 2 years but even older recorded SSL sessions  (without PFS) can be opened using the exposed private key.  "We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication." 

On January 14, 2020 Microsoft informed that a vulnerability was found on certificate validation. The flaw was reported to Microsoft by NSA, see https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF. According to NSA "examples where validation of trust may be impacted include: HTTPS connections, Signed files and emails and Signed executable code launched as user-mode processes. NSA assesses the vulnerability to be severe and that sophisticated cyber actors will understand the underlying flaw very quickly and, if exploited, would render the previously mentioned platforms as fundamentally vulnerable.".  This means an attacker using this flaw can e.g. start a man-in-the-middle attack without knowing any private keys.  Cert coordination centre (https://kb.cert.org/vuls/id/849224/) says "By exploiting this vulnerability, an attacker may be able to spoof a valid X.509 certificate chain on a vulnerable Windows system. This may allow various actions including, but not limited to, interception and modification of TLS-encrypted communications or spoofing an Authenticode signature.". Among affected versions is Windows 10 which was released on July 29, 2015.

Do you still remember what the leaked CIA papers warned: 'DO NOT solely rely on SSL/TLS to secure data in transit. Numerous man-in-middle attack vectors ...'

How the Man-In-The-Middle (MITM) works? The attack can be done by any computer between the web server and the user which knows a proper private key (either root certificate's or server's). When the user initiates the connection to the server the attacker acts like the proper server - it can do this because it knows the private key. To the server the attacker acts like the user.

MITM attack: User  ↔  Attacker ↔  Server.

Many companies use special machines to decrypt the SSL/TLS stream flowing in and out of the company. A certificate is placed on users' computers top enable this. This is done to e.g. search for malware from the stream. Citizen Lab’s report "Planet Blue Coat: Mapping Global Censorship and Surveillance Tools, January 2013" (from https://citizenlab.ca/publications/) describes how SSL interception machines intended for legitimate use for monitoring a specific company’s traffic are also used by countries with a history of concerns over human rights.

The MITM attack can be tried on ‘normal’ SSL or TLS based email and webmail solutions and on email encryption solutions that are browser based. There are also Virtual Private Network solutions that use the web browser. Web browser based systems usually use marketing argument that no software is needed on user’s computer because only a web browser is needed.

Sometimes email encryption is provided in a total browser based way where there is an additional PGP encryption done by javascript. This does not prevent the MITM attacker from being able to decrypt the PGP message. The attacker modifies the javacript that the server sends so that it e.g. sends PGP's private key to the attacker when run by the user.

EndCryptor has to use TLS when contacting email server - this is required by email servers. EndCryptor encrypts the message before contacting an email server - even a successful SSL attack cannot expose the message. In case of EndCryptor the attacker thus can only gain the userid and password to the email server. EndCryptor also stores every certificate it receives, they can later be analyzed if an SSL attack is suspected. EndCryptor can be configured so that when it connects to an email server using TLS it accepts only certain already received certificates – this prevents the usage of hostile server certificates, the dishonest certificate has not been seen before and is rejected. This technique is well known and called certificate pinning.

The Certificate Transparency project (https://www.certificate-transparency.org/) by Google tries to improve the certification infrastructure.  This project tries to log all publicly accepted CA issued SSL/TLS certificates in the world in order to make it possible to detect hostile certificates issued to a specific server. Major CAs take part of it and also search engines may submit certificates they see into the Certificate Transparency logs. Certificates issued after April 30, 2018 will not be accepted as secure by the Chrome browser unless they have a signed statement (a Signed Certificate Timestamp (SCT) accompanying the certificate) that the certificate will be logged. "Specifically, Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates. "

If a publicly accepted CA creates a certificate for a server then it must be logged into the transparency logs. An owner of a domain (e.g. example.com) can query from the logs all the certificates issued to a domain and check that there are only proper ones. The wrong certificate can be misused to decrypt/modify server's traffic until it is detected and revoked and the users know about the revokation. One can draw a conclusion that there must have been serious misuse cases because such a big system is needed.

According to https://www.certificate-transparency.org/benefits: ”Indeed, incidents that at one time were concealed and downplayed, and in fact caused the shutdown of an entire CA, could be exposed much earlier and mitigated by simply revoking a single certificate.”

The Certificate Transparency logging and protection of certificates is not done to local certificates that are not created by a publicly accepted CA (Certification Authority) and that are added to the certificate store of user’s computer by the user or by some program like antivirus, firewall and parental control program or malware. A browser that does not accept a certificate without the required SCT from a public CA will accept a certificate without the SCT if the certificate is not from public CA. The browser assumes that it is being used locally or to decrypt the SSL/TLS stream e.g. to find viruses from the stream.

Encryption solutions relying on SSL/TLS  when communicating to servers do  not necessarily follow the same practice as browsers i.e. require  proper Certificate Transparency extension in the certificate.

Some examples of interesting scenarios:

A term ‘compelled certificate creation attack’ was introduced by Christopher Soghoian and Sid Stamm in their paper ‘Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL’, Financial Cryptography and Data Security '11 March 2011. They define an attack where a goverment forces a CA to issue a certificate to a government given public key in order to decrypt traffic of a selected server.

Certificate Authorities can be targeted by viruses, e.g. Duqu virus targeted certificate authorities and used stolen and forged certificates for its purposes. Electronic Frontier Foundation’s SSL Observatory project (  https://www.eff.org/deeplinks/2011/10/how-secure-https-today) (2011-10-27) that the following reasons for certificate revocations were found in Certificate Revocation Lists:

Reason	Occurrences
NULL	921683
Affiliation Changed	41438
CA Compromise	248
Certificate Hold	80371
Cessation Of Operation	690905
Key Compromise	73345
Privilege Withdrawn	4622
Superseded	81021
Unspecified	168993

The researchers say (2011-10-27) that: “In at least 248 cases, a CA chose to indicate that it had been compromised as a reason for revoking a cert. Such statements have been issued by 14 distinct CA organizations.” When the statistics from earlier 4 months are compared to above findings: “So, from this data, we can observe that at least 4 CAs have experienced or discovered compromise incidents in the past four months. Again, each of these incidents could have broken the security of any HTTPS website.”

On January 3, 2013 Google reported that they had on December 24, 2012 detected an unauthorized digital certificate for the "*.google.com" domain. The certificate was issued by an intermediate certificate authority linking back to TURKTRUST, a Turkish certificate authority. See https://security.googleblog.com/2013/01/enhancing-digital-certificate-security.html. TURKTRUST told Google that in August 2011, they had mistakenly issued two intermediate CA certificates to organizations that should have instead received regular SSL certificates.

On December 2013 Google noticed that several unauthorized certificates were issued for Google’s domains. The certificates were issued by a French governmental certificate authority ANSSI who said that this was a violation of their procedures.  See (https://security.googleblog.com/2013/12/further-improving-digital-certificate.html)

On July 8, 2014 Google reported (https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html) that they had found fake certificates issued for several Google domains and one Yahoo domain and maybe for some other domains also. The issuer of the certificates was India’s National Informatics Centre. India’s Controller of Certifying Authorities said that the issuer’s issuance policies were compromised.

On March 23, 2015 Google reported (https://security.googleblog.com/2015/03/maintaining-digital-certificate-security.html ) that an intermediate certificate authority based in Egypt had used an intermediate level certificate in a proxy to create certificates for user's SSL  sessions. The used intermediate level certificate was issued by  Chinese certification authority CNNIC.

Last updated on November 20, 2021.