一、原理
1. 数据传输过程
浏览器访问一个HTTPS URL的数据传输的过程:
- 浏览器发送支持的加密方式给服务器
- 服务器选取一种加密方式,返回服务器的证书给浏览器,证书包含:网站域名,非对称加密的公钥,证书的颁发机构等
- 客户端验证证书是否合法。
- 如果证书合法或者用户同意使用不合法的证书,客户端随机生成一个随机密码TOKEN。
- 使用服务器返回的公钥加密随机密码,得到加密后的字符串TOKEN_EN
- 使用TOKEN(对称加密方法)加密一段握手信息(MSG),得到EN_MSG。
- 对MSG进行hash加密,得到HASH_MSG
- 把TOKEN_EN,HASH_MSG,EN_MSG一起发回给服务端
- 服务端使用密钥解密TOKEN_EN,得到TOKEN
- 服务端使用TOKEN解密EN_MSG,得到握手信息MSG,对MSG进行hash加密,得到HASH_MSG_,并验证是否与客户端发来的HASH_MSG一样。
- 服务端生成一段握手信息MSG1,使用TOKEN进行加密,得到EN_MSG1。使用hash加密,得到HASH_MSG1,把EN_MSG1和HASH_MSG1发送给客户端。
- 服务端使用TOKEN解密EN_MSG1,得到握手信息MSG1,对MSG进行hash加密,得到HASH_MSG1_,并验证是否与服务端发来的HASH_MSG1一样。
- 这样,握手阶段就结束了,握手阶段的作用:1. 验证服务端的证书 2. 客户端和服务端约定一个对称加密的秘钥,也就是TOKEN
- 后面所有的数据传输,都是发送方使用对称加密后,发送给接收方,接收方再进行解密,这样就可以保证,传输的过程中,1. 明文不会泄漏,2. 明文不会被篡改。这样就可以保证传输的安全性
最后的对MSG和MSG1的加密和解密,主要是用于测试的,也就是测试服务端和客户端的TOKEN,加密方式是不是都是一致的,这样可以保证后面的数据传输不会出错。
常用的加密方式:
非对称加密算法:RSA,DSA/DSS
对称加密算法:AES,RC4,3DES
HASH算法:MD5,SHA1,SHA256
非对称加密用于客户端和服务端协商TOKEN,这样可以做到只有服务端和客户端知道TOKEN的明文,使用密文来传输,防止被别人看到TOKEN
对称加密用于对HTTP传输的数据进行加密,发送方使用对称加密进行加密得到密文,传输密文给接收方,接收方解密后得到明文,这样传输的过程中,其他人看不到明文
HASH加密用于协商TOKEN后,客户端和服务端的传输测试,主要作用是判断加密前的数据和加密后再被解密得到的数据,是否一样。也就是验证测试是否通过。其实也可以不用hash加密,测试的时候直接发送明文,但是相对来说,安全性会差一点。
二、变化
1. 相对HTTP,能解决的问题
- 网络中间人。也就是有人破解了你的路由器,就可以看到你所有的请求。使用HTTPS后,所有经过路由器的数据都是经过加密的数据,所以别人看不到真实的数据。
- 运营商HTTP劫持。运营商会在返回的html文件里面加上自己的推广DOM,但是由于浏览器会对返回数据进行解密,这样会导致解密失败,可能会显示乱码。
- 运营商DNS劫持。DNS劫持的话,运营商会把域名解析为他们自己的IP,这样,返回的证书可能是假的,这样浏览器能够辨别,如果是真的,但是浏览器检查证书会发现DNS解析的IP和证书的IP不一样,也会报错,告诉用户。
2. 还是不能解决的问题
- 钓鱼网站。用户一开始就访问了错误的域名,所以HTTPS也不能解决,钓鱼网站也可能是HTTPS,但是现在相对较少。
- 篡改跳转链接。很多时候,并不是所有页面都是https的,有时候是从一个http页面跳转到https页面,这样网络中间人就可以修改http页面里的跳转地址,改为非https的,这样用户一般不会察觉。这样就可以实现中间人和服务器建立https链接,浏览器和中间人建立http链接,这样用户的所有输入,例如密码,中间人都可以看到。即使JS中对密码进行md5加密也没有用,因为中间人也可以修改JS代码。所以最好的方法是输入密码前,看看浏览器的地址是不是https的。
三、证书验证原理
上面的数据传输过程中,有一个步是:客户端验证证书是否合法
那客户端是怎么验证收到的证书是合法的还是不合法的呢?
假如有证书机构A,服务器B,客户端C
有数据
- A的公钥A_PUB和私钥A_PRI
- B的公钥B_PUB和私钥B_PRI
正式验证流程:
- 客户端会有一个信任的根证书库。保存的是证书机构的公钥,当然会有很多个证书机构。这个证书库,可能是系统级别的(例如window),也有可能是浏览器级别的。
- 服务器B,生成公钥和私钥后,需要证书机构的签发。证书机构会对服务器B进行详细的验证,然后会为B生成一张证书,证书的内容有:有效期,对应的网站,B的公钥,证书颁发机构的名字,B对证书的数字签名,A对证书的数字签名。
- 当C访问B的时候,B会把证书发送给C
- C会根据证书颁发机构的名字,从自己的根证书库里面找出A的公钥A_PUB。如果找不到,会提示用户,证书不可靠。
- 证书中会有B_PUB,这样通过B_PUB,A_PUB就可以验证A和B的数字签名是否正确。如果正确,就可以确定证书没有被篡改,而且是A颁发的。否则提示证书不可靠。
- C再验证其他内容,例如有效期,是否吊销(下面会说是否吊销的验证方法)等。
- 如果都通过,就可以认定,证书没有被修改,而且是属于B的证书。
数字签名的原理就是:证书机构,对证书的内容(数字签名外的其他内容,例如网站,有效期等)计算HASH值,然后使用A的私钥或者B的私钥进行加密。具体可以看RSA数字签名方法。
1.Fiddler抓包HTTPS的原理
Fiddler抓包的时候,Fiddler是充当中间人的角色的,上面说了,HTTPS可以解决中间人问题,所以按理Fiddler是不能抓HTTPS的包的。
但是我们知道使用Fiddler,可以实现对HTTPS的抓包的,那Fiddler是怎么实现的呢?
步骤是:
- Fiddler会自己生成一个模拟证书机构MA的公钥和私钥,还有一个模拟服务器MB的公钥和私钥
- 然后需要我们把模拟证书机构的公钥添加到客户端的信任的根证书库里面。
- 当服务端B下发证书CA给Fiddler时,Fiddler会通过MA和MB的公钥和私钥,生成另一张正式MCA给客户端。
- 由于客户端信任了MA的公钥,所以客户端不会发现MCA有异常。
其实这就说明Fiddler可以实现中间人的攻击。而可以实现攻击的根本原因是客户端信任了MA的公钥。
所以平时我们不要轻易相信未知的证书。
2. 证书是否吊销
吊销是指在有效期过期前,证书被吊销了。
这样的话,客户端怎么发现证书是否被吊销呢?
- 客户端会定期从信任的服务器下载已吊销的证书的MD5。
- 客户端收到服务端的证书后,可以访问信任的网站,查验证书是否有效。
其他:
访问一个https的网站,网站的旁边会有个信任的标志,里面可以看到证书的详细信息。
Internet选项-内容-证书 可以看到浏览器信任的证书和根证书
未经许可,请不要转载。