商城网站策划书,七牛图片怎么上传wordpress博客,html制作网页的软件,艺考有哪些专业太戏剧了#xff0c;昨晚看了佳片有约#xff0c;还不错#xff0c;2012版的《完美回顾》#xff0c;像我这样的人依旧选择用电视或者去影院看电影#xff0c;在没有中间插播广告的时候#xff0c;体验憋尿得过程中#xff0c;总是能突然有非常多的想法#xff0c;这是…太戏剧了昨晚看了佳片有约还不错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-ciphers-s3-tmp.new_cipher;if (!s-method-ssl3_enc-setup_key_block(s)) return(0);} 关于SSL/TLS规范中将CCS设计成独立的一个数据协议我在《TCP/IP协议族》这本经典教材中找到了更真切的理由那就是它将发送方和接收方切割成了两个状态依照分权原则这个事不能在握手协议本身完毕。 漏洞发现者Masashi Kikuchi所述仅仅要保证几点就可以非常easyIMHO, 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 转载于:https://www.cnblogs.com/hrhguanli/p/3788316.html
