具体解释https是怎样确保安全的

Https 介绍

什么是Https

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer）。是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下增加SSL层。HTTPS的安全基础是SSL，因此加密的具体内容就须要SSL

Https的作用

• 内容加密 建立一个信息安全通道，来保证传输数据的安全。
• 身份认证 确认站点的真实性
• 数据完整性 防止内容被第三方冒充或者篡改

Https的劣势

• 对数据进行加解密决定了它比http慢

  须要进行非对称的加解密，且须要三次握手。

  首次连接比較慢点。当然如今也有非常多的优化。

出于安全考虑。浏览器不会在本地保存HTTPS缓存。

实际上，仅仅要在HTTP头中使用特定命令。HTTPS是能够缓存的。Firefox默认仅仅在内存中缓存HTTPS。可是，仅仅要头命令中有Cache-Control: Public。缓存就会被写到硬盘上。

IE仅仅要http头同意就能够缓存https内容，缓存策略与是否使用HTTPS协议无关。

HTTPS和HTTP的差别

• https协议须要到CA申请证书。
• http是超文本传输协议，信息是明文传输；https 则是具有安全性的ssl加密传输协议。
• http和https使用的是全然不同的连接方式，用的端口也不一样，前者是80，后者是443。

• http的连接非常easy，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

http默认使用80端口。https默认使用443端口

以下就是https的整个架构，如今的https基本都使用TLS了，由于更加安全，所以下图中的SSL应该换为SSL/TLS。

以下就上图中的知识点进行一个大概的介绍。

加解密相关知识

对称加密

对称加密(也叫私钥加密)指加密和解密使用同样密钥的加密算法。

有时又叫传统password算法。就是加密密钥能够从解密密钥中推算出来。同一时候解密密钥也能够从加密密钥中推算出来。

而在大多数的对称算法中。加密密钥和解密密钥是同样的，所以也称这样的加密算法为秘密密钥算法或单密钥算法。
常见的对称加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA

非对称加密

与对称加密算法不同。非对称加密算法须要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。并且加密密钥和解密密钥是成对出现的。

非对称加密算法在加密和解密过程使用了不同的密钥，非对称加密也称为公钥加密。在密钥对中。当中一个密钥是对外公开的，全部人都能够获取到。称为公钥。当中一个密钥是不公开的称为私钥。

非对称加密算法对加密内容的长度有限制。不能超过公钥长度。比方如今经常使用的公钥长度是 2048 位，意味着待加密内容不能超过 256 个字节。

摘要算法

数字摘要是採用单项Hash函数将须要加密的明文“摘要”成一串固定长度（128位）的密文。这一串密文又称为数字指纹。它有固定的长度，并且不同的明文摘要成密文，其结果总是不同的。而同样的明文其摘要必然一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因。

数字签名

数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者仅仅实用发送者的公钥才干解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息。与解密的摘要信息对照。假设同样，则说明收到的信息是完整的。在传输过程中没有被改动，否则说明信息被改动过，因此数字签名能够验证信息的完整性。
数字签名的步骤例如以下：
明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名

数字签名有两种功效：
一、能确定消息确实是由发送方签名并发出来的，由于别人假冒不了发送方的签名。

二、数字签名能确定消息的完整性。

注意：
数字签名仅仅能验证数据的完整性，数据本身是否加密不属于数字签名的控制范围

数字证书

为什么要有数字证书？

对于请求方来说。它怎么能确定它所得到的公钥一定是从目标主机那里公布的，并且没有被篡改过呢？亦或者请求的目标主机本本身就从事窃取用户信息的不正当行为呢？这时候，我们须要有一个权威的值得信赖的第三方机构(通常是由政府审核并授权的机构)来统一对外发放主机机构的公钥，仅仅要请求方这样的机构获取公钥，就避免了上述问题的发生。

数字证书的颁发过程

