https的原理

问题

众所周知，http是个明文协议，仍然被中间人攻击，或者被中间人串改数据。

电信作为中间人劫持网页推送广告。

知乎上各种投诉电信劫持的问题。

加密算法

概要

对称加密

对称加密是指加密和解密使用相同密钥的加密算法。它要求发送方和接收方在安全通信之前，商定一个密钥。对称算法的安全性依赖于密钥，泄漏密钥就意味着任何人都可以对他们发送或接收的消息解密，所以密钥的保密性对通信至关重要。对称加密算法的优、缺点：优点：算法公开、计算量小、加密速度快、加密效率高。缺点： 1) 交易双方都使用同样钥匙，安全性得不到保证； 2) 每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一钥匙，这会使得发收信双方所拥有的钥匙数量呈几何级数增长，密钥管理成为用户的负担。 3) 能提供机密性，但是不能提供验证和不可否认性。

非对称加密

这种加密或许理解起来比较困难，这种加密指的是可以生成公钥和私钥。凡是公钥加密的数据，公钥自身不能解密，而需要私钥才能解密；凡是私钥加密的数据，私钥不能解密，需要公钥才能解密。这种算法事实上有很多，常用的是RSA，其基于的数学原理是两个大素数的乘积很容易算，而拿到这个乘积去算出是哪两个素数相乘就很复杂了，具体原理有兴趣可以自行研究。非对称加密相比对称加密更加安全，但也存在两个明显缺点： 1）CPU计算资源消耗非常大。一次完全TLS握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。 2）非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。所以公钥加密目前只能用来作密钥交换或者内容签名，不适合用来做应用层传输内容的加解密。 ## 摘要加密散列函数 Hash，常见的有 MD5、SHA1、SHA256，该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定，针对数据的任何修改都会改变散列函数的结果，用于防止信息篡改并验证数据的完整性

https模拟演进

简单的对称加密

方案：握手后，服务器返回对称加密的key，然后双方用key加密的数据通信，来保证中间人无法窃听。问题：中间人可以窃听握手时，服务器返回给客户端的key，而后中间人窃听数据后，用key来解密数据就可以窃听了。

非对称加密来握手，对称加密来通信

方案：握手后，服务器返回公匙，然后客户端随机生成一个key，然后用公匙加密。服务器获得后用私匙解密。随后双方用key作为对称加密数据。中间人无法窃听到服务器中的数据，因为被公匙加密的数据，只有私匙才能解密。

问题：中间人可以用重放攻击来窃听数据。或者说，你怎么确定发过来这个公匙是真服务器的公匙？

非对称加密来握手，证书体系验证身份，对称加密来通信

方案：就跟方案二差不多，只是多了个证书体系来验证对方身份。

用证书体系来保证这个公匙是真服务器的公匙。

https 最终流程

客户端发起HTTPS请求

这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。　　 ## 服务段解密信息服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。　　 ## 传输加密后的信息这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

证书链

什么是证书

解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构 CA。CA 负责核实公钥的拥有者的信息，并颁发认证”证书”，同时能够为使用者提供证书验证服务，即 PKI 体系。

证书链

服务器返回给客户端的信息中包含自己的证书，这个证书上有自己的网站的域名，以及IP信息，以及该证书的颁发者信息。浏览器获取到该证书后就会到操作系统中寻找颁发者的证书，如果颁发者的证书存在，而且颁发者证明了证书有效，那么该证书就有效的。如果颁发证书不存在，或者颁发证书无法证明证书有效，那么该证书就是无效的。

百度证书的证书链

12306的证书链

根证书

操作系统在预装时会提供一些重要的根证书，这些根证书是自签名的，完全信任的。一般情况避免自己导入根证书，或者安装一些非原装的系统。

证书验证过程

1、数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用 CA 自己的私钥对消息摘要进行加密。 2、数字签名的校验。使用 CA 的公钥解密签名，然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。

证书真伪

综上所述，为了证明公匙是真服务器的公匙，服务器需要提供一个数字签名，而这个数字签名是需要权威的第三方机构CA提供的，第三方机构CA会根据你提供的资料和金钱来确定是否给你做数字签名。由于计算数字签名需要的是CA的私匙，验证数字签名使用的公匙。那么，只要保证CA的私匙不泄漏，那么这世界就没有人能根据公匙伪造出一个证书。 CA证书验证->我方证书->CA私有钥匙。

总结

关键是证书

证书是整个https安全措施中最薄弱的环节，如果证书校验不通过，那么就不应该相信这个网站，不应该继续浏览下去。（12306除外）另外，严格禁止导入新的根证书，这相当于给你的系统开了后门。（mac中导入不了，windows中可以）

问题1

目前由于网站紧急需求，必须要在http环境下确保登录时用户的账号密码不被抓包泄漏，（不考虑中间人回放攻击），怎么做？

问题2

由于开发的需要，需要用proxy来查看手机端https网络请求情况，怎么办？就是想做中间人倾听像baidu.com，qq.com这种全站https的高安全性流量数据，怎么破？

问题3

https是怎么解决一开始的问题，防止电信运营商劫持流量加广告的。

https原理

问题