HTTPS Insecurity

10 06 2012

The most common method for encrypting traffic on the Internet is the HTTPS protocol.  When a user visits a website with HTTPS, the browser attempts to encrypt communication with the server hosting the site using SSL/TLS.   Assuming the process completes without errors or failures, an indicator will be displayed to the user such as a padlock icon closing, changes to the color of the address bar, or similar UI changes.  These have been understood by the layperson to mean that the identity of the website and server are verified and, more generally, that all transactions with the website are secure and trusted.  Unfortunately, this belief creates a false sense of security.  There are several key deficiencies created by this limited understanding, as I will outline in this post.

SSL/TLS negotiation in a nutshell

After exchanging random numbers and information about available ciphers, identity verification begins when the user’s browser requests the website certificate containing the site’s public key, the issuing Certificate Authority (CA), and the name of the site, organization, or other operating party.  The browser then verifies that the issuing CA is on the preconfigured list of trusted CAs, that the certificate hasn’t expired, that it hasn’t been revoked, and that it is otherwise valid.  Once this is complete, the browser then encrypts a random number using the website’s public key and sends it to the server.  The web server decrypts the number using its private key and uses the received information to generate the session keys.  Both machines then exchange hashes of the session keys to ensure they are ready for encryption.  With this information verified, the encrypted session can then begin (Kaufman, Perlman, & Speciner, 2002).


Certificate Authority Trust Issues

Modern web browsers ship with dozens of CAs preconfigured (Mozilla Foundation, 2012).  While this avoids forcing users to create their own CA lists, it means that users implicitly trust all preconfigured CAs.

To complicate this, all CAs are not equal.  While many are for-profit companies, they exist in a variety of political climates and geographic areas.  Governments control some Certificate Authorities, and as a result they are susceptible to political coercion, manipulation, and other undesirable behavior.  Other CAs may have business models that are inconsistent with proper security practices.  As stated by security researcher Matt Blaze, “certificate authorities protect you from anyone from whom they are unwilling to take money” (Blaze, 2010).  All CAs in the preconfigured list are trusted equally and verify their certificates without prompts to the user.  While convenient, this model does not provide proper transparency, instead necessitating that users completely trust the security of each individual CA without question.

Related to the problem of preconfigured CAs is the issue of CAs being added to the list unbeknownst to the user.  Organizations may create their own certificate authority and add it to employees’ browsers.  While adding a degree of flexibility and convenience, this practice also brings inherent risks.  The users again must implicitly trust this new CA, perhaps without knowing it was added to their browser.  Furthermore, organizations may not possess the expertise necessary to properly secure a CA, thereby creating an unforeseen attack vector.  Security decision makers need to understand the implications of inserting themselves in the Public Key Infrastructure (PKI) and ensure that they have taken proper steps to strengthen, not weaken, the security model.

All CAs, not just those internal to an organization, are subject to compromise.  TLS/SSL is supposed to provide non-repudiation, but this can’t be guaranteed unless the certificate vendor has removed every possible risk of intrusion.  Indeed, the fallibility of CAs has been demonstrated multiple times, such as when Verisign was tricked in to issuing Microsoft certificates to an attacker (Lemos, 2001), when Comodo was breached and made to issue fraudulent certificates, and again later when Diginotar and others were compromised and used to generate hundreds of fraudulent certificates (Fisher, 2011).

Certificate Authority Verification Issues

The verification process used by CAs to authenticate a certificate request often does little to serve the needs and expectations of clients that will eventually be using the certificate.  GoDaddy, one of the most popular CAs, requires no more than an email response from the domain being requested (GoDaddy, 2010).  A similarly weak system was exploited when Verisign issued Microsoft’s certificates erroneously (Microsoft Corporation, 2001).  Certificates with stronger verification are available, but the cost can be prohibitively high while the additional protection is often misunderstood or ignored by many users (see User Issues below).

As previously mentioned, if any common CA can be coerced into issuing a certificate, the standard browsers will accept this certificate without further prompting.   The only way for the user to check the validity of the certificate would be to examine it, manually tracing its chain of authority back to its origin.

Certificate Origin and Authority Issues

A certificate serves to prove merely that it belongs to and is being used by the person or organization that purchased it.  This may or may not be whom the user is expecting.  For example, how can a user be certain that the Microsoft to which the certificate was issued is the Microsoft they are expecting?  Examining the certificate to verify other properties is the best answer to this question, but even this is an inexact method with potential for failure (Schneier & Ellison, Ten Risks of PKI, 2000).

Furthermore, certificates are unable to assert that the domain name is authoritative.  While DNS authorities exist, the SSL/TLS CAs preconfigured in popular browsers are not such authorities.  CAs have become a de facto authority for domain correctness within SSL/TLS, but this is not vetted or checked against real DNS authorities.  As a result, this assumption of correctness is based on tenuous precepts (Schneier & Ellison, Ten Risks of PKI, 2000).

Browser Issues

