OpenSSL exposes the CCS injection vulnerability again.

It's a drama. I saw a movie with an appointment last night. It's not bad. In the 2012 version of "perfect memories", people like me still choose to watch movies on TV or in the cinema. When there are no intermediate advertisements, there are always a lot of things that you can think about when you try to urgency. This is something you don't know when you watch a movie on your computer or mobile phone. After reading the video, I have been watching the "hacker Empire" at. I suddenly want to watch it again. I don't need a computer anymore, because I didn't have to play it on TV... when the results were buffering, they suddenly saw a small announcement: "the serious security vulnerability of OpenSSL -- CCS injection". When it was over, the movie couldn't be seen, not to say they didn't want to watch it, suddenly, I felt more shameless than God. How could people be so happy to discover the vulnerability? I wanted to watch the OpenSSL joke when I turned off the movie that had already been buffered. At the same time, I thought it was absolutely distorted, I am not working on a recent modification based on OpenSSL. To use OpenSSL code like this, I am a spam coder to deserve it, because my spam code is perfect for it...
Note: To help avoid pipeline stils, ChangeCipherSpec is
What is the reason? Apparently, security is not taken into account. The problem arises. Since CCS is independent of the handshake state machine, it can send and receive data at any point during the handshake process, at the protocol level, it is not mandatory for CCS to be sent only when the master keys have been completed in the handshake protocol. If so, it is forced to overlap the two Protocols. In fact, according to the specification, in the SSL/TLS handshake, the location of the CCS is strictly specified, that is, after the master keys are ready, before the message is completed, the security mechanism must be the responsibility of the implementer. A little careless, the relationship between the handshake protocol and CCS will be difficult to handle, resulting in usable vulnerabilities. In an article Early ChangeCipherSpec Attack, the author discloses how OpenSSL1.0.1h solves this problem. In fact, a few lines of code are added, one of which is a judgment in the ssl3_do_change_cipher_spec function:
If (s-> session = NULL | s-> session-> master_key_length = 0) {/* might happen if dtls1_read_bytes () CILS this */SSLerr (SSL_F_SSL3_DO_CHANGE_CIPHER_SPEC, ssl_r_ccs_inclued_early); return (0 );}
If (s-> s3-> tmp. key_block = NULL) {if (s-> session = NULL) {/* might happen if dtls1_read_bytes () CILS this */SSLerr (delimiter, ssl_r_ccs_inclued_early ); return (0);} s-> session-> cipher = s-> s3-> tmp. new_cipher; if (! S-> method-> ssl3_enc-> setup_key_block (s) return (0 );}
IMHO, this sentence is the very cause of the vulnerability. according to it, the reason that CCS is assigned an independent record type is to avoid a stall. this is the point where the most complex synchronization is required in TLS/SSL handshake. first, you need to wait until the handshake proceeds to the proper phase. then, you need to check whether the handshake slaves es CCS before Finish.
The fact is very simple. When the CCS is sent, the master keys are actually ready. This is actually what CCS means. If I can tell this to my three-year-old girl, she will definitely say her mantra: Isn't it?
I don't want to talk about it anymore, but I want to clarify the differences between the two methods of death in the Internet age. For security, there are only two methods of death. I will give a real example, one is death due to illness or poisoning, and the other is death due to external force, such as a car accident, earthquake, or hacked. The two are essentially different, the first is your own problem, and the second is caused by external reasons. Maps to the Internet. For password cracking, CCS vulnerabilities, and so on, this is the first type. These problems are generally system design problems, and for Stack Overflow, Heartbleed, stack Overflow is the second type. Once such problems are encountered, they are fair, but they are not system design problems, but implementation problems. In the real world, even food that is safe can be used as a kitchen knife, but you can ask the guard and the husband to block the knife, but in the end, it may be caused by eating too much unhealthy oil...

Make an advertisement, the best Screening: OpenSSL