Shulou(Shulou.com)06/01 Report--

After OpenSSL's heart bleed, I believe a lot of people bled and shed tears. A large number of articles or jokes about spitting OpenSSL appeared on the Internet, as if the anger in my heart had been released in an instant. With this madness, I also spit it out. With the humiliation of snow being ravaged by OpenSSL all these years, maybe I can show my ignorance and ignorance by the way, but only maybe.

First of all, I do not mean to maliciously slander, nor do I aim at anything. Compared with the joys and sorrows in life, the ups and downs at work, and the ups and downs in the pursuit of ideals, OpenSSL's torture is actually a kind of happiness, only an interpretation of happiness, sometimes it can be regarded as painful and happy, Qi Qin said.

The OpenSSL code really sucks, it sucks, it's out of order.

Pragmatists, or people who have been poisoned, can always give a reason why a piece of code is written in this way and not so much, and the reason is so good that you will think that there is a reason to write it this way and write it so badly. There must be something difficult to understand. However, as a non-theological secular work, it is not a Bible, and it is a fault that it is not easy to understand. Maybe my level is too lame to reach the depth required by OpenSSL. If so, this post is for rookies at the same level as me. Master please leave silently, don't take away a little sadness, leave these sorrows, let us rookie tears wash away. Existence is reasonable, well, the myth of Sisyphus says that life is a sorrow, the harvest is not equal to the cost, it exists, so it is reasonable, please do not complain about OpenSSL, it is also reasonable, yes, absolutely correct.

Open source is great, or at least used to be great. Those who question it must not have experienced the excitement and masochistic passion of Linus Torvalds, nor do they necessarily have the awe and emotion of standing at the feet of Richard Stallman or the extreme Eric S. Raymond. But after the emergence of OpenSSL, it shows that the freedom of expression of open source has another meaning, that is, the code has the freedom to be uncensored, there is bad freedom, what's more, everyone has the freedom to use bad code, and what's more, everyone has the freedom to turn bad code into art, and this freedom, incited by the black wing of OpenSSL, brings it to everyone, so when the heart bleeds. I clenched my fist.

If you talk too much, you will cry. Suddenly I saw a project. OpenBSD launched a project to clean up OpenSSL code and wanted to continue to cry. After reading this post, please enjoy it with tears. The link is below:

Refreshing Link 1

Refreshing Link 2

It is also worth admiring that the code of Open × × is also rotten! Before you enjoy the link, please let me throw a brick and have a piece of cake. Let's get started!

If a function is declared to return int data, but in its implementation:

{if () return ret; else if () return ret2;} is this reasonable? The code is correct, of course, but it's not clear. Not only do people not see it clearly, but some compilers also complain. There is a lot of this kind of code in OpenSSL, but sadly, not all OpenSSL code is like this!

I know that when using pointers, judging whether it is NULL can prevent SIGSEGV from being sent, but if you can make it clear that it is not NULL, it will be superfluous, otherwise this judgment will be everywhere. What does the large number of redundant non-NULL judgments in OpenSSL indicate? I will continue to think hard.

I learned to use magic words without learning, which made the code I wrote instantly understandable. When I looked at OpenSSL, I found that magic words, if used properly, could play the function of encryption. OpenSSL defines so many variables and combinations of variables that the whole OpenSSL is doing "when to assign variables to whom". Pragmatists and hindsight guys will say, have to do this, OpenSSL has no choice! Maybe, OpenSSL has no choice, but other libraries that also implement SSL have too many choices! In addition, I used to like to use int variables to control logic, such as

