How the initiative to make the internet secure gone wrong?

SSL was supposed to protect you..

How the initiative to make the internet secure gone wrong?

In: Security, Cybersec, Infosec, IT Security

Taking into account the main purpose of SSL is to ensure an encrypted channel of communication between server and client, ensuring both authenticity and integrity via trust chain as well prevention of decrypting without a proper Public / Private key pair.

In its essence, modern cryptography provided a viable solution to:

  • Ensure authenticity of server
  • Prevent man in the middle decrypting of sensitive informations

Considering the benefits of both, back in 2014, Google announced SSL/TLS encrypted web communication will translate as a positive signal in search engine ranking. Following years, SEO race made us to a point that the majority, 51.8 percent of websites now use SSL.

So, what could go wrong?

According to public data from 2017, Cloudflare “protects” 12 million websites, adding approximately 20,000 new customers every day. These numbers could only be drastically higher in 2020.

What is the purpose of Cloudflare:

  • Ensure you can’t reach the origin server in direct.
  • Ensure encryption takes place at the edge of Cloudflare. In other words, re-encryption, or if you like, a “Man in the middle”.

How it looks like:

The main “problem” back in the days, was the fact that encryption takes place prior to Layer 7 headers are sent, including the virtual host name requested. This made it impossible to host multiple websites using the same pair of keys or at least without listing all hostname within these 2048 bits of certificates.

And a problem has been “Solved”. Implementing Server Name Indication (SNI) as an extension to TLS allowing clients to indicate which hostname is trying to connect to within the early stage of handshaking process.

SNI has been born!

Finally, a single IP could support millions of websites “protected” by Cloudflare.

With all the respect of Google’s attempts to make web more secure, what we ended up is:

  • Inability to validate the origin server is what is supposed to be. It’s up to Cloudflare edge.
  • Inability to prevent man in the middle considering re-encryption takes place by design.

With only 12 certificate authorities widely accepted, there’s an alternative for those who don’t like allowing Cloudflare to “secure” their communication.

There’s LetsEncrypt providing a basic domain ownership validated certification via HTTP file upload which is widely accepted, yet there’s no data about PKI fundamentals including HSM storage type, FIPS 140-2 level 3 requirements. In essence, these keys are a big sign of question, especially taking into account recent CAA bug causing millions of certificates revocation at march.

The problem has been reported, further publicly pushed on social media and totally ignored until Google’s intervention. (Likely in an attempt to save the project from commercials players that can’t wait to see them down).

Nope, obviously the push went without any response although millions of sites were affected. In other words, let’s try to cover up.

What’s your opinion. Did we made a progress considering the starting point of:

  • Ensuring authenticity
  • Preventing man in the middle

Aside of letsencrypt which is likely to suffer StartSSL faith due to arrogance, ignorance and incompetence combined with high paychecks out of grants, how do you feel having a single company, Cloudflare protecting the web by by:

  • Hiding and preventing authenticity
  • Has wide open hands for men in the middle decryption.

Bonus: With so much TLS bandwidth following the single private key, what are the odds of not being able to carry statistical analysis against 256bit keys? :)

Share the Fun!

Sharing is caring, and sharing is easy! made it easy!

Join the talk

Share your toughts on the subject or whatever you would like to know.


Browse blog post by popular tags.

Share Page

Back to Top