https是http协议加上SSL/TLS协议总称。SSL/TLS协议是位于http协议和tcp协议的中间层。这个SSL/TLS协议完完全全就是为了安全而生的，解决的就是http各种安全问题（容易被劫持、明文传输等）。

一、从加密开始

http协议中，客户端和服务端通信是没有加密的，明文传输。如今我们的需求是传输的内容必须是密文。那么应该怎么做？我们想当然的想着把内容加密后在传输。那么应该选择什么加密算法呢？非对称加密对于长内容来说非常耗时，所以我们理所应当的选择对称加密来对信息加密。
问题是，客户端加密内容的密钥怎么才能安全的传输给服务器，以用于服务器解密呢？

二、混合加密

聪明的人类想到，把密钥再加密不就完了。首先服务器生成非对称加密的公钥和私钥，公钥用于加密，私钥用于解密。公钥通过互联网发给客户端。客户端用公钥加密一串随机字符串(对称加密密钥)后，通过互联网返回给服务器，服务器用私钥解密，这样双方就得到了加解密信息的密钥(那一串随机字符串)。如下流程：
客户端：“服务端啊，我要你的公钥。”
服务端：生成公私密钥，把公钥发送给客户端。“诺，给你”
客户端：收到公钥后，加密一串随机字符串，发送给服务端。
服务端：收到密文后，通过私钥解密，得到随机字符串。
客户端：发送http加密报文。
服务端：收到报文后，用密钥解密http加密报文

看似安全了，是吗？其实不然。如果有一个中间人，从始至终都在中间劫持客户端服务端之间的内容，服务端发送公钥中间人就劫持，并自己伪造一个公钥给客户端。那么后面所有的内容，他都可以劫持到。

三、数字证书

单纯只靠浏览器、服务端双方很难做到真正的安全。必须要第三方权威机构介入。那么第三方权威机构是干嘛的呢？简单来说，在上一步中一旦中间人劫持了公钥，后面的步骤都白搭。那么第三方权威机构就是能安全的把公钥送达到客户端手中。How? 很简单，在这里，权威机构用自己的私钥对那个公钥进行加密(注意啊，私钥也可以用于加密，非对称加密很灵活的)。将密文（这个密文就是数字证书，数字证书中还包含权威机构一些信息）传输给客户端，客户端用权威机构的公钥解密后，得到客户端的公钥。奇怪？权威机构的公钥怎么到客户端去的？这个是由于权威机构和操作系统以及浏览器厂商做了py交易，内置了公钥。
那现在安全了吗？差不都把，几乎安全了。但是有没有可能中间人伪造这个数字证书呢？确实有这个可能。

四、数字签名

其实这个问题，数字证书本身已经提供方案了，数字证书中除了包含加密之后的服务器公钥，权威机构的信息之外，还包含了证书内容的签名(先通过Hash函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名)，签名计算方法以及证书对应的域名。这样一来，客户端收到证书之后：
先用权威机构的公钥解密，得到证书内容的签名，然后根据证书上描述的计算证书签名的方法计算一下当前证书的签名，与收到的签名作对比，如果一样，表示证书一定是服务器下发的，没有被中间人篡改过。

由此，就得到了一个安全的传输协议。

五、总结一下流程

step1：客户端向服务器发起https请求。
step2：服务器向权威机构获取证书
step3：将证书发送给客户端，里面包含服务器加密的公钥
step4：客户端用权威机构的私钥解密报文。验证证书合法性，之后取出里面的公钥，加密一个随机数(传输内容的密钥)
step5：将加密后的密钥传输给服务器
step6：服务器收到加密密钥，用服务器私钥解密后得到密钥。用于加解密报文。
step7：服务器，客户端开始加密“通话”