太戏剧了，昨晚看了佳片有约，还不错，2012版的《完美回顾》，像我这样的人依旧选择用电视或者去影院看电影，在没有中间插播广告的时候，体验憋尿得过程中，总是能突然有非常多的想法，这是用电脑或者手机看电影所体会不到的。看完以后已经12点半了，突然想再看一遍《黑客帝国》，这下不用电脑不行了，因为电视上没得播...结果正在缓冲的时候，突然看到了旁边的小公告：“OpenSSL再爆严重安全漏洞--CCS注入”，完了，电影看不成了，不是说不想看了，突然感觉自己比神还无耻，怎么人家曝出漏洞会这么高兴啊，关掉已经缓冲完毕的电影，就想看一下OpenSSL的笑话，同一时候心里还极度扭曲地想，我不近期在搞基于OpenSSL的一个改动么，向OpenSSL这样的代码，就我这样的垃圾coder配得上它，因为我的垃圾代码和它非常般配...
       当我看了一篇博客《How I discovered CCS Injection Vulnerability (CVE-2014-0224)》后，我认为我错怪OpenSSL了，这次或许真的不是OpenSSL的错，而是RFC的错，即这次的这个漏洞不是实现问题，很多其它的是协议本身的设计问题。假设你还没有读过上面我提到的那篇博客，一定要看一下，假设看过了，我们就接着往下走，看看这个漏洞的一些细节。
       我们知道，OpenSSL协议分了两个层次，一个是记录协议层，一个是数据协议层，后者包括了握手协议，告警协议，CCS协议等，注意这个“等”字，搞知道国密标准的应该知道这个等字的含义，不知道国密标准的人奉劝永远都不要知道，这次的CCS漏洞本质上就和这个“等”字有关。言归正传，SSL/TLS的安全通道通过握手协议建立，安全通道上通行的数据显然是加密的，而在握手过程中，在密钥等安全參数没有协商完毕之前，数据都是明文的，那么在握手状态机中就肯定有那么一个点，在该点之前数据是明文的，而在该点之后数据是加密的，这个点就是接收到ChangeCipherSpec消息，问题是，这个消息在握手状态机中交换，可是却不在握手协议中定义，它被定义为一个单独的协议，不属于握手协议。这样做的理由，依照漏洞发现者Masashi Kikuchi在RFC挖掘出的理由那就是：

Note:          To help avoid pipeline stalls, ChangeCipherSpec is
                 an independent SSL Protocol content type, and is not
                 actually an SSL handshake message.
这是一个什么理由？显然没有考虑安全因素。那么问题就来了，既然CCS独立于握手状态机，那么它便能够在握手过程中的不论什么一点收发，在协议层面并没有强制CCS必需要在master keys在握手协议中已经完备的情况下才干发送，假设那样强制，就是两个协议之间的交叠。其实，依照规范而言，SSL/TLS的握手中，CCS的位置是被严格规定的，即master keys准备好之后，Finish消息之前，那么安全机制就必须由实现者自己负责。稍有不慎，关于握手协议和CCS之间的关系就会处理不好造成能够利用的漏洞。在一篇文章《Early ChangeCipherSpec Attack 》中，作者披露了OpenSSL1.0.1h是怎样解决问题的，实际上加了不多的几行代码，当中之中的一个就是ssl3_do_change_cipher_spec函数中的一个推断：

if (s->session == NULL || s->session->master_key_length == 0){/* might happen if dtls1_read_bytes() calls this */SSLerr(SSL_F_SSL3_DO_CHANGE_CIPHER_SPEC,SSL_R_CCS_RECEIVED_EARLY);return (0);}

在之前的漏洞影响的版本号中，并没有确认master_key_length不为0，这就意味着即便master key还没有准备好，也是能够发送CCS的，而这样的话，所谓的密钥也没有秘密可言了。CCS的发送时间并没有强制要求，可是要求master keys必须准备好！以下是一个基于中间人攻击的漏洞利用场景，中间人在作为server的时候，在ServerHelloDone完毕后即发送一个CCS，注意此时还没有生成master keys，因此使用一个空值取代，因为OpenSSL在收到CCS的时候并没有检查自己的握手状态机处于哪一步骤，因此会无条件接收，此时它也没有master key，后面的事情就是使用不是密钥的密钥对数据进行加密，注意，因为OpenSSL的实现原因，仅仅要已经经过了key的计算，在一个session中以后就不会再次计算，因此以下的代码(相同处于ssl3_do_change_cipher_spec中)其实助长了漏洞：

if (s->s3->tmp.key_block == NULL){if (s->session == NULL){/* might happen if dtls1_read_bytes() calls this */SSLerr(SSL_F_SSL3_DO_CHANGE_CIPHER_SPEC,SSL_R_CCS_RECEIVED_EARLY);return (0);}s->session->cipher=s->s3->tmp.new_cipher;if (!s->method->ssl3_enc->setup_key_block(s)) return(0);}

关于SSL/TLS规范中将CCS设计成独立的一个数据协议，我在《TCP/IP协议族》这本经典教材中找到了更真切的理由，那就是它将发送方和接收方切割成了两个状态，依照分权原则，这个事不能在握手协议本身完毕。
    漏洞发现者Masashi Kikuchi所述，仅仅要保证几点就可以，非常easy：

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 receives CCS before Finish.

More precisely, when accepting CCS, you must verify the following three conditions (*):

the handshake proceeds to the proper phase, i.e., just before to receive Finished,
    no fragments from the handshake remains,
    and, the next message is Finished.

Being more careful, you should also check

no Alert fragment remains (they can be rejected in the first place),
    and, no Heartbeat fragment remains

事实非常easy，保证CCS发送的时候，master keys真的已经准备好了，这实际上就是CCS本身的意思，假设我能跟我的三岁的小小讲清楚这个，她肯定会说她的口头禅：难道不是吗？
       一个独立的CCS协议，独立于握手协议的CCS协议，在SSL/TLS中必定不可能是全然独立的，协议封装上是独立的，语义却不可能是独立的，否则，我在ClientHello后发送一个CCS，可否？唉，心病还未痊愈，CCS又来捣乱，假设说心脏出血是OpenSSL的问题的话(它实际上是一个低级的代码级错误)，CCS漏洞则是一个协议层面的问题，这个问题可不低级！我相信不止OpenSSL的实现会有这个问题。

我不再吐嘈了，可是我想澄清互联网时代系统两种死法的不同之处，对于安全而已，死法也仅仅有两种，我举一个现实中的样例，一种是生病或中毒而死，一种是外力置死，比方车祸，地震，或者被砍死，这两种本质是不同的，第一种是你自身出了问题，另外一种则是外部原因导致。映射到互联网，对于password被破解，CCS漏洞之类的，这就是第一类的，这类问题一般都是系统本身的设计问题，而对于像栈溢出，Heartbleed，堆溢出之类的，则属于第二类，这类问题一旦碰到，非常公平，可是不属于系统设计的问题，仅仅是实现问题。再说一下现实世界，即便吃再安全的食品，也怕菜刀，可是能够请保镖，武夫之流能挡刀，可是终于可能会因为吃了太多的不健康的油而致癌...

做个广告，最好的筛子：OpenSSL