For (...) {if () {flag = 1;}... If (flag2 = = 2) {flag = 2;} if (flag = = 3 | | flag2 = = 1) {...} I used to make a painful choice between magic words and flags, because I TMD didn't understand software development at all. I naively thought that software development was programming, that is, to make the code run, until I saw OpenSSL and found that all software development had to do was to make the code run that simple! OpenSSL can run! As mentioned earlier, OpenSSL defines too many variables, but not enough, because there are if (var = = 2), var2=3,var3 everywhere.

< 5，之类的代码，2，3，5代表什么意思呢？OpenSSL的注释同样很多，但是还不够多，该有的注释没有，晦涩的地方一般都是jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj 请注意以下代码，它展示了C语言块的本质，并非一定要是一个完整的函数，完整的条件判断逻辑，完整的循环逻辑，我觉得这种教人什么是"C语言块"的方式只能存在于谭浩强的书中，但OpenSSL做得更好： some_function(...){... return(n); } /* If we get here, then type != rr->

Type; if we have a handshake * message, then it was unexpected (Hello Request or Client Hello). * / * In case of record types for which we have 'fragment' storage, * fill that so that we can process the data ata fixed place. * / {unsigned int dest_maxlen = 0; unsigned char * dest = NULL; unsigned int * dest_len = NULL; if (rr- > type = = SSL3_RT_HANDSHAKE) {dest_maxlen = sizeof s-> S3-> handshake_fragment; dest = s-> S3-> handshake_fragment; dest_len = & s-> S3-> handshake_fragment_len }. Is it comfortable to clip a block in the middle of the function? Maybe it's because the author uses different C standards, wants to declare new variables, doesn't want to move the original code, compiles without adding new blocks, but has no choice but to play like this. But it's only possible. in fact, the author may not think so much at all, and I personally like to do it, sometimes my idea is to try a new idea, if not, it is convenient to return to the original, and I hate to use macros. The main reason is that the typing cost is too high. In fact, until not long ago, I knew that in a block, the position of variable declaration can not be random, of course, the standard is different. The restrictions are also different.

Macros in C language are a good thing, but they can also cause bloodshed. A few years ago, one of my managers said at a meeting that he would use a large number of macros to create some different compilation results. Later, because those macros created a terrible macro hell, we had to work overtime every week, and then another colleague of mine beat the leader, right in the office. I don't know if it has something to do with a lot of macros. I really don't know. Just ask you to read the following code, do you want to hit someone?

# define ARGV Argvintmain (int Argc, char * ARGV []) what is the artistry of doing this? I will continue to struggle up and down.

There are a large number of # if 0 in the OpenSSL code, and there are the following strange things, the comments are all masked by the macro definition, and the compiler is confused. The first line of the comment can be seen as a comment, but the * / can't be found. Oh, I see. The latter part of the comment is obscured by the macro # if 0.

# if 0 / * worked only because C operator preferences are not as expected (and * because this is not really needed for clients except for detecting * protocol violations): * / s-> state=SSL_ST_BEFORE | (s-> server)? SSL_ST_ACCEPT: SSL_ST_CONNECT;#else s-> state= s-> server? SSL_ST_ACCEPT: SSL_ST_CONNECT;#endif pays attention to the "(and" in the first line of the note above, and can see that the author did this on purpose to show his cubism.

OpenSSL has no consistent style, whether it's indentation or the code itself, or even in a function, like this:

Int func () {... If I write this kind of code, I will be scolded again, but slowly, I don't think it's painful to be scolded for it, just like OpenSSL regards self-abuse as a source of pleasure!

If I hadn't scratched off the business part of the following code, it could definitely participate in IOCCC. In fact, the process of picking business code is painful, and it doesn't have the pleasure of solving cattle at all. On the contrary, it's as painful as picking your ass.

Some_function (...) {... If (s-> session- > sess_cert! = NULL) {# ifndef OPENSSL_NO_RSA if (s-> session- > sess_cert- > peer_rsa_tmp! = NULL) {.} # endif.} else {. }... # ifndef OPENSSL_NO_RSA if (alg & SSL_kRSA) {...} # else / * OPENSSL_NO_RSA * / if (0) # endif#ifndef OPENSSL_NO_DH else if (alg & SSL_kEDH) {... # ifndef OPENSSL_NO_RSA if (alg & SSL_aRSA)... # else if (0); # endif#ifndef OPENSSL_NO_DSA else if (alg & SSL_aDSS)...; # endif / * else anonymous DH, so no certificate or pkey. * /...} else if ((alg & SSL_kDHr) | | (alg & SSL_kDHd)) {. Goto fancier;} # endif / *! OPENSSL_NO_DH * / # ifndef OPENSSL_NO_ECDH else if (alg & SSL_kECDHE) {. If (0); # ifndef OPENSSL_NO_RSA else if (alg & SSL_aRSA)...; # endif#ifndef OPENSSL_NO_ECDSA else if (alg & SSL_aECDSA)...; # endif / * else anonymous ECDH, so no certificate or pkey. * /...} else if (alg & SSL_kECDH) {. Goto fancier;} # endif / *! OPENSSL_NO_ECDH * / if (alg & SSL_aFZA) {. Goto fancier;} / * p points to the next byte, there are 'n' bytes left * / / * if it was signed, check the signature * / if (pkey! = NULL) {. If ((I! = n) | | (n > j) | | (n type = = EVP_PKEY_RSA) {... For (num=2; num > 0; num--) {.}. If (I)

< 0) { ... goto f_err; } if (i == 0) { /* bad signature */ ... goto f_err; } } else#endif#ifndef OPENSSL_NO_DSA if (pkey->

