飞羽博客

众所周知在12306购票，官方说明需要导入根证书，这算是良心的了。其实你安装了支付宝插件，就会被不知情的导入了某些[哔]的根证书，而这会带来一些安全隐患：提升遭遇中间人攻击的可能性：在你完全不知情，以为自己还在享受这HTTPS带来的安全保护的情况下，将未加密的信息完全暴露给第三方。而根证书是什么？为什么可能导入一个证书就可能会遭到中间人攻击的？我们从头说开去~  （本文写得非常不专业，如有错误望指正）

一、基本概念

加密：

未加密信息：明文x
加密后信息：密文y
明文到密文之间的转换关系：y=f(x)，而解密则是x=f ^-1(y)
例子：f：密文=明文+1，那么123→234；bag→cbh
实际起到加密作用的是f，故f是不能被公开的。
缺点：f是作为加密的关键不能被公开，假如有N对人进行加密通讯，每个人都不想让其他人解密自己的通讯那么必须构造N种f，而构造一个好的f很不容易的。对“天王盖地虎，宝塔镇河妖”这种情况或许还好用，可是对于互联网通讯加密来说就非常不合适了

密钥：

为映射f引入第二个参数key，关系变为y=f(x,key)
f是可以公开的，而key密钥是私有的。只要key没有泄露出去，而且f合理，由y导出x就不是件容易的事。 不少加密算法密钥越长，加密强度越高，逆向破解越困难。

破解：

指在不知道key的情况下，利用各种方法，获取到key；或者绕开key，通过y直接求解x。

合理的f：

在不知道key的情况下，由y计算出x在时间上不可行（破解所需时间比密文时效长很多）；并且不存在可以大幅缩短破解时间的缺陷。

当今计算机的计算能力飞速提升，往往过去认为安全的加密方式，现在已经变得不安全。

二、加密方式

对称加密：

双方共享一个密钥，这个使用这个密钥来加密。用以保护双方的通讯。

优点：简单高效。一个优秀的对称加密算法可以做到，加密过程不需要消耗太多计算能力；但反过来破解缺非常难。

缺点：如果是通讯双方使用预先协商好（设定好）的密钥那么没有问题，如WiFi的加密就基于此种方式。然而如果双方并没有预先协商好密钥，而是在通讯发生时候才开始协商密钥，那么密钥就存在被截获的可能，如果被截获，通讯将不安全。

对称加密常见的算法如：AES-128；其中，AES是加密算法，128是密钥长度。

实际应用时候，往往还会给加密算法加入通讯双方的一些指纹信息用于身份验证，如：AES-128-GCM。

非对称加密：

密钥对（一对密钥）：
密钥对p,q，通过特殊方法计算得出；他们存在映射关系g，但仅通过这个关系很难从一方计算出另一方（基于单向函数的特性）。
通过p加密的密文需要用q来解密，通过q加密的密文需要p来解密。

公钥与私钥：
将密钥对p,q中的一个p公开给其他人，称为公钥p；另一个私有不公开，称为私钥q

加密解密方式:
A持有私钥p，生成对应公钥q，并将公钥q告诉给B
A→B
A使用私钥加密，B使用公钥解密

实际HTTPS常用到的TLS(SSL)加密协议是混用了非对称与对称加密两种方式，这个我们在下面提到。
非对称加密常用算法如：RSA

非对称加密算法加上密钥算法，构成了TLS(SSL)通讯中的密钥交换机制，如：ECDHE_RSA

三、HTTPS加密的实现

TLS（SSL）

加密通道的建立主要是两个方面：

1. 通讯双方协商加密通讯所用的密钥（此处称之为密钥x）；此协商过程使用非对称加密方式进行；

2. 通讯双方使用协商的密钥x、对称加密方式加密其通讯内容。

这样，服务器与客户端协商密钥的过程也被加密，这样即密钥x的交换过程被截获，也是加密后的密钥，没有私钥就无法解密。
也就是：
要发的明文→（对称加密）→发出的密文
密钥→（非对称加密）→加密的密钥
而整个过程如下：
1、连接发起，开始协商密钥x，如何确定密钥x由通讯双方的其中一方来主导，假如说是客户端；
2、客户端将密钥x的信息通过服务端的公钥加密后发给服务端；
3、服务端通过私钥解密，最后计算出私钥x；
4、双方均知晓密钥x，建立对称加密连接，开始数据通信。

下图是google.com.hk的https连接信息，可以看到连接使用chacha20对称加密算法加密通讯数据，poly1305进行身份验证，使用了ECDHE密钥交换算法，使用了RSA加密密钥交换过程。并且服务器证书由google Internet authority G2颁发，这个其实是个证书链，是个中间层，属于中级证书颁发机构，其上还对应了一个CA机构：GeoTrust Global CA

中间人攻击(MITM)：

