https的原理和流程，c（客户端）s（服务端） 

http是不能确保通信是可信的，ssl可以做到通信可信，ssl其实就是使用非对称进行加密，非对称加密分为公私钥，公钥加密，私钥解密，所以只要c端拿着公钥加密了数据，只有s端才能进行解密，这就保持了双方的通信可信的（私钥和公钥是成对的，因为私钥只有一份，也就是s端是能确保唯一性的，只要cs能进行一次加解密就确保了双方的通信是可信的），只要双方的通信是可信的，那么就可以发送数据给对方。但是怎么确定对方的身份呢？s端把公钥给发给c端，c端认证了这个公钥的安全性，就说明了c端认可了s端，在c端用公钥进行加密后，只有s端才能解密，c端就可以安全的向s端发送数据（因为只有s端才能完全解密来得到数据，其他的服务器是没有私钥的！），这样就能确保了c向s发送的数据是安全无误的到达了s端，不会被人劫持，因为你就算劫持了，你没有秘钥也是解不开的！

但是，非对称加密是一个非常耗时的计算（大数因式分解为两个素数），所以不能把所有的数据都进行非对称加密，那么简单的咱们就对称加密进行加密，用非对称加密来加密对称加密的key，只要双方都妥善保存了key就能确保安全性。

那么，咱么上面说的都是理论，那么c怎么去验证证书的呢？如何去判断这个公钥是安全的，c也不知道s的公钥是啥！这时候就出现了第三方的信任机构，这些由于比较权威签名了一些证书，咱们可以利用这些安全机构的证书来进行验证，s端使用这些机构签名的证书，向c端发送证书的时候，c端就可以去第三方信任机构验证证书是否安全（设备内置了根证书中级证书，并且后台会返回对应的证书链，所以不是每次都要迭代子证书去查询，如果你的s端发的是根证书签名的，那本地机器里面就有根证书直接验证成功，如果没有就需要进行证书链的验证，如果s端给的证书链不全，那就只能让c端自己去安全机构进行证书的请求验证了，fuck..）。

那么咱们说一下流程，c向s请求的时候发送支持的对称hash加密的支持列表，s会返回一个加密类型和一个证书给c，c会验证证书的有效性，如果无效就提示个网页（证书不可信），如果验证通过，就会根据s端的对称加密类型来生成一个key，并把这个key用公钥进行加密，发送给s端，s端拿得到数据后就用私钥进行解密，解密后得到了对称加密key，后面就是以这个key进行对称加密进行网络通讯。

以上就是https的理解，还有要说的是，如果信任的机构证书不安全了，那么上面的这一切都白搭了，因为c不知道证书是否安全的情况下，发送的数据不知道是否会被其他拥有私钥的端解密，那也就没什么安全性了，完全信任证书也是没有安全性的，因为完全信任，那么就代表着自签证书发给c端  ，c也会和s端进行通讯，如果这个s是中间人，那么所有的数据都会被劫持了，还要说一下，https是如何调试的，比如抓包工具，https抓取的原理就是：抓包工具自签名证书，然后添加进信任证书列表，c端和抓包工具的代理进行数据发送（因为已经信任了抓包工具的证书），抓包工具就成为了中间人，每次发起网络请求都会由抓包工具和s端再次进行数据请求，c->z(抓包工具)->s。