HyperText Transfer Protocol，超文本传输协议，是互联网上使用最广泛的一种协议，所有WWW文件必须遵循的标准。HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。
Hyper Text Transfer Protocol over Secure Socket Layer，安全的超文本传输协议，网景公式设计了SSL(Secure Sockets Layer)协议用于对Http协议传输的数据进行加密，保证会话过程中的安全性。
SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定义在RFC 6101中，之后IETF对SSL 3.0进行了升级，于是出现了TLS（Transport Layer Security） 1.0，定义在RFC 2246。实际上我们现在的HTTPS都是用的TLS协议，但是由于SSL出现的时间比较早，并且依旧被现在浏览器所支持，因此SSL依然是HTTPS的代名词，但无论是TLS还是SSL都是上个世纪的事情，SSL最后一个版本是3.0，今后TLS将会继承SSL优良血统继续为我们进行加密服务。
本文将详细介绍https是如何实现安全传输的。
我们先不了聊HTTP，HTTPS，我们先从一个聊天软件说起，我们要实现A能发一个hello消息给B：
我们要达到的目标是：A发给B的hello消息包，即使被中间人拦截到了，也无法得知消息的内容。
如何做到真正的安全
对于解决方案，很容易就想到了对消息进行加密，什么对称加密、非对称加密、DES、RSA、XX~
对于A与B这样的简单通信模型，我们很容易做出选择：
这就是对称加密算法，其中图中的密钥S同时扮演加密和解密的角色。
只要这个密钥S不公开给第三者，同时密钥S足够安全，我们就解决了我们一开始所定的目标了。因为世界上有且只有A与B知道如何加密和解密他们之间的消息。
但是，在WWW环境下，我们的Web服务器的通信模型没有这么简单：
如果服务器端对所有的客户端通信都使用同样的对称加密算法，无异于没有加密。那怎么办呢？即能使用对称加密算法，又不公开密钥？
答案是：Web服务器与每个客户端使用不同的对称加密算法。
如何确定对称加密算法
我们的服务器端怎么告诉客户端该使用哪种对称加密算法？
当然是通过协商。
但是，你协商的过程是没有加密的，还是会被中间人拦截。
这个协商过程也需要进行加密才行，协商的过程加密如果再使用这种对称加密就会陷入死循环了。
如何对协商过程加密
密码学领域中，有一种称为“非对称加密”的加密算法，特点是 私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。
虽然服务器端向A、B……的方向还是不安全的，但是至少A、B向服务器端方向是安全的。
如何协商加密算法的问题，我们解决了：使用非对称加密算法进行对称加密算法协商过程。
这下，你明白为什么HTTPS同时需要对称加密算法和非对称加密算法了吧？
协商什么加密算法
要达到Web服务器针对每个客户端使用不同的对称加密算法，同时，我们也不能让第三者知道这个对称加密算法是什么，怎么办？
使用随机数，就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才确定加密算法。
这下，你明白为什么HTTPS协议握手阶段会有随机数了吧。
如何得到公钥
细心的人可能已经注意到了如果使用非对称加密算法，我们的客户端A，B需要一开始就持有公钥，要不没法开展加密行为。
这下，我们又遇到新问题了，如何让A、B客户端安全地得到公钥？
我能想到的方案只有这些：
方案1. 服务器端将公钥发送给每一个客户端
方案2. 服务器端将公钥放到一个远程服务器，客户端可以请求得到
我们选择方案1，因为方案2又多了一次请求，还要另外处理公钥的放置问题。
公钥被调包了怎么办
但是方案1有个问题：如果服务器端发送公钥给客户端时，被中间人调包了，怎么办？
显然，让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。
使用第三方机构的公钥
公钥被调包的问题出现，是因为我们的客户端无法分辨返回公钥的人到底是中间人，还是真的服务器。这其实就是密码学中提的身份验证问题。
既然服务器需要将公钥传给客户端，这个过程本身是不安全，那么我们为什么不对这个过程本身再加密一次？可是，你是使用对称加密，还是非对称加密？这下好了，又陷入死循环了。
问题的难点是如果我们选择直接将公钥传递给客户端的方案，我们始终无法解决公钥传递被中间人调包的问题。
所以，我们不能直接将服务器的公钥传递给客户端，而是第三方机构使用它的私钥对我们的公钥进行加密后，再传给客户端。客户端再使用第三方机构的公钥进行解密。
下图就是我们设计的第一版“数字证书”，证书中只有服务器交给第三方机构的公钥，而且这个公钥被第三方机构的私钥加密了：
如果能解密，就说明这个公钥没有被中间人调包。因为如果中间人使用自己的私钥加密后的东西传给客户端，客户端是无法使用第三方的公钥进行解密的。
漏掉了一个场景：第三方机构不可能只给你一家公司制作证书，它也可能会给中间人这样有坏心思的公司发放证书。这样，中间人就有机会对你的证书进行调包，客户端在这种情况下是无法分辨出是接收的是你的证书，还是中间人的。因为不论中间人，还是你的证书，都能使用第三方机构的公钥进行解密。
第三方机构向多家公司颁发证书的情况：
客户端能解密同一家第三机构颁发的所有证书：
最终会导致其它持有同一家第三方机构证书的中间人可以进行调包吗？
答案是：不能。
数字签名
要解决这个问题，我们首先要想清楚一个问题，辨别同一机构下不同证书的这个职责，我们应该放在哪？
只能放到客户端了。意思是，客户端在拿到证书后，自己就有能力分辨证书是否被篡改了。如何才能有这个能力呢？
我们从现实中找灵感。比如你是HR，你手上拿到候选人的学历证书，证书上写了持证人，颁发机构，颁发时间等等，同时证书上，还写有一个最重要的：证书编号！我们怎么鉴别这张证书是的真伪呢？只要拿着这个证书编号上相关机构去查，如果证书上的持证人与现实的这个候选人一致，同时证书编号也能对应上，那么就说明这个证书是真实的。
第三方机构在颁发证书的时候都会填写域名字段，域名就相当于网站的身份证一样，如果确认这个证书是真实的，只需要核对你的域名即可。
如何获取第三方机构公钥
第三方机构的公钥怎么跑到了客户端的机器中呢？世界上这么多机器。
其实呢，现实中，浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。
题外话：如果浏览器和操作系统这道防线被破了，就没办法。
CA颁发证书
CA如何颁发给我们的网站管理员，而我们的管理员又如何将这个数字证书放到我们的服务器上。
我们如何向CA申请呢？每个CA机构都大同小异：
拿到证书后，我们就可以将证书配置到自己的服务器上了。此处略过。
HTTPS过程
开始加密通信之前，客户端和服务器首先必须建立连接和交换参数，这个过程叫做握手（handshake）。
假定客户端叫做爱丽丝，服务器叫做鲍勃，整个握手过程可以用下图说明。
握手阶段分成五步。
第一步，爱丽丝给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
第二步，鲍勃确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
第三步，爱丽丝确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。
第四步，鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。
第五步，爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成”对话密钥”（session key），用来加密接下来的整个对话过程。
上面的五步，画成一张图，就是下面这样。
握手阶段有三点需要注意：
（1）生成对话密钥一共需要三个随机数。
（2）握手之后的对话使用”对话密钥”加密（对称加密），服务器的公钥和私钥只用于加密和解密”对话密钥”（非对称加密），无其他作用。
（3）服务器公钥放在服务器的数字证书之中。
整个握手阶段出现三个随机数，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把”会话密钥”。
至于为什么一定要用三个随机数，来生成”会话密钥”：
不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。
HTTPS双向认证
上面的HTTPS过程就是单向的认证，私钥只在服务器存有。
所谓的双向认证就是客户端也存有自己的私钥。
在客户端验证完服务端证书有效之后，客户端会把自己私钥对应的数字证书发送给服务端，服务端同样验证通过之后才会继续执行剩下的认证过程。
服务端验证客户端证书有效性的过程同客户端验证服务端证书。
客户端的证书，私钥从哪来呢？
我们应该使用过银行或者支付宝的系统，在登录或交易时会要求给电脑安装数字证书，这个安装数字证书的过程就是给电脑颁发客户端证书。
银行给我们的UsbKey其实也是存的客户端证书，这种比浏览器安装的又安全了一层。
总结HTTPS
HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。
参考资料
- http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
- http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html
- http://blog.jobbole.com/110354/
- https://www.cnblogs.com/zery/p/5164795.html
- http://blog.jobbole.com/104919/