众所周知在12306购票，官方说明需要导入根证书，这算是良心的了。其实你安装了支付宝插件，就会被不知情的导入了某些[哔]的根证书，而这会带来一些安全隐患：提升遭遇中间人攻击的可能性：在你完全不知情，以为自己还在享受这HTTPS带来的安全保护的情况下，将未加密的信息完全暴露给第三方（比如GFW）。而根证书是什么？为什么可能导入一个证书就可能会遭到中间人攻击的？我们从头说开去~
一、基本概念
加密：
未加密信息：明文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
非对称加密：
密钥对：
密钥对p,q存在映射关系g，但通过这个关系很难计算互相计算出对方。
通过p加密的密文需要用q来解密，通过q加密的密文需要p来解密。
公钥与私钥：
将密钥对p,q中的一个p公开给其他人，称为公钥p；另一个私有不公开，称为私钥q
加密解密方式:
A持有p,q密钥对，并将公钥p告诉给B
A→B
A使用私钥加密，B使用公钥解密
B→A
B使用公钥加密，A使用私钥解密
当然，如果AB均有一对自己的密钥，那么就可以分别通过对方的公钥加密自己发出的信息这样对方就可以利用对方的私钥解密了。
不过对于HTTPS来说似乎不太合适，因为让用户端也保有一对安全的密钥是不合实际的，通常只有服务器保有一对密钥。实际HTTPS常用到的TLS(SSL)加密协议是混用了两种加密方式，这个我们在下面提到。
非对称加密常用算法为RSA
三、HTTPS加密的实现
TLS（SSL）
通过对称加密方式加密通讯内容，并通过非对称加密方式加密其密钥，这样，服务器与客户端协商的密钥在传输中也被加密，这样即使密钥被截获，也是加密后的密钥，而如果想要解密这个密钥，则需要知道非对称加密的私钥，而其概率就非常小了。
也就是：
明文→（对称加密）→密文
密钥→（非对称加密）→加密的密钥
而整个过程如下：
1、双方协商
2、客户端通过服务器公钥加密对称加密的密钥
3、服务器通过私钥解密这个密钥
4、双方均知晓密钥，建立对称加密连接，开始数据通信
下图是google.com.hk的https连接信息，可以看到连接使用chacha20_ploy1305方式的256位密钥加密，并且使用了RSA的变种ECDHE_RSA加密了该密钥。并且服务器证书由google Internet authority G2颁发，这个其实是个证书链，是个中间层，属于中级证书颁发机构，其上还对应了一个CA机构：GeoTrust Global CA
中间人攻击：
假设A是服务器，B是用户，B向A发起HTTPS连接，于是A需要将自己的公钥发给B。中间人C通过某种手段可以截获并伪造AB之间的通讯（比如GFW）。那么C可以伪造一份A的公钥，并保有这分假公钥的私钥；然后截获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的证书链，一并删除即可