There are several issues with our current browser infrastructure that serve to weaken the SSL/TLS infrastructure.  One of the primary problems is that browsers currently do not prompt the user with possibly significant changes to a website’s certificates.  In particular, a user will not be informed if a website’s certificate changes, if it removes Extended Validation, if it comes from a different provider, or if it changes expiration.  So long as a valid CA will authenticate the new or changed certificate, the user is not notified, even though these changes may possibly be symptoms of a compromise or other security event.

When it comes time to remove a compromised certificate, the process used by browsers is overly cumbersome and imprecise.  When Comodo was hacked and used to issue fraudulent certificates, it required that all the major browser makers issue updates to the browsers themselves in order to blacklist the offending certificates (Leonhard, 2011).  This means that if a user does not receive and install the browser update in a timely manner, they will still be susceptible to fraudulent certificate acceptance.

User Issues

SSL/TLS is a complex mechanism designed to solve a difficult problem.  Unfortunately, many users are not technically astute and do not understand the underlying security implications.  Security-related user interface elements (the yellow padlock, for example) and certificate prompts assume that the user is able to understand and react accordingly, but this is often not the case.  As a result, non-technical users are particularly susceptible to problems because they lack awareness and knowledge necessary to parse security warnings.  In particular, it has been shown repeatedly that the “Dancing Pig Problem” is still in full effect.

Bruce Schneier explains this phenomenon in his book Secrets and Lies:

If J. Random Websurfer clicks on a button that promises dancing pigs on his computer monitor, and instead gets a hortatory message describing the potential dangers of the applet — he’s going to choose dancing pigs over computer security any day. If the computer prompts him with a warning screen like: “The applet DANCING PIGS could contain malicious code that might do permanent damage to your computer, steal your life’s savings, and impair your ability to have children,” he’ll click OK without even reading it. Thirty seconds later he won’t even remember that the warning screen even existed. (Schneier, Secrets and Lies, 2000)

Not only are most users unable to identify security issues and react accordingly, they have been trained to ignore the barrage of seemingly incomprehensible techno-babble they encounter.  This presents a particular problem when it comes to SSL/TLS security, as the messages often pertain directly to trust decisions or problems.  These warnings go unheeded and the decisions are made by default settings in nearly all circumstances.


There are numerous risks present in the current HTTPS implementation.  The famous yellow padlock has been advertised to users as a promise of ubiquitous security for web transactions, but this is not realistic.  Additional mechanisms seek to remedy the problem, such as the Certificate Patrol add-on for Firefox, but they require that users seek them out and be sufficiently educated to understand the warnings.  As it stands, additional user education is required to help non-technical computer users understand the implications of our current HTTPS system.


  1. Blaze, M. (2010, March 24). The Spy in the Middle. Retrieved June 2, 2012, from Exhaustive Search:

  2. Fisher, D. (2011, September 2). Comodo, DigiNotar Attacks Expose Crumbling Foundation of CA System. Retrieved June 3, 2012, from Threat Post:
  3. GoDaddy. (2010, October 21). How does the Certificate Authority verify domain registration information? Retrieved June 2, 2012, from
  4. Kaufman, C., Perlman, R., & Speciner, M. (2002). Network Security, Private Communication in a Public World (2nd ed.). Upper Saddle River, NJ: Prentice Hall.
  5. Lemos, R. (2001, March 22). Microsoft warns of hijacked certificates. Retrieved June 1, 2012, from CNET News:
  6. Leonhard, W. (2011, March 24). Weaknesses in SSL certification exposed by Comodo security breach. Retrieved June 3, 2012, from InfoWorld:,0
  7. Microsoft Corporation. (2001, March 22). Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard. Retrieved June 3, 2012, from Microsoft Security TechCenter:
  8. Mozilla Foundation. (2012). Included Certificate List. Retrieved June 2, 2012, from Home of the Mozilla Project:
  9. Schneier, B. (2000). Secrets and Lies. New York, NY: Wiley Computer Publishing
  10. Schneier, B., & Ellison, C. (2000). Ten Risks of PKI. Computer Security Journal , 16 (1), 1-7.
  11. Schneier, B., & Ellison, C. (2000). Ten Risks of PKI: What You’re Not Being Told About Public Key Infrastructure. Computer Security Journal , 16 (1), 1-7.





3 responses

15 06 2012
Lisandro Aguirre

Very interesting article and definitely I agree with the implications of implementing https sites. Technically, it represents a chalenge, but at user level, the impact is that usually we don’t trust on internet transactions due to there is not enough information (at user level) about how https works and how secure it is.

16 06 2012
Thomas Timpf

I’d wonder what are the risks associated with data exchanged even if the certificate is not verified. I know at work we use https for many internal web servers where the certificate would never be validated by an external authority. As you mention my browser regularly tells me this certificate may not be valid but I still use it.

26 06 2012
Michael Petit

What is the answer? The world has embraced the web and the web continues to gain popularity. Do browsers need revamping? How do you recommend browser security be enforced? Do users need training? Is there a better solution within the industry that should be embraced?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: