网页数字证书

2022-12-10

安全证书CA的权力是巨大的。根CA如果愿意,它可以随便伪造国内外任何站点的SSL证书,配合防火墙DNS污染,它可以在国内发起对任何网站的中间人攻击、截获通信数据。并且在比如硬件驱动验证、Windows更新等重要网络数据传输中的身份验证,也依赖于证书。这意味着,不安全的证书可以“合法的”向你的内核插入任意代码。

起源

博客Squidward’s Moai所载的文章请立即停用360浏览器并尽量减少使用相关产品

360浏览器根证书计划

关键词:360浏览器、CA机构、网站证书

网络上对360浏览器根证书计划的反应

知乎问答:如何看待360浏览器根证书计划?

  1. 黎明号护卫舰:不负责任地猜测一下,这个“360浏览器根证书”相当于360独家的门槛,网站不使用这个机构签发的证书就会被浏览器以安全理由拒绝访问(典型例子如自造证书的12306网站曾经被包括IE在内的主流浏览器拦截并警告)另外这个根证书独立于业界现有的证书分发系统,也就是说使用了360证书的网站反过来会被其他浏览器拦截并弹窗警告甚至拒绝浏览。用户在确定了要上的目标网站肯定安全之后,只能选择安装360浏览器来上。
  2. 知乎用户lzW15v:360 同理,你不装他的浏览器打不开网站,因为其他浏览器不认同你这伪造的根证书。反过来,网站不买360的证书,360浏览器打不开,但是360浏览器市场大,你不得不买他的证书。
  3. 匿名用户:关于ssl,我来做个科普。ssl协议目的不是证明网站安全,而是加密传输过程的流量,这样第三方即便监听到你的流量,在没有密钥的情况下也无法解密ssl的流量看到传输的内容。关于信任第三方窃取数据的方式可以通过一组证书让浏览器按照自己的密钥进行加密,然后再用自己的密钥解密后获取数据再通过服务器原本的密钥加密发送给服务器,实现通讯的监听。所以浏览器要确保证书是可信的才能保证通讯过程中无监听,所以证书一般包含了签发机构和域名,域名得和证书匹配才能证明传输过程安全。

CA以及网站数字证书

博客园-东寻

https传输协议需要SSL

HTTP协议传输的数据都是未加密的,也就是明文的,因此使用HTTP协议传输隐私信息非常不安全,为了保证这些隐私数据能加密传输,于是网景公司设计了SSL(Secure Sockets Layer)协议用于对HTTP协议传输的数据进行加密,从而就诞生了HTTPS。 简单来说,HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比HTTP协议安全。

SSL下的通信非对称加密

非对称加密算法需要两个密钥:公开密钥(publickey:简称公钥)和私有密钥(privatekey:简称私钥)。

公钥与私钥是一对,如果用公钥对数据进行加密,只有用对应的私钥才能解密,相反,也可以先用私钥加密,再使用公钥解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法。

非对称加密分发公钥的真伪验证

中间人截获、篡改公钥

使用非对称加密下,A同样需要与其他用户协商密钥,A需要构造一对公私钥,将公钥发送给B、C、D,自己保留私钥。此时,若A发送给B、C、D的消息被黑客E截获,E就可以保留A的公钥,然后构造一对新的公私钥,将私钥保留,自己的公钥发给B、C、D。

按照非对称加密,E就成了通信的中间人:

B、C、D使用E的公钥加密数据并发送给A,E劫持通信数据后,使用自己的私钥解密数据,再使用A的公钥加密数据发送给A。 对于用户A、B、C、D而言,他们并不知道自己的通信对于中间人而言是曝光的。

CA认证公钥

此时需要引入一个公信机构F,用于为用户证明身份,否则在当前通信环境中,个人是无法为自己证明身份的。这个机构便是CA。

CA自己有一对公私钥,公钥公开给所有用户,私钥自己保留。当A想要向B证明自己时,只需要先请求CA给自己的消息用CA私钥加密一下(签名),再把消息发送给B,如果B用CA的公钥能解密,说明这条消息是被CA认证过的,没有被其他人篡改过。

此时中间人攻击就不再奏效,因为即便截获了A发送给B的数据,中间人也只能用CA的公钥解密出消息内容——“这是一条被CA认证过,由A发送给B的数据”。但中间人无法对消息内容进行篡改,因为B只会用CA的公钥去验证这条消息是否被CA认证过,中间人用自己的私钥加密的数据,B用CA的公钥无法解开。

https协议通信建立流程