用户首先产生自己的密钥对。并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后，将运行一些必要的步骤。以确信请求确实由用户发送而来。然后，认证中心将发给用户一个数字证书，该证书内包括用户的个人信息和他的公钥信息，同一时候还附有认证中心的签名信息(根证书私钥签名)。用户就能够使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构公布，数字证书各不同样。每种证书可提供不同级别的可信度。

证书包括哪些内容

• 证书颁发机构的名称
• 证书本身的数字签名
• 证书持有者公钥
• 证书签名用到的Hash算法

验证证书的有效性

浏览器默认都会内置CA根证书，当中根证书包括了CA的公钥

1. 证书颁发的机构是伪造的：浏览器不认识，直接觉得是危急证书
2. 证书颁发的机构是确实存在的。于是依据CA名，找到相应内置的CA根证书、CA的公钥。用CA的公钥。对伪造的证书的摘要进行解密，发现解不了，觉得是危急证书。

3. 对于篡改的证书，使用CA的公钥对数字签名进行解密得到摘要A。然后再依据签名的Hash算法计算出证书的摘要B。对照A与B，若相等则正常。若不相等则是被篡改过的。
4. 证书可在其过期前被吊销。通常情况是该证书的私钥已经失密。较新的浏览器如Chrome、Firefox、Opera和Internet Explorer都实现了在线证书状态协议（OCSP）以排除这样的情形：浏览器将站点提供的证书的序列号通过OCSP发送给证书颁发机构，后者会告诉浏览器证书是否还是有效的。

1、2点是对伪造证书进行的。3是对于篡改后的证书验证，4是对于过期失效的验证。

SSL
与 TLS

SSL
(Secure Socket Layer，安全套接字层)

SSL为Netscape所研发，用以保障在Internet上传输数据之安全，利用数据加密(Encryption)技术。可确保数据在网络上之传输过程中不会被截取，当前为3.0版本号。

SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的传输数据開始前。通讯两方进行身份认证、协商加密算法、交换加密密钥等。

TLS
(Transport Layer Security，传输层安全协议)

用于两个应用程序之间提供保密性和数据完整性。
TLS 1.0是IETF（Internet Engineering Task Force。Internetproject任务组）制定的一种新的协议。它建立在SSL 3.0协议规范之上，是SSL 3.0的兴许版本号，能够理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议。位于某个可靠的传输协议（比如 TCP）上面。

SSL/TLS协议作用：

• 认证用户和server。确保数据发送到正确的客户机和server。
• 加密数据以防止数据中途被窃取；
• 维护数据的完整性。确保数据在传输过程中不被改变。

TLS比SSL的优势

1. 对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC）。当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。

   SSLv3.0还提供键控消息认证。但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。

2. 增强的伪随机功能（PRF）：PRF生成密钥数据。

   在TLS中，HMAC定义PRF。

   PRF使用两种散列算法保证其安全性。假设任一算法暴露了，仅仅要另外一种算法未暴露，则数据仍然是安全的。

3. 改进的已完毕消息验证：TLS和SSLv3.0都对两个端点提供已完毕的消息。该消息认证交换的消息没有被变更。然而，TLS将此已完毕消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
4. 一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
5. 特定警报消息：TLS提供很多其它的特定和附加警报。以指示任一会话端点检測到的问题。TLS还对何时应该发送某些警报进行记录。

SSL、TLS的握手过程

SSL与TLS握手整个步骤例如以下图所看到的，以下会具体介绍每一步的具体内容：

client首次发出请求

由于client(如浏览器)对一些加解密算法的支持程度不一样，可是在TLS协议传输过程中必须使用同一套加解密算法才干保证数据能够正常的加解密。在TLS握手阶段，client首先要告知服务端。自己支持哪些加密算法。所以client须要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外。client还要产生一个随机数，这个随机数一方面须要在client保存，还有一方面须要传送给服务端，client的随机数须要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

client须要提供例如以下信息：

• 支持的协议版本号。比方TLS 1.0版
• 一个client生成的随机数，稍后用于生成”对话密钥”
• 支持的加密方法。比方RSA公钥加密
• 支持的压缩方法

服务端首次回应