假设A是服务器，B是用户，B向A发起HTTPS连接，于是A需要将自己的公钥发给B。中间人C通过某种手段可以截获并伪造AB之间的通讯。那么C可以伪造一份假公钥，并保有这分假公钥对应的假私钥；然后截获A发给B的真公钥，并伪造自己的身份，让B认为自己就是A，并把伪造的公钥发给B；如此一来，B会通过伪造的公钥给A发送密文，而C就可以截获这些密文并利用手中的私钥轻易的解密这些密文了。然后将这些密文通过正确的公钥转发给服务器A，这样AB之间的通讯仍将继续，AB在毫不知情的情况下被中间人把密钥对“偷梁换柱”，从而达成了中间人攻击，AB之间的非对称加密形同虚设，从而TLS协议的对称加密的密钥就能被C轻易的获取，如此，TLS完全告破。

数字证书认证机构（CA）：

它的出现就是为了防止中间人攻击的。
防止中间人攻击，说白了就是要确保B收到的A的公钥（证书）真实有效，这样数字证书认证机构应运而生。

数字证书认证机构说白了就相当于一个受信任的身份验证者。CA有一对根密钥，其公钥称为根证书。
A向CA申请一个证书，则CA利用其私钥加密并签名A的公钥，其结果就是“服务器A，通过CA验证的证书”。
而在用户的操作系统（或者浏览器）中，会集成世界范围内所有被信任的CA的根证书。
这样，用户B在收到A发送给他的证书后，需要利用CA的根证书（公钥）解密后才能得到正确的公钥，如此一来，就完成了对A发送过来的信息的验证，证明了A的正身，不是C伪造的假证书，从而达成了中间人攻击的防范。

四、第三方CA的问题

目前很多机构都会要求你安装第三方的CA证书，特别是遇到网上支付时候。另一种就是goagent的根证书了。这些机构使用自签名证书的验证方式，这对于支付宝、网上银行这种为个人制作验证用的证书的情况很正常，因为为如此庞大的用户群体制作证书，如果交给正规CA来做不知道得收多少钱。。。不过他们却把本来可以不导入至你系统中的根证书导入进去了，这将带来一些安全隐患。

Goagent的伪HTTPS代理

由于GAE的功能性限制（只能实现HTTP代理），无法实现HTTPS信息原封不动的转发，于是Goagent的伪HTTPS代理其实就是利用了中间人攻击：在GAE服务器上解密服务器数据，并利用伪密钥对重新加密数据发给用户。本来这种中间人攻击因为CA的问题被检查出证书错误，出现警告：Goagent CA不是受信任的证书颁发机构；不过如果向系统导入了goagent CA的根证书以后，就会消除此现象。这就是goagent为什么要导入根证书的原因。

不过虽然HTTPS没有证书警告了，不过当你查看证书详情的时候，还是会发现，证书颁发机构从原来的值变成了“GoAgent CA”，不过通常是很难察觉这个变化的（如下图红色框）

导入ROOTCA的危险性：

如果导入goagent、铁道部12306.cn这种第三方CA的根证书，将会大大增加受到中间人攻击的可能性。如果GoAgent私钥泄露，所有Goagent用户都有遭到中间人攻击的可能性。
而铁道部的根证书更危险，铁道部的私钥必然对LD是公开的，GFW完全有能力通过铁道部的私钥来实现对所有导入了铁道部CA根证书的用户的中间人攻击，让你的HTTPS加密流量完全暴露给GFW。正确的做法是，不导入根证书，访问12306购票时候，无视证书警告，点仍然继续，依然可以正常购票，且不影响购票的安全性。

各大银行的CA证书、支付宝亦是同理。这些网站验证证书时候均使用了插件，那既然如此使用插件自己读取自己的证书即可，本大可不必将根证书导入至系统。但他们却这么干了。如此一来把其根证书作用域从插件自身扩大至整个系统，扩大了安全隐患。

不止如此，安装个支付宝控件，你会发现多了一个OSCCA的ROOTCA，然后你查找OSCCA，结果是：国家商用密码办公室。。。好吧我之前都没注意

劝大家，运行certmgr.msc，把奇怪的证书都清理干净吧。。

建议删除（或者直接将之拖入不受信任列表内）：

ROOTCA：上面说了

CNNIC ROOT CA：中国互联网络信息中心，这个可能需要拖入不受信任证书内，否则会重新出现

alibaba .. CA：阿里巴巴的（删了也没发现用支付宝啥异常来着 本来他们的网站用的就是VeriSign的证书，不过使用证书验证登录的用户会受影响，建议取消证书验证）

ABC …CA：农业银行的，想要保证网上银行可用，根证书还是需要的，不过最好点开其属性，把证书目的从“所有”改成“服务器身份验证”和“客户端身份验证”两种

BOC、ICBC等等

其实可以来个更狠的 把这些证书导出后删除，然后再将它们导回“不受信任”里面。注意在“中级证书颁发机构”里面还可能有以上根CA的证书链，一并删除即可