Type = = EVP_PKEY_DSA) {/ * lets do DSS * /. If (EVP_VerifyFinal (& md_ctx,p, (int) n int pkey) type = = EVP_PKEY_EC) {/ * let's do ECDSA * /. In fact, there are only two ways to play well with if (0). The first is to use macros to block if (0), and the second is to use goto to rape if (0), but there is another way to change the meaning of if (0). The existence of a large number of # if 0grammes if 1jie if (0), if (1), plus some notes that make people see "the world is improving", have turned OpenSSL into a zombie museum, and there will be notes next to these codes that will never be executed, explaining how they used to be brilliant and why they became mummies a few days ago. But why not delete them directly? Now that we know that they are useless and why they are useless and still keep them, I think the authors are nostalgic. This makes us newcomers have to preprocess before reading or changing the code. Personally, I don't like preprocessing. I delete the code that will never be executed by hand. I even regard it as a pastime when I am bored, and get the pleasure of sublimation as much as an afternoon exhibition of the Windows registry! I really did show the registration form, and I didn't finish it all afternoon.

Three years ago, I made extensive use of the following code in an engine in OpenSSL:

Do {... if (...) Break;...} while (0); I was called shit for this kind of code, but I wasn't angry at that time. Instead, I snickered with another colleague. I heard that laughter can live a long life. I think I'll have to look at the OpenSSL code in the future.

Laughter is good, but crying is another way to relieve stress, which is sometimes better than laughter. But just the above still can't make me cry. What makes me cry is the implementation logic of a piece of code. Here's the thing. Although Laozi is not a master, at least he works hard as a programmer to record it. Being ravaged by OpenSSL is really unspeakable bitterness.

SSL data is left-type, that is, it has no boundary, unlike Datagram protocol, at the bottom, SSL recording protocol is encapsulated in a recode block, it can be considered that SSL has a boundary at the bottom, but at the upper layer, like TCP, it has no boundary. But I happen to use it to transmit IP datagrams with boundaries, and the SSL_write/SSL_read interface of OpenSSL does not expose the concept of SSL record. How I wish SSL_write would send the incoming buff as a record at a time, while SSL_read would only return one record data to the caller at a time. However, there is no standard that it should do so, so I can't expect OpenSSL to be implemented in this way.

Fortunately, OpenSSL is open source, and the code can be seen for yourself, RTFSC! As the great god Linus said. But look at the implementation of ssl3_write_bytes:

Int ssl3_write_bytes (SSL * s, int type, const void * buf_, int len) {. N = (len-tot); for (;;) {if (n > SSL3_RT_MAX_PLAIN_LENGTH) nw=SSL3_RT_MAX_PLAIN_LENGTH; else nw=n; / / I think this is a core function i=do_ssl3_write (s, type, & (buf [tot]), nw, 0); if (iS3-> wnum=tot; return I } if ((I = = (int) n) | | (type = = SSL3_RT_APPLICATION_DATA & & (s-> mode & SSL_MODE_ENABLE_PARTIAL_WRITE) {/ * next chunk of data should get another prepended empty fragment * in ciphersuites with known-IV weakness: * / s-> S3-> empty_fragment_done = 0 Return tot+i;} n murmur I; tot+=i;}} what do ordinary people think when they see this code? Of course, those people who are deeply poisoned by OpenSSL do not belong to ordinary people. Most people will think that a buff may be divided into multiple messages, so there is a for ( ), until the end of sending, if the behavior of the interface is well defined, I should give up hope, because according to the above implementation logic, a buff may be divided into multiple segments, and each segment is called do_ssl3_write to send, so that a buff will form multiple record, thus breaking my fantasy. At this time, I want to cry, because I have to fuck the guy again and stir shit. Oh, what a painful understanding, what a straightforward statement.

Fortunately, there are experts to help me, tell me, in theory, should be a write to construct a record, my divine worship of this person prompted me to go deep into the do_ssl3_write function, and then I sneezed, blink tears, snot sucked into my throat, salty, but not bitter.

Static int do_ssl3_write (SSL * s, int type, const unsigned char * buf, unsigned int len, int create_empty_fragment) {unsigned char * pLegen; int iMaxime; int prefix_len = 0; SSL3_RECORD * wr; SSL3_BUFFER * wb; SSL_SESSION * sess; / * first check if there is a SSL3_BUFFER still being written * out. This will happen with non blocking IO * / if (s-> S3-> wbuf.left! = 0) / / in the first place, the processing logic is hijacked, so I have to pay attention to when left does not jump strangely for 0 / / this execution flow! It's so weird! Return (ssl3_write_pending); / * If we have an alert to send, lets send it * / if (s-> S3-> alert_dispatch) {iS3-> method- > ssl_dispatch_alert (s); if (IS3-> wrec); wb= & (S3-> S3-> wbuf); sess=s- > session;. If (clear) mac_size=0; else mac_size=EVP_MD_size (s-> write_hash) / * 'create_empty_fragment' is true only when this function calls itself * / if (! clear & &! create_empty_fragment & &! S3-> empty_fragment_done) {/ * countermeasure against known-IV weakness in CBC ciphersuites * (see http://www.openssl.org/~bodo/tls-cbc.txt) * / if (s-> S3-> need_empty_fragments & & type = = SSL3) _ RT_APPLICATION_DATA) {/ * recursive function call with 'create_empty_fragment' set * this prepares and buffers the data for an empty fragment * (these 'prefix_len' bytes are sent out later * together with the actual payload) * / / Recursive call? I kao, this function actually has two pieces of logic: / / 1. Silently create a new record; / / 2. Create a record that encapsulates buf and send prefix_len = do_ssl3_write (s, type, buf, 0,1) together with the record created silently in the recursive call; if (prefix_len S3-> wbuf.len

< (size_t)prefix_len + SSL3_RT_MAX_PACKET_SIZE) { /* insufficient space */ SSLerr(SSL_F_DO_SSL3_WRITE, ERR_R_INTERNAL_ERROR); goto err; } } s->

S3-> empty_fragment_done = 1;} / / wb- > buf is a sending buf bound with SSL. It's generous to malloc the memory beforehand. / / A prefix_len indicates the silently created record immediately before the real record is sent. The caller does not know / / will create and send such a record p = wb- > buf + prefix_len; / * write the header * / / this code is fairly clear / / but remember that it will be here twice if empty fragment is needed * (packs +) = type&0xff; wr- > type=type * (paired +) = (s-> version > > 8); * (paired +) = s-> version&0xff; / * field where we are to write out packet length * / plen=p; pendant 2; / * lets setup the record stuff. * / wr- > data=p; wr- > length= (int) len; wr- > input= (unsigned char *) buf; / * we now 'read' from wr- > input, wr- > length bytes into * wr- > data * / / * first we compress * / if (s-> compress! = NULL) {if (! ssl3_do_compress (s)) {SSLerr (SSL_F_DO_SSL3_WRITE,SSL_R_COMPRESSION_FAILURE) Goto err;}} else {memcpy (wr- > data,wr- > input,wr- > length); wr- > input=wr- > data;} / * we should still have the output to wr- > data and the input * from wr- > input. Length should be wr- > length. * wr- > data still points in the wb- > buf * / if (mac_size! = 0) {s-> method- > ssl3_enc- > mac (p [wr-> length]), 1); wr- > length+=mac_size; wr- > input=p; wr- > data=p;} / * ssl3_enc can only have an error on read * / s-> method- > ssl3_enc- > enc (sMagne1) / * record length after mac and block padding * / s2n (wr- > length,plen); / * we should now have * wr- > data pointing to the encrypted data, which is * wr- > length long * / wr- > type=type; / * not needed but helps for debugging * / wr- > length+=SSL3_RT_HEADER_LENGTH; if (create_empty_fragment) {/ * we are in a recursive call * just return the length, don't write out anything here * / / if it is the record created silently, it is not sent directly. The purpose is to send the real record in memory / / immediately following the silently constructed record to the lower layer BIO as a buffer. Why not send two / / record separately? I think it's for compact use of SSL's S3-> wbuf buffer, which was built beforehand, and / / it's not small: 16Kbits! Alas, I really don't think the implementer can think of a better way, return wr- > length;} / * now let's set up wb * / wb- > left = prefix_len + wr- > length; wb- > offset = 0; / * memorize arguments so that ssl3_write_pending can detect bad write retries later * / S3-> wpend_tot=len; s-> wpend_buf=buf; s-> S3-> wpend_type=type; s-> S3-> wpend_ret=len / * we now just need to write the buffer * / return ssl3_write_pending (sMagnetypeDibufLen); err: return-1;} the above function calls are executed before the last return ssl3_write_pending (srecamenttypedbufjlen), you will get the following buffers with a total wb- > left size:

| | empty record header | empty record data | real record header | real record data | |

The final buff is constructed, ready to send, OK, ready to send! But the underlying mechanism has come to find fault again. In non-blocking IO mode, the underlying BIO does not necessarily guarantee that it will return as much data as wb- > left. The key is to return to the ssl3_write_bytes function, that is, the for ( ) call the function of do_ssl3_write, and then a lot of if judges, either continue or return to SSL_write directly. Anyway, the next time you call the do_ssl3_write in ssl3_write_bytes, as long as the two record are not finished, that is, if the S3-> wbuf.left of SSL is not 0, ssl3_write_pending will be called directly at the beginning of the do_ssl3_write to ensure that a record is written.

The whole problem is that do_ssl3_ write is too complicated and does too many things. It does three things: 1. Construct empty fragment;2. Construct real record;3. Make sure that these two record are sent. The logic is so complicated that all kinds of jumps are invited. Before giving the logic that I think is reasonable, let's briefly talk about what empty fragment is. It is actually a bug repair, that is, for the CBC IV * *, the empty frag mechanism sends an empty frag record before sending record, and some useless data inside the receiver can be processed arbitrarily after decryption in the SSL protocol layer. Its purpose is to insert some random factors in the data to increase the difficulty of IV guessing in CBC mode.

I don't understand why the last unfinished data should be placed so deep, and I don't understand why recursion should be used. Can't you encapsulate a function of build_record? Can't you encapsulate a write_raw function? Since empty fragment is a security hardening mechanism, why hide it? Directly:

Build_record {manipulate S3-> wbuf of SSL. I think it's good, so continue to use} write_raw {write to the lower layer BIO to write a certain segment of SSL S3-> wbuf.buf} do_ssl3_build {if (need_empty) {build_record;} build_record;...}. Is this clearer than recursion? As for the for (;;), I keep it, just modify the ssl3_write_bytes

Ssl3_write_bytes {if (left) {write_pending} do_ssl3_build for (;;) {write_raw;}} you can you up,no can no BB! I'm afraid there's no place to die, so that's the end of the subject, who can who up! But I want to say one thing, that is, the implementation of polarssl, take a look at other people's ssl_write interface:

Ssl_write () {if (ssl- > state! = SSL_HANDSHAKE_OVER) {handshack;} if (left) {flush_pending and return

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.