服务端在接收到client的Client Hello之后，服务端须要确定加密协议的版本号，以及加密的算法。然后也生成一个随机数，以及将自己的证书发送给client一并发送给client。这里的随机数是整个过程的第二个随机数。

服务端须要提供的信息：

• 协议的版本号
• 加密的算法
• 随机数
• server证书

client再次回应

client首先会对server下发的证书进行验证，验证通过之后，则会继续以下的操作，client再次产生一个随机数（第三个随机数），然后使用server证书中的公钥进行加密，以及放一个ChangeCipherSpec消息即编码改变的消息，还有整个前面全部消息的hash值。进行server验证，然后用新秘钥加密一段数据一并发送到server，确保正式通信前无误。
client使用前面的两个随机数以及刚刚新生成的新随机数，使用与server确定的加密算法。生成一个Session Secret。

ChangeCipherSpec
ChangeCipherSpec是一个独立的协议，体如今数据包中就是一个字节的数据，用于告知服务端。client已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。

server再次响应

服务端在接收到client传过来的第三个随机数的 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证。也会使用跟client同样的方式生成秘钥，一切准备好之后，也会给client发送一个 ChangeCipherSpec，告知client已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给client。以验证之前通过握手建立起来的加解密通道是否成功。

兴许client与server间通信

确定秘钥之后。server与client之间就会通过商定的秘钥加密消息了，进行通讯了。整个握手过程也就基本完毕了。

值得特别提出的是：
SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密，也就是说在SSL上传送的数据是使用对称密钥加密的！由于非对称加密的速度缓慢。耗费资源。

事实上当client和主机使用非对称加密方式建立连接后，client和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥，由于这个过程本身是安全可靠的，也即对称加密密钥是不可能被窃取盗用的，因此，保证了在传输过程中对数据进行对称加密也是安全可靠的。由于除了client和主机之外。不可能有第三方窃取并解密出对称加密密钥！

假设有人窃听通信，他能够知道两方选择的加密方法，以及三个随机数中的两个。

整个通话的安全，仅仅取决于第三个随机数（Premaster
secret）能不能被破解。

其它补充

对于非常重要的保密数据。服务端还须要对client进行验证。以保证数据传送给了安全的合法的client。服务端能够向client发出 Cerficate Request 消息，要求client发送证书对client的合法性进行验证。比方。金融机构往往仅仅同意认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包括了一张client证书。

PreMaster secret前两个字节是TLS的版本号号，这是一个比較重要的用来核对握手数据的版本号号。由于在Client Hello阶段，client会发送一份加密套件列表和当前支持的SSL/TLS的版本号号给服务端。并且是使用明文传送的。假设握手的数据包被破解之后，攻击者非常有可能串改数据包，选择一个安全性较低的加密套件和版本号给服务端，从而对数据进行破解。所以，服务端须要对密文中解密出来对的PreMaster版本号号跟之前Client Hello阶段的版本号号进行对照。假设版本号号变低。则说明被串改，则马上停止发送不论什么消息。

session的恢复

有两种方法能够恢复原来的session：一种叫做session ID，还有一种叫做session ticket。

session
ID

session ID的思想非常easy。就是每一次对话都有一个编号（session ID）。假设对话中断。下次重连的时候。仅仅要client给出这个编号。且server有这个编号的记录，两方就能够又一次使用已有的”对话密钥”，而不必又一次生成一把。

session ID是眼下全部浏览器都支持的方法，可是它的缺点在于session ID往往仅仅保留在一台server上。所以，假设client的请求发到还有一台server，就无法恢复对话

session
ticket

client发送一个server在上一次对话中发送过来的session ticket。这个session ticket是加密的，仅仅有server才干解密。当中包括本次对话的主要信息。比方对话密钥和加密方法。当server收到session ticket以后，解密后就不必又一次生成对话密钥了。

眼下仅仅有Firefox和Chrome浏览器支持。

总结

https实际就是在TCP层与http层之间增加了SSL/TLS来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书，等技术进行client与server的数据加密传输，终于达到保证整个通信的安全性。