HTTPS Weaknesses. Part 2

Any system has its strengths and weaknesses. The first part said about:

  1. impossibility of ensuring complete confidentiality and privacy for users (it is still possible to track and ban the resources that a person visits)
  2. the fact that certificates are transmitted over an open channel and often contain more information than the current resource (for example, bing.com certificate contains information about 72 additional resources, including dev, test, beta environments).

I will continue to call it the “weaknesses” of design. In this article, let’s talk about another weak side — centralization.

HTTPS is based on SSL and TLS protocols (for simplicity we will simply call SSL — although SSL and TLS work at different levels of the OSI stack). Therefore, speaking of weakness, we will keep in mind the centralized SSL protocol.

Theory

Let’s start with the theory of encryption protocols. The problem of modern cryptography is not the encryption itself, but what to do with the keys: how to store, transmit, create and destroy them safely.

The basis of SSL is asymmetric encryption, which is determined by the presence of two keys — if one is for encryption, then the second is for decryption, and vice versa. The main function of asymmetric encryption is authentication, not encryption at all — it is a resource-consuming and expensive operation of this algorithm. Fast and efficient encryption is the prerogative of symmetric algorithms that use the same key for both encryption and decryption.

One of the keys always remains with one party to confirm its identification, it is called a private key. A public key is available to everyone.

Imagine that there is a village of the future where Boris and Anna live. In the future, there are already keys of a different size, and the algorithms are more stringent, and the brain’s abilities are disproportionate to the modern, but the approach remains the same.

Boris and Anna want privacy of their love correspondence, so the main thing for them is a safe exchange of information.

In the simplest case, Boris sends Anna a message: “Let’s talk.” Anna generates two pairs of asymmetric encryption keys — private Pr1 and public P1. “Come on,” says Anna, “I’m Anna, this is my public key, and this is the symmetric encryption algorithm that I know.” Boris generates a symmetric key S1, encrypts it with the public key of Anna P1 (S1). Now S1 can not be decrypted even by Boris, because only Anna can decrypt the message with her private key. In the end, Boris and Anna have a symmetric session key to “ensure” a reliable transfer of letters between them and prevent anyone from reading their correspondence.

I did not specifically reduce this messaging, it turns out that we described SSL Handshake with one-way authentication [1]. With a two-way authentication Boris generates his own key pair and passes the public key to Anna.

An important conclusion that we can already make: among three main functions of SSL protocol (authentication, encryption, integrity), the most important is authentication.

Everything is fine until the postman appears. He is dissatisfied with his life and likes to read other people’s letters, and he’s also smart. And now Boris and Anna are faced with the question: how they can ensure that the postman can not read their messages. The answer is no way. The postman can generate his own key pair, expose Boris his key “supposedly” from Anna, organize two encrypted channels and read their letters.

It is possible to solve the problem only with appearance of a certain third party that can guarantee that the P1 key belongs to Anna. Let’s imagine that a village administration appears in the village, and it maintains the register of public keys of its inhabitants. Anna can take her passport, her public key P1, come there and ask her to register it. Boris, when he receives P1 from Anna, can go to the same administration and check the register. If the key does not match, you can suspect the postman in an attempt to read their correspondence. But the problem is solved for now.

Of course, it’s uncomfortable for Boris to go to the administration every time. Therefore, the same authentication can be made with the administration. The administration now calls itself the Certification Authority (CA) and has its own key pair P10 and Pr10. When Anna comes with her passport and her public key, CA issues something like a card that says — it’s Anna, she owns the public key P1, some more information (up to the passport number) and adds one more field for of its signature: takes all the information from the card, hashes it, encrypts it with its private key, and calls it a digital signature. It would be possible to do it without a hash, but then the signature will be too big. And CA now calls this card a certificate. Now Anna for the exchange of love messages with Boris gives him not just her name and a public key, but also her certificate. Boris will have to go to the village administration only once, and ask them for their public key. Any information that this key can decrypt will be a priori considered as information encrypted by the administration. The postman does not know what to do at all, he is covered by an existential vacuum, he has only one thing to do: try to pick up the private key of the administration so that life returns to normal.

But life does not stop there. Boris has another girlfriend in the next village, then another. He has to add the keys of other administrations to his trusted list, he starts keeping his register with public keys of certification centers. Then it acquires a national and supranational scale. The organizations that sign certificates become so much that they begin to unite into a hierarchy. Root Certification Authority appears, which does not sign the certificates of ordinary users, but only signs the certificates for Intermediate Certification Authority after they have been verified. It is enough for Boris to keep only the public keys of root certificates. And from Anna now he receives not only her certificate, but also certificates of intermediate centers, so that they can be checked up to the root center.

