深度了解HTTPS原理
分享于：2019-01-30 10:40:21
对于做web开发（比如PHP）的童鞋，必须熟知https是怎么回事。
在说HTTPS之前先说说什么是HTTP，HTTP就是我们平时浏览网页时候使用的一种协议。HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。
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优良血统继续为我们进行加密服务。目前TLS的版本是1.2，定义在RFC 5246中，暂时还没有被广泛的使用。
HTTPS实际上就是HTTP协议和SSL/TSL协议的组合，可以把HTTPS大致理解为“HTTP over SSL”或“HTTP over TSL”。HTTPS能够加密信息，以免敏感信息被第三方获取。所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。（其实现在大部分网站都采用https协议，抛弃了不安全的http协议）为了便于理解https原理，在了解它之前先要了解下加密的两种方式：对称加密和非对称加密。
看完上篇文章，对于HTTPS我们应该有以下几个认知：
1）使用HTTPS传输数据是安全的，因为数据都是被加密传输的；
2）使用HTTPS需要在服务器端配置密钥对（非对称加密）；
3）使用HTTPS需要花钱找专业的权威机构进行CA证书的签发。
那么使用HTTPS与网站服务器进行交互的流程和原理到底是怎样的呢？让我们先以逆向思考的方式来进行说明：
非对称加密方式虽然安全，但是由于密钥过长，加密和解密速度都远远低于对称加密。因此，出于对性能方面的考虑，HTTPS并不是把所有传输的数据都使用非对称加密的方式进行机密性的保护，而是继续使用对称加密的方式来加密数据。还有一个原因就是，使用非对称机密算法来保证数据机密性的话，需要通信双方都要有密钥对，什么意思？就是A与B通信，两人都有“钥匙”与“锁”，互相把自己的“锁”给对方。A发信息给B，需要用B的“锁”锁起来；同理，B发信息给A，需要用A的“锁”锁起来。
既然使用对称加密的方式加密数据，就需要有一个通信双方都知道的秘钥。HTTPS是通过密钥交换技术来动态协商这个密钥，实际上就是由客户端生成一个随机秘钥，然后发送给服务器端，这样就解决了秘钥的管理问题。
既然说HTTPS是安全的，那么客户端生成的这个随机秘钥肯定不能以明文的方式发送给服务器端啊。是的，当客户端以https的方式访问一个站点时，该站点会自动下发其公钥信息。客户端会使用这个公钥对产生的随机密钥进行加密，然后传送给服务器端。服务器端以自己的私钥对这个密文进行解密，然后得到这个秘钥的明文内容。至此，客户端与服务端用于对称加密和解密的秘钥协商与传输工作已经安全的完成了。
那么要通过网络获取服务器端的公钥信息，那么怎么验证该公钥信息的合法性呢？上篇文章说过，不是所有问题都能依赖技术来解决的。这里要验证公钥信息的合法性就要依靠CA证书签发机构了，网站服务的提供者必须找一个大家都信任的机构来对它提供的公钥进行签名，用户得到一个网站下发的公钥后看到有这个机构的签名就认为这个公钥是合法的，是可信赖的。
那么CA机构的签名要以什么样的形式来提供呢？实际上网站服务器下发给客户端（通常是浏览器）的公钥已经不仅仅是密钥对儿中公钥的内容了，而是包含了证书签发机构写入的其他信息的CA证书。这个CA证书中包括【证书签发机构的标识】和【证书公钥数据指纹】，当然还包含网站服务提供者的【证书公钥信息】以及【证书到期时间】等等。（数据指纹，是通过以不可逆的单向加密算法对数据提取特征码，例如md5加密。）单向加密只能保证数据的完整性，不能保证数据机密性。
CA证书的伪造者完全可以伪造公钥信息并生成相应的数据指纹，然后发送给用户。那么现在的问题就变成了要验证CA证书中公钥的合法性以及CA证书提供者的身份了。
其实每个CA证书的签发机构也都有自己的密钥对，他们放在CA证书中的【证书公钥数据指纹】是通过自己的私钥加密过的，而这些【CA证书签发机构的公钥】是被各浏览器厂商内置在浏览器内部的。
当浏览器接收到某网站服务器下发的CA证书后，会根据CA证书中签发机构的标识来读取浏览器内置的相应【CA证书签发机构的公钥】，通过这个公钥信息对【证书公钥数据指纹密文】进行解密就可以得到CA证书中包含的真实的【证书公钥数据指纹】。浏览器再通过单向加密的方式自己计算一次CA证书中包含的【证书公钥信息】的数据指纹，两个数据指纹一致则说明这个CA证书确实是该CA机构签发的，同时也证明了CA证书中的公钥信息没有被篡改过。至此，所有的问题就都解决了。
现在我们再来以正常的顺序描述一下使用HTTPS与网站服务器进行交互的过程：
1）浏览器A与网站服务器B通过三次握手后建立网络连接。
2）浏览器A告诉网站服务器B：我想跟你通过HTTPS协议进行秘密交流。
3）网站服务器B把包含自己公钥信息的CA证书下发给浏览器A，并告诉浏览器A这个CA证书里有我的公钥信息，你决定一个对称加密使用的秘钥串，然后通过这个公钥加密后发送给我。
4） 浏览器A接收到网站服务器B下发的CA证书后，对这个CA证书的及其包含的公钥信息的合法性表示怀疑。于是根据CA证书中包含的证书签发机构的标识找到【自身内置的该签发机构的公钥】对CA【证书中公钥的数据指纹】进行解密，然后再自己计算一下【CA证书中公钥】的数据指纹，对了一下这两个数据指纹是一致的。浏览器A放心了，知道这个CA证书是合法的，CA证书中的公钥也没有被篡改过。
5）然后浏览器A通过通过密钥协商技术产生了一个随机的字符串作为与网站服务器B进行秘密通信的密钥，并把这个密钥通过CA证书中包含的公钥进行加密后发送给网站服务器B。
6）网站服务器B接收到密文格式的密钥后，通过自己的私钥进行解密得到密钥的明文内容。
7）浏览器A和网站服务器B开始了秘密交流。
再以图解的方式说一下：
HTTPS有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。
1. 客户端发起HTTPS请求
在浏览器里输入一个https网址，然后连接到server的443端口。浏览器把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）发送给服务端。
2. 服务端的配置
服务端，接收到客户端所有的Cipher后与自身支持的对比，如果不支持则连接断开，反之则会从中选出一种加密算法和HASH算法以证书的形式返回给客户端。数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。
3. 传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
4. 客户端解析证书
这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值。然后用证书里的公钥信息对该随机值进行加密。
5. 传送加密信息
这部分传送的是用公钥加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
除了公钥加密后的随机值，使用最开始约定好的HASH方式，把握手消息取HASH值，然后用 随机数 加密 “握手消息+握手消息HASH值(签名)” 并一起发送给服务端。
在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。
6. 服务段解密信息
服务端用私钥解密后，得到了客户端传过来的随机数(秘钥)，再用随机数 解密 “握手消息与HASH值”，并与传过来的HASH值做对比确认是否一致。然后用随机数加密一段握手消息(握手消息+握手消息的HASH值 )给客户端。
7. 传输加密后的信息
这部分信息是服务端用随机数(秘钥)加密后的信息，发送给客户端。
8. 客户端解密信息
客户端用随机数(秘钥)解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束。之后所有的通信数据将由随机数(秘钥)利用对称加密算法进行加密，因为这串密钥只有客户端和服务端知道，整个过程第三方即使监听到了数据，也束手无策，以此保证了通信的安全。
总的说，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。
HTTPS协议和HTTP协议的区别：
https协议需要到ca申请证书，一般免费证书很少，需要交费。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl/TLS加密传输协议。
http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
http的连接很简单,是无状态的 。
HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议， 要比http协议安全。