Weak HTTPS. Part 2
Any system has its strengths and weaknesses. The first part about HTTPS weaknesses caused an ambiguous reaction that “these are not weaknesses, it was intended to be so.” The first part said:
I will continue to call this the “weaknesses” of design. In this article we will talk about another weakness - 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 centrality of the SSL protocol.
We should start with the theory of encryption protocols. The problem of modern cryptography is not in the encryption itself, but in what to do with keys: how to store, transfer, create and destroy them safely.
The basis of SSL is asymmetric encryption , which is determined by the presence of two keys - if one is encrypted, then only the second can be decrypted, and vice versa.
The main function of asymmetric encryption is authentication ; by no means encryption is a rather resource-intensive and expensive operation for 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 side to confirm its identification, it is called private . Public key is available to all.
Imagine that there is a village of the future in which Boris and Anya live. In the future, the keys of a different size, algorithms are more stringent, and the capabilities of the brain are disproportionate to the modern ones, but the approach, let’s say, remains the same.
Boris and Anya want the confidentiality of their love correspondence, so the most important thing for them is the secure exchange of information.
In the simplest case, Boris sends Anna a message: "let's talk." Anya generates two pairs of asymmetric encryption keys - private Pr1 and public P1. “Come on,” says Anya, “I'm Anya, here is my public key, here is the symmetric encryption algorithm that I know.” Boris generates the symmetric key S1, encrypts it with the public key Ani P1 (S1). Now S1 cannot even decrypt Boris himself, because only Anna can decrypt the message with her private key. In the end, Boris and Ani appear with a symmetric session key in order to “ensure” a reliable transfer of letters to each other and prevent parents from reading their correspondence.
I didn’t deliberately reduce this messaging, in fact, we described SSL Handshake with one-way authentication [1]. On the two-way side, Boris generates his key pair and sends the public key to Anya.
An important conclusion that we can already do. Of the three main functions of the SSL protocol (authentication, encryption, integrity), the most important is authentication.
Everything is fine, until the postman appears, offended at life, who is fond of reading other people's letters, in addition also clever. Between Boris and Anya, the question arises how to guarantee now that the postman cannot read their messages. The answer is no way. The postman can generate his own pair of keys, expose Boris his “supposedly” key from Ani, organize two encrypted channels and calmly read letters.
To solve the dilemma can only the presence of a certain third party who can guarantee that the P1 key belongs to Anya. Imagine that a village council appears in the village, which keeps a register of residents' public keys. Anya can take her passport, her public key P1, come there and ask for registration. Boris, when he gets P1 from Ani, can go to the same village council and check the register. If the key does not match, you can begin to sin on the postman and accuse him of all serious, although he may go into denial. But the problem is solved.
Not kamilfo, of course, Boris to be dragged every time to the village council. Therefore, the same authentication can be performed with the village council itself. The village council now calls itself the Certification Authority (CA) and has its own pair of keys P10 and Pr10. When Anya comes in with a passport and her public key, CA issues something like a card, which indicates that it is Anya, she owns the public key P1, some other information, up to the passport number, and adds another field for her signatures: takes all the information from the card, removes the hash from it, and encrypts it with its private key, and calls it a digital signature. It would be possible to do without a hash, but then the signature was too big. And CA now calls this card a certificate.
Now Anya to exchange love messages with Boris sends him not just her name and public key, but her certificate. Boris will have to go to the village council only once, and ask them for their public key. Any information that this key can decrypt will be considered as a priori information encrypted by the village council. The postman does not know at all what to do, he is covered by an existential vacuum, he has only one thing left to do - try to find the village council’s private key so that life will return to normal.
But life does not stand still. Boris has another girlfriend in the next village, then another. He has to add the keys of other village councils to his trusted, begins to keep his registry with public keys of certification authorities. Then it acquires a national and supranational scale. There are so many organizations that sign certificates that they begin to form a hierarchy. Root Certification Authorities appear that do not sign certificates of mere mortals, but sign only Intermediate Certification Authority certificates after their verification. Boris now only needs to store the public keys of the root certificates. And from Anya he receives not only her certificate, but also certificates of intermediate centers,
The system becomes more complex and centralized , and from this point on, the postman again has a chance.
On the one hand, Boris initially had a small list of root certification authorities (Windows prescribes about 50 root certification authorities 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 verify that for some reason the certification center of another country is indicated in the certificate from Ani from his village. He trusts his list of root centers at 99.9 percent. The postman can go on the most brutal way, and somehow (social engineering, hacking with penetration) register his fake root certification authority in the registry of Boris.
Ps.This method of adding a fake root root certificate is actively used by both pentesters (like me) and intruders. To test for penetration and use this approach, my favorite tool is ZapProxy (free and open source), which will generate a root certificate (it will need to be manually installed), and then replaces the real one with a “similar” certificate on the fly. This allows you not only to view the traffic, but also to stop it, change it and send it further. Therefore, if validation in your system is not duplicated on the server, then you definitely have problems.
Pps.The second problem, which was raised in this case, concerns Anya and the indication in her certificate of an incomprehensible center. Anya paid the money, and would like Boris to recognize her anyway. This problem is solved by using SSL Pinning [3], when the application can be assigned trust only to a specific certificate and certain certificate authorities. This especially makes sense for high-risk applications. With browsers it is more difficult, for mobile applications that work with one or two services, simpler. For the sake of experiment, I put a fake certificate on my Android, indicated that the traffic went through ZapProxy, which is stuck on the network on my machine, and looked at how many applications use this mechanism. Almost no one, I was able to watch and play around with the substitution of traffic with almost all popular applications.
So back to our postman. The government could not fail to appreciate his zeal and gave him the status of a secret agent with higher powers. Although private keys of root certification centers are stored under seven locks, self-burning discs, multi-level protection - even the postman’s authority may not be enough to agree with them to provide him with his private key to generate fake valid certificates on the fly (although everything is possible). He found a simpler way. He goes to his village council, which is in the hierarchy of certification centers at the lowest level, and pushes or bribes the village council to sign its certificate, like a certificate from an intermediate certification authority. Now he can listen to the traffic not only of Boris, but in principle of any subject. The person most likely will not even notice anything
This is a known problem, and humanity is also trying to fight it. When such fake certificates are detected, compromised intermediate and root centers, these certificates should be marked as revoked (Revoked Certificates). This means that, in addition to storing root certificates, Boris still needs to constantly synchronize them with the online certificate revocation list — this mechanism is implemented through the CRL (certificate revocation list) and Online Certificate Status Protocol (OCSP) protocols [4], which, by the way, work on unprotected channel. When we began to actively work on controlling OUTPUT traffic using Dhound [5], we noticed periodic requests for port 80. If you ban similar 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: for 2013, there were about 3 million revoked certificates [6], 23000 certificates withdrawn by Symantec only in 2018 [7]. Chrome turned off the default feature of full validation of revoked certificates several years ago [8] to increase the speed of loading pages. It turns out that if our postman is discovered, the process of further preventing his actions will be long and not always successful.
Modern SSL is partly closed and centralized , which is definitely one of its weaknesses. As long as it is such, there will always be the temptation of the “powerful of the world” to get its benefits from it, without prioritizing the personal privacy of users. It will still create its own encryption algorithms at the national level, in an attempt to isolate other countries from their own citizens, and to do it themselves. Compromise key nodes can bring down the entire system as a whole. Increasing entropy and the complexity of the system will increasingly lead her into an unstable state and eventually to the death of the system.
What is the possible exit? The transition from a closed and centralized SSL system to a more transparent and distributed, which is not capable by its nature to give advantages to any of the parties. Perhaps this will be a solution something similar to what the open blockchain implements.
Ps. The SSL protocol has more complex nuances that were not covered in the article. But the level of information was sufficient to reveal one of its weaknesses. Are there any other weaknesses? In the following articles we will see.
The author - Denis Koloshko, CISSP
- About the impossibility to provide full confidentiality and privacy to users (you can still track and ban resources that a person visits)
- That certificates are transmitted over an open channel and often contain more information than the current resource (for example, the bing.com certificate contains information about 72 additional resources, including virgins, test, beta media)
I will continue to call this the “weaknesses” of design. In this article we will talk about another weakness - 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 centrality of the SSL protocol.
Theory
We should start with the theory of encryption protocols. The problem of modern cryptography is not in the encryption itself, but in what to do with keys: how to store, transfer, create and destroy them safely.
The basis of SSL is asymmetric encryption , which is determined by the presence of two keys - if one is encrypted, then only the second can be decrypted, and vice versa.
The main function of asymmetric encryption is authentication ; by no means encryption is a rather resource-intensive and expensive operation for 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 side to confirm its identification, it is called private . Public key is available to all.
Imagine that there is a village of the future in which Boris and Anya live. In the future, the keys of a different size, algorithms are more stringent, and the capabilities of the brain are disproportionate to the modern ones, but the approach, let’s say, remains the same.
Boris and Anya want the confidentiality of their love correspondence, so the most important thing for them is the secure exchange of information.
In the simplest case, Boris sends Anna a message: "let's talk." Anya generates two pairs of asymmetric encryption keys - private Pr1 and public P1. “Come on,” says Anya, “I'm Anya, here is my public key, here is the symmetric encryption algorithm that I know.” Boris generates the symmetric key S1, encrypts it with the public key Ani P1 (S1). Now S1 cannot even decrypt Boris himself, because only Anna can decrypt the message with her private key. In the end, Boris and Ani appear with a symmetric session key in order to “ensure” a reliable transfer of letters to each other and prevent parents from reading their correspondence.
I didn’t deliberately reduce this messaging, in fact, we described SSL Handshake with one-way authentication [1]. On the two-way side, Boris generates his key pair and sends the public key to Anya.
An important conclusion that we can already do. Of the three main functions of the SSL protocol (authentication, encryption, integrity), the most important is authentication.
Everything is fine, until the postman appears, offended at life, who is fond of reading other people's letters, in addition also clever. Between Boris and Anya, the question arises how to guarantee now that the postman cannot read their messages. The answer is no way. The postman can generate his own pair of keys, expose Boris his “supposedly” key from Ani, organize two encrypted channels and calmly read letters.
To solve the dilemma can only the presence of a certain third party who can guarantee that the P1 key belongs to Anya. Imagine that a village council appears in the village, which keeps a register of residents' public keys. Anya can take her passport, her public key P1, come there and ask for registration. Boris, when he gets P1 from Ani, can go to the same village council and check the register. If the key does not match, you can begin to sin on the postman and accuse him of all serious, although he may go into denial. But the problem is solved.
Not kamilfo, of course, Boris to be dragged every time to the village council. Therefore, the same authentication can be performed with the village council itself. The village council now calls itself the Certification Authority (CA) and has its own pair of keys P10 and Pr10. When Anya comes in with a passport and her public key, CA issues something like a card, which indicates that it is Anya, she owns the public key P1, some other information, up to the passport number, and adds another field for her signatures: takes all the information from the card, removes the hash from it, and encrypts it with its private key, and calls it a digital signature. It would be possible to do without a hash, but then the signature was too big. And CA now calls this card a certificate.
Now Anya to exchange love messages with Boris sends him not just her name and public key, but her certificate. Boris will have to go to the village council only once, and ask them for their public key. Any information that this key can decrypt will be considered as a priori information encrypted by the village council. The postman does not know at all what to do, he is covered by an existential vacuum, he has only one thing left to do - try to find the village council’s private key so that life will return to normal.
But life does not stand still. Boris has another girlfriend in the next village, then another. He has to add the keys of other village councils to his trusted, begins to keep his registry with public keys of certification authorities. Then it acquires a national and supranational scale. There are so many organizations that sign certificates that they begin to form a hierarchy. Root Certification Authorities appear that do not sign certificates of mere mortals, but sign only Intermediate Certification Authority certificates after their verification. Boris now only needs to store the public keys of the root certificates. And from Anya he receives not only her certificate, but also certificates of intermediate centers,
Problem field
The system becomes more complex and centralized , and from this point on, the postman again has a chance.
On the one hand, Boris initially had a small list of root certification authorities (Windows prescribes about 50 root certification authorities 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 verify that for some reason the certification center of another country is indicated in the certificate from Ani from his village. He trusts his list of root centers at 99.9 percent. The postman can go on the most brutal way, and somehow (social engineering, hacking with penetration) register his fake root certification authority in the registry of Boris.
Ps.This method of adding a fake root root certificate is actively used by both pentesters (like me) and intruders. To test for penetration and use this approach, my favorite tool is ZapProxy (free and open source), which will generate a root certificate (it will need to be manually installed), and then replaces the real one with a “similar” certificate on the fly. This allows you not only to view the traffic, but also to stop it, change it and send it further. Therefore, if validation in your system is not duplicated on the server, then you definitely have problems.
Pps.The second problem, which was raised in this case, concerns Anya and the indication in her certificate of an incomprehensible center. Anya paid the money, and would like Boris to recognize her anyway. This problem is solved by using SSL Pinning [3], when the application can be assigned trust only to a specific certificate and certain certificate authorities. This especially makes sense for high-risk applications. With browsers it is more difficult, for mobile applications that work with one or two services, simpler. For the sake of experiment, I put a fake certificate on my Android, indicated that the traffic went through ZapProxy, which is stuck on the network on my machine, and looked at how many applications use this mechanism. Almost no one, I was able to watch and play around with the substitution of traffic with almost all popular applications.
So back to our postman. The government could not fail to appreciate his zeal and gave him the status of a secret agent with higher powers. Although private keys of root certification centers are stored under seven locks, self-burning discs, multi-level protection - even the postman’s authority may not be enough to agree with them to provide him with his private key to generate fake valid certificates on the fly (although everything is possible). He found a simpler way. He goes to his village council, which is in the hierarchy of certification centers at the lowest level, and pushes or bribes the village council to sign its certificate, like a certificate from an intermediate certification authority. Now he can listen to the traffic not only of Boris, but in principle of any subject. The person most likely will not even notice anything
This is a known problem, and humanity is also trying to fight it. When such fake certificates are detected, compromised intermediate and root centers, these certificates should be marked as revoked (Revoked Certificates). This means that, in addition to storing root certificates, Boris still needs to constantly synchronize them with the online certificate revocation list — this mechanism is implemented through the CRL (certificate revocation list) and Online Certificate Status Protocol (OCSP) protocols [4], which, by the way, work on unprotected channel. When we began to actively work on controlling OUTPUT traffic using Dhound [5], we noticed periodic requests for port 80. If you ban similar 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: for 2013, there were about 3 million revoked certificates [6], 23000 certificates withdrawn by Symantec only in 2018 [7]. Chrome turned off the default feature of full validation of revoked certificates several years ago [8] to increase the speed of loading pages. It turns out that if our postman is discovered, the process of further preventing his actions will be long and not always successful.
findings
Modern SSL is partly closed and centralized , which is definitely one of its weaknesses. As long as it is such, there will always be the temptation of the “powerful of the world” to get its benefits from it, without prioritizing the personal privacy of users. It will still create its own encryption algorithms at the national level, in an attempt to isolate other countries from their own citizens, and to do it themselves. Compromise key nodes can bring down the entire system as a whole. Increasing entropy and the complexity of the system will increasingly lead her into an unstable state and eventually to the death of the system.
What is the possible exit? The transition from a closed and centralized SSL system to a more transparent and distributed, which is not capable by its nature to give advantages to any of the parties. Perhaps this will be a solution something similar to what the open blockchain implements.
Ps. The SSL protocol has more complex nuances that were not covered in the article. But the level of information was sufficient to reveal one of its weaknesses. Are there any other weaknesses? In the following articles we will see.
Links
The author - Denis Koloshko, CISSP