Problem area

The system becomes more complex and centralized, and from that moment the postman again has a chance.

On the one hand, Boris has a small list of root certification centers (Windows prescribes about 50 root certification centers even during installation). On the other hand, it is difficult for him to follow the entire chain of certification centers every time. Most likely, he will no longer check that in the certificate of Anna from his own village for some reason the certification center of another country is indicated. He trusts his list of root centers by 99.9 percent. The postman can go on the most brutal way, and somehow (social engineering, hacking with penetration) to register his fake root certification center in the registry of Boris.

PS. This method of adding a fake certificate of the root center is actively used by both pentesters (like me) and hackers. To conduct penetration testing and use this approach is possible with my favorite tool — ZapProxy (free and open source), which will generate a root site certificate (it must be manually installed), and then it will replace a real certificate with a “similar one”. This allows you not only view traffic, but also stop it, change it and send it on. Therefore, if in your system the validation is not duplicated on the server, then you definitely have problems.

PPS. The second problem in this case concerns Anna and fake center indication in her certificate. Anna paid money, and she would like Boris to recognize her. This problem is solved using SSL Pinning [3], when you can assign trust in the application only to a certain certificate and certain certification centers. This especially makes sense for applications with a high level of risk. With browsers this is more difficult, for mobile applications that work with one or two services this is simpler. For the experiment I put a fake certificate on my Android, indicated that the traffic would go through ZapProxy, which is present on my machine, and saw how many applications use this mechanism. It turned out that no one. I was able to watch and play with the substitution of traffic with almost all popular applications.

So, back to our postman. The government could not but appreciate his zeal and endowed him with the status of a secret agent with higher powers. Although the private keys of root certification centers are stored under seven locks, self-igniting disks, multi-layered protection. So even the postmaster’s authority may not be enough to agree with root certification centers so that they give him their private key to generate fake valid certificates (although everything is possible). Our postman found an easier way. He goes to his village administration, which is in the hierarchy of certification centers at the lowest level, and bribes the administration to sign his certificate as an intermediate certification authority certificate. Now he can see the traffic not only of Boris, but, in principle, of any subject. A person probably will not even notice anything, the browser does not show any warnings.

This is a known problem, and with it humanity is also trying to fight. If such fake certificates, compromised intermediate and root centers are found, these certificates should be marked as revoked and compromised (Revoked Certificates). This means that in addition to storing root certificates Boris also needs to constantly synchronize them with the online list of revoked certificates — this mechanism is implemented through the CRL (certificate revocation list) and Online Certificate Status Protocol (OCSP) protocols [4], that, incidentally, work on an unprotected channel. When we started actively working on controlling OUTPUT traffic using Dhound [5], we noticed periodic requests for 80 port. If you ban such requests at the firewall level, then some functions stop working — for example, sending mail. The problem with revoked certificates is that there are already a huge number of them: in 2013 there were about 3 million revoked certificates [6], 23,000 revoked Symantec certificates only in 2018 [7]. Chrome disabled the default feature of fully validating revoked certificates a few years ago [8] to increase the speed of loading pages. It turns out that if our postman will be found, the process of further preventing his actions will be long and not always successful.

Conclusions

The modern SSL system is partially closed and centralized, which is definitely one of its weaknesses. While it is so, there will always be a temptation for hackers to get benefits from it, without prioritizing privacy of users. People will still create their own encryption algorithms at the national level, in an attempt to fence off other countries from their own citizens, and do it themselves. Key nodes compromising can collapse the entire system as a whole. The increasing entropy and complexity of the system will lead it to an unstable state and eventually to the death of the system.

What is possible? The transition from a closed and centralized SSL system to a more transparent and distributed one, which is not capable of giving the advantages of either side by its nature. Perhaps this will be a solution that looks like something that is implemented by an open blockchain.

PS. SSL protocol has more complex nuances that were not covered in this article. But the level of information was sufficient to reveal one of its weaknesses. Are there any other weaknesses? We’ll see in future articles.

References

  1. [SSL Handshake]
  2. [ZapProxy]
  3. [SSL Pining]
  4. [Certificate Revocation (CRL vs OCSP)]
  5. [Dhound]
  6. [An Evaluation of the Effectiveness of Chrome’s CRLSets]
  7. [23,000 Symantec certificates revoked following leak of private keys]
  8. [Enabling Certificate Revocation Checks in Google Chrome]

Denis Koloshko — CISSP, CEO at Dhound

Dhound Security Solution

Written by

Dhound - Intrusion Detection System for internet facing servers