https协议通信建立流程

  1. CA将自己的证书(公信凭证)交给各浏览器厂商,厂商将证书配置到各自浏览器。

  2. 网站将自己的证书(身份凭证)交给CA,让CA使用私钥对证书进行签名,CA签名后发回给网站。在这个过程中,CA需要核实网站的真实性,网站发给CA签名的也不仅只是证书,其中网站证书(含网站URL)和网站公钥是必要的,还会包含一些其他信息一同签名。

  3. 浏览器用户向网站请求安全连接,网站把CA签名后的证书发给用户,浏览器会根据证书信息,检查是哪个CA做的签名,从浏览器自带的CA证书中找到对应公钥验证。

  4. 如果验证通过,就证明了网站身份的可靠性,用户可以通过网站提供的公钥进行安全连接,和网站协商后续对称加密的密钥。

安全证书CA的权力是巨大的,曾经发生的CNNIC证书事件,CNNIC作为受信任的根CA,如果它愿意,它可以随便伪造国内外任何站点的SSL证书,配合防火墙DNS污染,它可以在国内发起对任何网站的中间人攻击、截获通信数据。

CA证书的“权力”

知乎问答:网上流传的所谓「支付宝偷偷添加根证书,将造成安全隐患」的说法是否正确?

  1. 刘昊: CNNIC、12306、阿里巴巴和很多其他银行的根证书之所以不应被信任,不仅是因为它们的公正性和可信度没有得到业界和公众认可,更重要的是,它们的根证书声明了远远超出需要的权限。什么叫远远超出需要呢?阿里巴巴和各银行的根证书如果像很多同学所说,是为了为自己的网站签名,只需要有“服务器身份验证”的权限就可以了。如果需要为各种外置UKey签名,只需要“客户端身份验证权限”,而自己的软件需要认证,只需要“代码签名”权限。比如硬件驱动验证、Windows更新等等。这意味着CNNIC、12306以及Alibaba可以伪造微软的更新包或签名的驱动程序,“合法的”向你的内核插入任意代码。而这一切,由于Windows支持后台推送更新,都可以在你完全不知情的情况下发生。相比于这个安全威胁,中间人攻击什么的完全是战五渣。

  2. Ivony:证书颁发机构和域名一样,是一个树状的结构,全球有为数不多的几个根证书颁发机构。这些根证书颁发机构轻易不颁发证书,因为一旦根证书颁发机构的证书被泄漏,所有直接间接的证书,都会受到严重的影响。所以,根证书颁发机构一般授权二级证书颁发机构颁发证书,一旦信任一个根证书颁发机构,等同于信任其下所有颁发的所有证书,以及其授权的二级证书颁发机构颁发的所有证书。更为严重的事情是,根证书颁发机构,是整个证书颁发体系中,唯一不受任何身份验证的。其身份的正确性,由其自行保证!也就是说,根证书颁发机构可以宣称自己是任何一个公司,没有任何人和组织可以对其进行审查!换句话说,支付宝要更没节操点,给你弄个自己签发的VeriSign的根证书装你电脑里也没商量。事实上,根证书颁发机构是整个证书体系中,最薄弱的环节。这就是为什么上次微软在操作系统中内置CNNIC这个流氓的根证书引起了网络上广泛的质疑。根证书几乎只能由操作系统内置,通过操作系统安装程序二进制代码的安全来确保正确。证书在现代互联网和操作系统中的应用会越来越广泛,在可预见的将来,所有的程序、邮件、文档,全部都会使用证书加密,确保其在传输、分发过程中不被篡改,确认发行者的身份。根证书颁发机构的证书,不能被任何组织或机构所验证,因为几乎一切互联网上的验证机制,都是通过证书体系来完成的。我举一个栗子,我如何验证我电脑上的这个VeriSign的根证书是正确的?我们可以想出很多种办法:1、直接问我,或者问某个安全领域的砖家。你怎么知道我或者砖家不会骗你?万一我收了别人的钱呢?或者我也被人骗了呢?2、去VeriSign网站查询。你怎么知道这个网站是VeriSign的?有HTTP,有绿色的小锁?问题是这些都是基于你所信任的根证书的。如果你的根证书是假的,他肯定会弄个假的网站给你认证了,反而把那个真的网站给认证成不安全的。3、去第三方网站下载证书的校验码。哪个网站是可信的?没有证书的情况下,所有的网站都可能被劫持,被篡改。

  3. Rix Tox:現在所有主流的操作系統、瀏覽器軟件大廠商都會維護自己的默認根證書列表通過軟件分發給用戶,這種情況其實對於終端用戶來說也基本上是「不知情」的,但是他們都有盡到法律義務,並且遵循我後面講到的原則,也都會在用戶使用協議中列舉相應的法律條款。我們可以看看各大廠商是如何採納根證書的。微軟有一個 Microsoft Root Certificate Program可以接受機構申請加入微軟的默認根證書列表。Firefox也有類似的policy for CAs來規定根證書機構的申請要求。這些申請條件中都共同有一條很重要的要求:必須由世界公認的審計機構對根證書的管理機構進行信用審計。這些審計工作不是光在申請前期做完就一勞永逸的,而是一個長期性的監督審計過程,所以審計資金根據其工作量和信用要求程度的不同可以是很貴到非常貴