参考：https://segmentfault.com/a/1190000012196642
作为一个web开发者，对于https和http肯定要有所了解，现在的我对于深层次的https通信看着还不是太懂，但是对于https和http的差别，记得有一次去中科招商的时候面试有问到过。写这篇文章的时候，主要是方便自己看的时候理解。
首先呢 https默认端口号是443，http是80，都知道http相比于http更加安全。但是安全主要在什么方面呢，http通过明文传输，post方式好像看不见，但是get方式可以通过在服务器上监听这个端口，就能看见甚至都不要解密传进来的数据。像之前的talent，远程连接（默认端口23），因为传输过程明文，而且远程连接主要就是用来远程登录，肯定要输入用户名和密码，so，通过对这个端口的监听，就能知道用户通过talent服务的这个端口传进来的用户名和密码，这个安全性的要求不言而喻，所以现在都不用了，现在用ssh。还记得每次连接服务器的时候，让你接受公钥的弹窗嘛，这是为了在传输过程中用服务器的公钥进行加密，然后数据到达服务器端，服务器可以通过私钥进行解密。之前看过一个很形象的比喻。公钥就相当于锁，私钥就相当于钥匙，我这个东西用锁锁起来了，当然就可以用钥匙打开了（这是公钥加密，私钥解密的比喻）
https和http都是基于tcp/ip 协议，属于应用层，他们其实是一样的，只是https外层有个ssl包裹起来
其实本质上还是属于http协议。
https在传输过程中使用了加密，有对称加密和非对称加密。
对称加密就是在加密和加密过程中使用同一个密钥，但是这样有个不安全点就是，密钥需要进行传递，传递过程中，如果密钥被捕获了，那加密如同虚设，so，就产生了我们的非对称加密
我所接触的非对称加密有ssh加密，这个因为不管是github上开始代码的提交，还是我们开始远程建立数据库的连接，都要用到。记得我第一次给github提交代码的时候，因为window默认不支持ssh，所以下载了git客户端，在gitbash上进行操作，生成了ssh密钥，把公钥贴在了github的setting里面。（非对称加密算法好像有个叫RSA）。
因为非对称加密有些复杂，https通信过程中,注意是通信过程中，不用非对称加密，用的还是对称加密，因为我们只要保证通信过程中对称加密的密钥不被窃取捕获篡改，就可以了。所以我们在传输密钥的过程用的是非对称加密，这样就得需要服务器的公钥，我们用服务器的公钥加密我们传输数据对称加密的密钥，然后传输到服务器端，服务器用他的私钥进行解密，这样密钥传输成功，我们进行通行的过程中就可以用对称加密了。
那问题来了，服务器怎么传输过来他的公钥呢，怎么保证他传输过来的公钥的安全性呢，用对称加密？不行，无法保证密钥的准确，用非对称加密，也不行，这就陷入无限的死循环中了。
其实非对称加密不仅可以用公钥加密，私钥解密，保证传输数据的数据不被获取（需要私钥解密，可是私钥是私密的东西哦，别人都不知道）到，但不能保证数据不被劫持篡改（但无法保证别人对你这个文件进行修改），还可以使用私钥加密，公钥解密，这样不能保证数据不被获取到，但是可以保证数据不被篡改（因为每个人都可能获取到公钥，然后用公钥解密你这个私钥解密的文件，但无法修改，因为一旦修改了，文件的内容和私钥加密的内容就不一样了，等到客户端接收到服务器端传过来的内容，用公钥解密后，发现内容不一样，就很容易判断到文件被修改，如果一样，则能保证传输过来文件的准确性（我对不能同时修改文件和私钥加密文件的看法是私钥是服务器所特有的，所以不能还原修改文件被私钥加密后的样子））
- 首先，CA会向申请者颁发一个证书，这个证书里面的内容有：签发者、证书用途、服务器申请的时候附带的公钥、服务器的加密算法、使用的HASH算法、证书到期的时间等等。
- 紧接着，把上面所提到的内容，做一次HASH求值，得到一个HASH值。
- 再接着，用CA的私钥进行加密，这样就完成了数字签名。而用CA的私钥加密后，就生成了类似人体指纹的签名，任何篡改证书的尝试，都会被数字签名发现。
- 最后，把数字签名，附在数字证书的末尾，传输给服务器
因为这个传输服务器公钥的过程就是为了保证数据的不被篡改，不用管数据是否被窃取到，因为传输的是服务器的公钥，本身就是公开的，所以我们用私钥进行加密，公钥进行解密。
- 客户端拿到这个数字证书以后，用CA私钥对应的公钥，可以解密数字证书末尾的数字签名，得到证书的内容以及原始的HASH值。
- 紧接着，客户端按照证书中的HASH算法，对证书的内容求HASH值。如果通过CA公钥解密的HASH和通过计算求得的HASH值相同，那么认证通过，否则失败。
- 如果认证通过，就可以取得服务器的公开密钥。
所以对服务器公钥的传递本质上还是通过费对称加密算法，只是找了个中间机构ca，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。这样，就方便客户端对于数字证书真实性的验证。
客户端证书
HTTPS中不仅可以使用服务器证书，还可以使用客户端证书。以客户端证书进行客户端认证，它的作用与服务器证书是相同的。
由于客户端获取证书需要用户自行安装客户端证书，同时也面临着费用的问题。
因此，现状是，安全性极高的认证机构可办法客户端证书但是仅用于特殊用途的业务。比如那些可支撑客户端证书支出费用的业务。
例如，银行的网上银行就采用了客户端证书。在登录网银时不仅要求用户确认输入ID和密码，还会要求用户的客户端证书，以确认用户是否从特定的终端访问网银。
总结一下：
- 首先服务器端让ca用他的私钥对自己的公钥进行加密，然后传给客户端，客户端用ca的公钥进行解密，保证接收到服务器端公钥的准确性。
- 然后客户端用服务器端公钥对自己传输过程中数据进行对称加密的密钥进行加密，传输给服务器端，因为只有服务器端有私钥，所以只能服务器能解密，保证数据传输过程中密钥的安全性。
- 最后客户端通过对称加密的密钥给自己传输的数据进行加密，传输给服务器端，服务端用之前客户端传输过来的密钥进行对称结密，完成通信。
