产生原因：

• HTTP：未加密、明文。
• SSL（Secure Sockets Layer）=> TLS（Transport Layer Security），目前大部分https都是用的TLS，只不过SSL出现最早我们有时候也依然叫SSL。
• HTTPS = HTTP + TLS

对称加密和非对称加密

对称加密就是用同一个密钥加密、解密。
如图，A如果直接发送data，肯定会经过若干中间人M（如路由等），HTTP就是纯明文的，M可以获取所有明文数据。

而通过对称加密，如果A和B都有密钥key，M没有密钥就无法得到明文的data。

但问题来了，现在A生成了一个密钥key，怎么将其传给B呢？若直接发送，那M也会得到，那加密也没啥意义了。非对称加密就是为了解决这个而诞生的。
非对称加密，就是生成俩key，一个公钥key1一个私钥key2，key1加密的数据只能用key2解密，而key2加密的数据只能用key1解密。这种算法事实上有很多，常用的是 RSA，其基于的数学原理是两个大素数的乘积很容易算，而拿到这个乘积去算出是哪两个素数相乘就很复杂了。好在以目前的技术，分解大数的素因数确实比较困难，尤其是当这个大数足够大的时候（通常使用2的10次方个二进制位这么大），就算是超级计算机解密也需要非常长的时间。

• 先在A生成公钥key1和私钥key2，发送公钥key1给B，M可以拿到明文的key1，但拿到也没啥用。
• B拿到公钥key1后，生成一个密钥key，然后用公钥key1把密钥key加密，回传给A。此时通过M时，因为数据只能用私钥key2才能解密，M只有key1，所以并不能看到其内容。
• A拿到加密后的密钥key后，通过key2解密。此时，A、B都拥有了密钥key，可以通过密钥key进行对称加密了。

CA证书（Certification Authority）

然而，非对称加密一定是安全的吗？

• M在收到公钥key1的时候，把key1存起来，同时又生成一个伪公钥key_a和伪私钥key_b，
• M把伪公钥key_a发送给B，B依然按照原来的逻辑生成密钥key。然后通过收到的伪公钥key_a加密密钥key，然后发送给M。
• M收到数据后，通过伪私钥key_b解密，得到了明文的密钥key。然后用key1加密密钥，再发送给A，最后A通过key2解密得到密钥key。

• 此时A、B、M都知道了密钥，但是A、B并不知道M已经知道了密钥，接下来的消息传递对M来说都是明文的了。

  
  

这就要用到了CA证书。CA 是一些非常权威的专门用于认证一个网站合法性的组织。服务商可以向他们申请一个证书，使得他们建立安全连接时可以带上 CA 的签名。而 CA 的安全性由操作系统或浏览器来认证。你的 Windows、Mac、Linux、Chrome、Safari 等会在安装时带上一个他们认为安全的 CA 证书列表。如果和你建立安全连接的人带着这些人的签名，那么认为这个安全连接是安全的，没有遭到中间人攻击。

CA 证书通常情况下是安全的。因为一旦某个 CA 颁发出的某个证书被用于了非法用途，浏览器和操作系统一般会通过更新将整个 CA 颁发过的全部证书全部视为不安全。这使得 CA 通常在颁发证书时是比较小心的。

所以通过 对称加密 + 非对称加密 + CA认证 这三个技术混合在一起，才使得 HTTP 的后面加上了一个 S —— Security。

HTTPS原理

下图是一个简单的原理：

• 1.浏览器输入url请求网站，并附带自己支持的一套加密规则。
• 2.网站制作证书，这个应该是网站建站的时候就已经弄好了。证书分为服务器证书和客户端证书，我们所说的证书一般都是指服务器证书。制作过程如下：
  ssl证书相关：http://www.jianshu.com/p/4494774963a9

• a) 制作CSR文件。就是制作Certificate Secure Request证书请求文件，制作过程中，系统会产生2个密钥，一个是公钥就是这个CSR文件，另一个是私钥，存在服务器上。
• b) CA认证。将CSR文件提交给CA，一般有两种认证方式：域名认证 和 企业文档认证。
• c) 证书安装。收到CA证书后，将证书部署在服务器上。

• 3.网站从浏览器发过来的加密规则中选一组自身也支持的加密算法和hash算法，并向浏览器发送带有公钥的证书，当然证书还包含了很多信息，如网站地址、证书的颁发机构、过期时间等。
• 4.浏览器解析证书。

• a) 验证证书的合法性。如颁发机构是否合法、证书中的网站地址是否与访问的地址一致，若不合法，则浏览器提示证书不受信任，若合法，浏览器会显示一个小锁头。
• b) 若合法，或用户接受了不合法的证书，浏览器会生成一串随机数的密码（即密钥），并用证书中提供的公钥加密。
• c) 使用约定好的hash计算握手消息，并使用生成的随机数（即密钥）对消息进行加密，最后将之前生成的所有消息一并发送给网站服务器。

• 5.网站服务器解析消息。用已有的私钥将密钥解密出来，然后用密钥解密发过来的握手消息，并验证是否跟浏览器传过来的一致。然后再用密钥加密一段握手消息，发送给浏览器。

• 6.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。

  
  
  
  
  
  

  另外，HTTPS一般使用的加密与HASH算法如下：
  非对称加密算法：RSA，DSA/DSS
  对称加密算法：AES，RC4，3DES
  HASH算法：MD5，SHA1，SHA256
  其中非对称加密算法用于在握手过程中加密生成的密码，对称加密算法用于对真正传输的数据进行加密，而HASH算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键，因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输，而网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。
  TLS握手过程中如果有任何错误，都会使加密连接断开，从而阻止了隐私信息的传输。正是由于HTTPS非常的安全，攻击者无法从中找到下手的地方，于是更多的是采用了假证书的手法来欺骗客户端，从而获取明文的信息，但是这些手段都可以被识别出来。

其他参考:http://www.admin5.com/article/20150505/597061.shtml
https://wenku.baidu.com/view/4112d2cf960590c69ec376b4.html
https://wenku.baidu.com/view/b753d97a79563c1ec4da715d.html?from=search