https加密套件版本

⑴ 加速ssl https 程序怎么优化

主要响应速度，提升自己的加密套件版本，服务器apache尽量使用最新，使用国内的服务器就可以了。

⑵ 详解https是如何确保安全的

（多文字预警）

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

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

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

对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中，加密密钥和解密密钥是相同的，所以也称这种加密算法为秘密密钥算法或单密钥算法。
常见的对称加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA

与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）；并且加密密钥和解密密钥是成对出现的。非对称加密算法在加密和解密过程使用了不同的密钥，非对称加密也称为公钥加密，在密钥对中，其中一个密钥是对外公开的，所有人都可以获取到，称为公钥，其中一个密钥是不公开的称为私钥。

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

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

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

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

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

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

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

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

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

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

SSL与TLS握手整个过程如下图所示，下面会详细介绍每一步的具体内容：

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

客户端需要提供如下信息：

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

服务端需要提供的信息：

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

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

后续客户端与服务器间通信
确定秘钥之后，服务器与客户端之间就会通过商定的秘钥加密消息了，进行通讯了。整个握手过程也就基本完成了。

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

PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。

session ID
session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的”对话密钥”，而不必重新生成一把。

session ticket
客户端发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。

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

收录自| 原文地址

⑶ https详解

TCP三次握手；
TLS/SSL的连接；
HTTP的请求和响应；

前提介绍（证书校验）
服务端传递一个证书，客户端是怎么来验证其中是没有问题的
1.证书大致包含了哪些数据？
证书的申请者，证书的颁发者，证书的有效期，证书的公钥，证书的指纹，证书的指纹算法，证书的数字签名

2.如何验证证书是否是完整的？
1.首先根据该证书的颁发者找到对应的颁发者的公钥对该证书的数字签名进行解密，然后得到一个证书的指纹和证书的指纹算法；
2根据证书的指纹算法对整个证书进行加密得到指纹；
3对比两个指纹，如果一致说明证书是完整的；

3如何验证证书是否是被全部替换？
在请求网络的时候，可以对比下请求的Url和证书的Url，如果不一致的话，说明证书被全部替换，一致的话说明是正确的证书；

Tcp的三次握手之前的文档已经介绍了，现在来介绍下TLS/SSL的连接过程；

1.客户端->服务端 （安全协议和版本（SSL和TSL）， 客户端支持的所有的加密套件列表，client Random）；
2服务端->客户端 （安全协议和版本（SSL和TSL），服务端选中的加密套件， server Random， 证书， 秘钥交换服务端的参数）
客户端会去验证该证书的有效性
3.客户端->服务端 （秘钥交换客户端的参数）
这个时候双方都含有了四个数据（client Random， server Random ， 秘钥交换客户端参数和服务端参数）；
根据后面两个参数等到预主秘钥（Pre-master secret）；
最后三个参数生成用以加密会话的会话秘钥；
4.客户端->服务端 （告诉后台去采用会话秘钥去加密）；
5.客户端->服务端（使用会话秘钥对之前的的全部报文进行加密，然后传递到服务端）
6.服务端->客户端（使用会话秘钥加密解密，然后结束这段握手，进行之后的htpp请求和响应）

⑷ HTTPS的前世今生和原理详解

HTTPS网络：

HTTP是明文传输的协议，数据很容易被窃听和篡改，并且攻击者很容易冒充客户端和服务端，HTTPS可以解决这两个的安全问题。HTTS仍是HTTP协议，只是在HTTP与TCP之间添加了用于加密数据的TSL/SSL协议。很多其它应用层的协议也采用在传输层之上添加TSL/SSL协议来保证安全，如FTPS、IMAPS。

加密和解密使用的是同一个密钥。加密和解密的双发都需要持有同一个密钥。常见对称加密算法：AES、DES、3DES。

加密和解密使用的是不同的密钥，加密时使用的密钥称为公钥匙，解密是使用的密钥称为私钥。使用公钥加密的密文只能用私钥解开。公钥可以发布出去使用，但私钥一定不能泄漏。常见的非对称加密算法：RSA、背包算法、ECC。

数字签名用于校验数据是否被篡改，即数据是否和原数据是否一致。
数字签名包含签名和验证两个运算。数字签名具有不可抵赖性，签名验证正确后就不能否认。
数字签名一般包含一个自己知道的私钥和一个公开的公钥，与传统的加密不同的是签名时使用私钥，验证签名是使用公钥。

1994年Netscape提出了SSL协议并制订了SSL协议的原始规范，即SSL1.0。但由于SSL1.0使用的是弱加密算法而受到密码学界的质疑，所以SSL1.0并没有公共发布。

SSL1.0之后Netscape对SLL协议规范进行了重大改近，并在1995年发布 SSL2.0协议 。虽然SSL2.0版本被认为是一个相当强大且健壮的协议，但仍存在一些易受攻击的漏洞，所以并没有得到广泛的使用。

由于SSL2.0的安全问题，Netscape联合哈佛的Paul Kocher等人重新设计了SSL协议，并在1996年发布，即SSL3.0版本，该版本较2.0版本有较大的差别。 SSL 3.0协议 获得了互联网广泛认可和支持。

随着互联网的飞速发展，网络安全越来越重要，业界非常迫切的需要一个标准的安全协议，于是IETE接手了SSL协议，并将其更名为 TSL（Transport Layer Security Protocol，安全传输层协议 ，并在1999年发布了TSL1.0版本。
不过TSL1.0于SSL3.0差别并不大（TLS 1.0 内部的协议版本号其实是3.1）。
虽然TSL是SSL的升级，但一些称呼上还存在混淆，所以大家通常将二者统称为SSL/TLS协议。

TSL1.1 于2006年发布，主要是修复了一些漏洞。

TSL1.2于2008年发布，1.2版本主要移除了一些老旧的加密套件，并引入了 AEAD 加密模式。1.2版本是目前应用最广泛的版本。

TSL1.3 于2018年发布。1.3版本在2014年提出，经4年的反复修改直到第28个草案才于2018年正式纳入标准。
1.3版本相较1.2版本有很大的改动，即增强了安全性也也大大提升了访问速度。主要有以下改动：

在公网通讯时想要保证通信信道的安全，目前来看只有将通信的数据进行加密后可防止窃听、冒充和篡改。

防止窃听：
数据加密后传输的就是加密后的密文，这些密文即使被窃听了但在没有解密的密钥的情况下是得不到真正的内容的。

防冒充和篡改：
通讯的数据加密后传输，在没有加密用的秘钥的情况下时无法构造出合法的数据包的，也就无法冒充或篡改数据。

将通信数据加密后传输可以解决很多的安全问题，但要实现通信的加密最为关键的点在于通信的双发用于加密的密钥怎么协商才能保证密钥不被泄漏和篡改那？密钥协商是HTTPS中最大的难点。

通信时使用对称加密，并且在客户端请求时直接将对称加密的密钥返回给客户端。
但在安全的信道建立起来之前任何传输仍是明文的，使用明文风发密钥毫无安全性可言，并且由对称加密使用同一个密钥，所以第三方在窃听到密钥后即可以窃听和篡改数据也可以冒充客户端和服务端。 所以直接分发对称加密的密钥显然行不通。

为方便说明这里只看客户端单向向服务端发送数据的情况，服务端向客户端发送数据与其类似。
通信时使用非对称加密，在客户端请求时将公钥放回给客户端。
但返回公钥时仍然是明文传输的，所以公钥还是很容易就会被泄漏，泄漏了公钥后，虽然第三方无在没有密钥的情况下是没法窃听数据或直接冒充服务端，但由于泄漏了公钥第三方还是可以冒充客户端或者进行‘中间人’攻击。
所以单纯使用非对称加密也是行不通的。

'中间人’攻击：

只要通信时使用的密钥不泄漏，那么在通信时完全没必要使用非对称加密，毕竟对称加密的效率更高。所以可以在通信正式开始前使用非对称加密来协商出通信时使用的对称加密的密钥，步骤如下：

虽然对称加密与非对称加密结合可以使我们或得两种的优点，但这样还是无法避免‘中间人’攻击。

DH密钥协商算法不会直接交互密钥，而是交互用于生产密钥的参数，DH算法基于当前‘无法’对大数进行质数分解来保证即使参数泄漏了，第三方也无法通过参数推导出密钥。
DH算法密钥协商步骤：

通过以上步骤客户端和服务端就协商出了密钥s，并且整个过程中没有传输过s。为了防止被破解a和b通常非常大，p 是一个至少 300 位的质数，g一般很小通常是3或者5.
但DH算法的缺点也很明显，DH无法防止冒充，还是会受到中间人攻击。

数字证书（digital certificate），又称公开密钥认证（Public key certificate）或身份证书（identity certificate），用来下发公钥匙和证明公钥拥有者的身份。

证书由第三机构颁发用来验证服务提供方的合法性，使用时服务提供方将证书给到客户端，客户端通过特定的机制验证书的合法性，从而信任提供证书的服务端和证书中的公钥。

数字证书以文件的形式存在，证书文件中包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对数字证书自身的数字签名，证书的数字签名用来保证证书没有被篡改。

一般我们向CA申请证书时不用我们我们提供公钥和私钥，CA会给我们分配一个密钥对，并将公钥写到证书中，然后将证书和私钥给我们。

证书有统一的标准，其合法性（证书是否过期、数字签名是否有效、颁发的机构是否可信）通过一定的程序按标准来进行验证，如浏览器会保证HTTPS证书是否是合法的，linux下openSSL库提供了证书验证功能。

核对证书后若证书可信，就可以使用证书中的公钥对数据进行加密与证书的拥有者进行通信。

HTTPS的证书在扩展字段中包含了域名相关的信息，所以HTTPS的证书在申请的时候CA会严格的校验申请的机构或个人是否真的拥有这个域名。

数字证书认证机构（英语：Certificate Authority，缩写为CA）。证书标准是公开的任何人都可以去制作证书，但自己制作的证书是不受信任的，只有权威的CA机构颁发的证书才被信任。

权威的CA证书审核和部署流程严苛而繁杂，所以权威的根证书的有效期一般在几十年内。
也只有权威的CA的根证书会被各大操作系统支持，将其预制与操作系统内。

证书一般遵循X.509规范，主要包含以下内容：

CA生成的证书包含以上内容和一些扩展字段外，还包含CA使用自己的私钥对这些内容进行加密后的密文。在验证证书时使用CA的根证书对秘文进行验证，从而判断证书是否是合法的。

权威结构使用根证书来签发二级CA证书，二级CA证书可以给其它服务签发证书。但不是所有证书都可以继续签发新的证书，证书使用基础约束扩展来限制证书的签发，我们普通申请到证书基础约束扩展都是False的。查看根证书的基本约束可以看到证书颁发机构为‘是’。

根证书并不直接签发服务的证书，只要基于以下两点：

上一级证书对下一级证书进行签名，签名值包含在证书中，可以使用上一级证书中的公钥来验证下一级证书的签名值。根证书的签名是自己签的，并且验证签名的公钥包含在根证书中。

完整的证书连的关系应该有服务器放回，但有的并没有返回，对于没有放回完整证书连的证书，证书中的扩展字段CA 密钥标识符( Authority Key Identifier)记录了证书的上一个证书，通过该字段获取到上一级中间证书，再从中间证书的该字段中继续向上查找，直到根证书。
服务端最好可以返回证书连，这样可以避免浏览器自己去查找，提示握手速度。服务器返回的证书链并不包含根证书，根证书预至与操作系统内部。

在linux中openssl库会集成根证书。openssl的根证书的存放路径通过‘openssl version -a’查看。

校验证书时先根据证书链逐级校验证书的签名，签名校验的最关键的在根证书。根证书预至于操作系统中，CA要将自己的证书预至与各个系统中是非常困难的，所以预支与系统中的根证书是可信的。

回顾一下对于HTTPS的证书来说申请的时候CA会严苛的验证，保证这个域名是属于申请这个证书的机构的。这样攻击者或许可以伪造一个改域名的证书，但伪造的证书的根证书在系统中并不会存在，所以伪造的证书是不会被信任的。这样通过证书链的校验就可以有效的防止服务端被‘冒充’。

经过上面证书数字签名验证只是验证了证书确实是合法的证书，后还要验证证书的有效性，有效性验证主要包括以下字段：

验证合法的证书也可能由于种种原因被吊销，如证书的私钥泄漏了、证书错发了等，为了验证证书是否有效引入了证书吊销机制。

OSCP是证书提供方提供的证书验证接口，用户通过调用OSCP接口验证证书是否被吊销了。
但OCSP服务可能因为策略或服务故障导致无法访问，这时一般浏览器会选择信任证书，毕竟证书被吊销的情况只是极少数。也有部分CA将OCSP失败后的策略写到证书的扩展字段中，用用户根据扩展字段去做处理。
OSCP方式有自己明显的缺陷，为了验证证书而请求OSCP的同时也将自己在什么时候访问了什么服务也告诉了CA，CA利用我们的访问数据作恶咋办，还有OCSP的接口很慢的话不就拖慢了我们服务的相应数独。为了解决这两个问题各大CA厂商联手推出了CRL方案。

CRL方案是将被吊销的证书列表定期拉去到本机，一般是几天拉取一次。在校验证书时去本机列表中查找。
CA会在证书的扩展字段中写入CRL更新的地址：

CRL也有自己明显的确定，首先CRL是定期拉取的不能保证实时生效，然后CRL的列表一般很大可能达到数M。

CRLSet是chrome自建自用的解决方案。google觉得CRL更新太慢了，每个CA都有自己的CRL并且CRL内容也太多了。于是自己搞了一个CRLSet，将各大CA被吊销的高风险证书添加到CRLSet中，chrome在校验证书时可以去自己CRLSet中校验。
CRLSet只有各个CA吊销的证书的部分，大概包含所有吊销证书的2%。
CRLSet的更新相对快一些，最慢几个小时就会从各个CA中更新一次，CRLSet可以用在需要紧急吊销证书的情况下让吊销快速生效。

CRLSet提供了 https://github.com/agl/crlset-tools 工具来拉取和校验证书是否在CRLSet中。

可以在 chrome://components/ 中更新chrome的CRLSet

客户端向服务端发送hello请求，里面包含了客户端SSL/TSL的版本、支持的加密套件和一个随机数Random1

服务端收到客户端的hello后，根据客服端支持的加密套件和自己支持的加密套件选择出后面使用的加密和散列套件并返回给客户端，同时返回的还有服务端生产的一个随机数 Random2

服务端向客户端返回自己的证书，客户端收到证书后通过校验证书来信任服务端，并从证书中获取到证书中的公钥。

服务端在返回证书后会立即向客户端发送该请求。不过该请求不是必须的，只有选择的加密套件需要额外的参数是才会发送该请求交互参数。
如果密钥协议商算法是DH算法，那么DH的参数就在该请求中返回给客户端，DH算法有以下几种：DHE_DSS、DHE_RSA、ECDHE_ECDSAECDHE_RSA
dh算法会返回dh的参数p、g、dh的公钥和公钥的签名，公钥即g^b mod p，b为服务端的随机数

这里g就是0X03，p就是0X0017。

服务端在发送完上述信息后，就会立马发送Server Hello Done，来告知客户端服务端的相关信息已经发送完毕，就等客户端开始做密钥协商了。
客户端在收到该消息后就开始验证证书，协商密钥等工作。

在接受到服务器的Server Hello Done信息之后，客户端会计数出预备主密钥，并将其返回给服务端。

如果使用的是RSA/ECDSA算法，那么发送的就是预备主密钥。
如果使用的是DH算法，那么发送的就是通过之前的参数计数出来的公钥匙，即B（ g^b mod p）服务端在收到B后通过 B ^ a mod p得到第三个随机数。而客户端已经通过s = A b mod 得到了s。

到了这里服务端和客户端已经得到了三个随机数，通过之前协商好的加密算法使用这个三个随机数就得到一个对称加密的密钥，后面通信时就使用该密钥。

该请求用于通知对方已经计数出通信用的密钥，接下来的通信都使用该密钥进行。服务端和客户端都会发出该请求，一般是服务端先发出。

在完成上述步骤以后，双发都会发送一个Finished请求给对方，Finished的数据是通过协商好的密钥加密的，以此来验证之前协商好的密钥、协议版本是否是有效的。

参考资料：

⑸ 如何查看本机能够支持的https加密算法套件

HTTPS加密算法，来自于签发机构的SSL证书CSR文件，也就是说签发完毕的证书加密算法，就一定定向了，您可以打开这个网站，就说明就是支持，算法：sha256 加密位数：2048，是证书常见的标准，你可以打开网络知道，就说明支持的。

⑹ 温故而知新之HTTPS

对于HTTPS其实很早之前就有过学习，但对其一直是一知半解，知道的并不深入全面，因此用了些时间，好好地阅读了极客时间关于HTTPS的一些专栏，并总结一下尝试着用自己的话来描述一下。

HTTP最初的目的：传输超文本文件，因此一直是明文传输文件，而且不安全。由于是明文传输，所以就很容易被中间人所截取，一切通信的内容也被这个中间人所掌握。这也就是常说的中间人攻击。

那如何定义通信过程是安全的呢：机密性，完整性，身份验证以及不可否认：

机密性：简单来说就是数据是加密过的，除了参与通信之外的人都是都是看不了的。

完整性：数据在通信的过程中是完整的，没加经过篡改的。

身份认证：通信双方可以验证对方的真实身份

不可否认：不能否认已经发生过的行为

因为是明文传输，所以在一些对安全要求高的场景就不能很好的满足需求，因此在原有的基础上引入了加密方案，在TCP和HTTP之间加入了一个安全层SSL/TLS

SSL全名叫Secure Sockets Layer中文名叫 安全套接层，在 OSI 模型中储运第五层会话层的位置。这玩意儿是由网景公司所发明，并在其发展到 V3 的时候被 IETF 改名为 TLC（Transport Layer Security），并对其进行标准化。而 TLS 发展到现在也经历了三个版本，最新的版本是2018年所制定的，牢牢的将密码学的发展与当今互联网的现状相结合，持续提高安全与性能，因此也成为信息安全领域的权威标准。

而它的职责也很简单：

当浏览器客户端和服务端在使用 TLS 进行通信时，需要选择一组合理的加密算法来实现安全通信，而这些算法的组合通常被称为：加密套件。它的命名是很规范的，基本形式就是：密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法。其中，签名算法可以进行身份验证，摘要算法可以保证数据的完整性，而对称加密算法则可以保证数据的机密性。（值得注意的是，在2019年不安全的 TLS 1.0 和 1.1 默认被禁用（ Safari TP 91 、Google Chrome 72+、Firefox Nightly）

前面我们提到，HTTP协议在进行传输的时候是通过明文进行传输的，因此不安全。那么如果需要保证传输信息的机密性，最简单的方法不外于将其进行加密，这样第三方的人在拿到这些信息的时候，也就不能获取信息里面的内容了。因此这就引入了加密的第一个概念：对称加密。

对称加密其实很简单：加密和解密都使用的是相同的密钥，是对称的，这里的密钥就是用于解开加密信息的钥匙。

简单来说就是客户端会给服务端发送它支持的加密的方法的列表，以及一个随机数，然后服务器端在接受到这些东西后，会从客户端所支持的加密方法列表中选取一种，然后同时生成一个随机数给客户端，这样两端就都确定了加密方法和随机数，也就可以通过这些信息来生成对应的密钥了。这样做的话即使黑客在获取到浏览器与服务器所传输的信息，得到的也只是一串乱码，而他也没有相应的密钥，也就保证了信息传输的机密性。

TLS中所提供的对称加密算法有很多，其中最常用的当属 AES（Advanced Encryption Standard）既高级加密标准，密钥的长度可以是128，192，256，是当今用的最为广泛的对称加密算法。当然除了上面这个AES之外，我们国家也存在这自己的一套对称加密算法：SM1 和 SM4。其中SM1算法不公开，属于国家机密，而 SM4 则是公开的，可以自行使用，这两个算法的最大的优势就在于：国家支持！

对称加密还有一个分组的概念，他可以让算法用固定的长度的密钥加密任意长度的明文，从而将密钥转化为密文。最新的分组模式叫做AEAD，在加密的同时还增加了认证的功能。

对称加密就是通过上面的这些东西，来完成一个简单却安全的加密方式的。

对称加密看起来的确是解决了我们所说的安全要素中的机密性的要求，但它仍然存在一个致命的漏洞就是：密钥交互的方式仍然是明文的。也正是为了解决密钥安全的问题，我们就需要使用非堆成加密的方法，那什么是非堆成加密呢？非对称加密简单来说就是有两把私钥，一把是公钥，可以公开给任何人使用，一把是私钥，需要严格保密。这就形成了一个非对称性。具体举个栗子来讲就是：有 A、B 两把密钥，如果你用 A 密钥来加密，那么只能使用 B 密钥来解密；反过来，如果你要 B 密钥来加密，那么只能用 A 密钥来解密。

非对称加密除了可以对信息进行加密外，很多非对称加密算法还有签名的功能，这样就可以提供身份认证，保证通信双方可以确定对面的身份。

而从实现上来讲，所有的非对称加密算法，都是基于各种数学难题来设计实现的，这些难题的特点在于：正向计算很简单，反向推倒是无解的。其中比较经典的非对称加密算法包括：RSA，ECC以及SM2。

RSA 是所使用的数学难题是：两个大的质数相乘的结果很容易计算，但根据这个结果去做质因分解得到原先的两个质数，则需要很大的计算量。就比如这个：

https://lists.gforge.inria.fr/pipermail/cado-nfs-discuss/2019-December/001139.html 。

前段时间美国一群大佬宣布，240哥十进制的整数分解成功，找到了它的两个大质数因子，不过这个成本也是很大的。

ECC和 SM2 都是是基于椭圆曲线的数学难题设计的。普遍的观点认为，椭圆曲线的难度高于大质数难题，160 位密钥的 ECC 加密强度，相当于 1088 位密钥的 RSA。因为密钥短，所以相应的计算量、消耗的内存和带宽也就少，加密解密的性能就上去了，因此对于互联网行业来讲吸引力也是相当大的。而SM2除了加密强度和国际标准和ECC差不多以外，还属于国家所支持的非对称加密算法。

需要注意的是，非对称加密的安全性上虽然可以满足我们的需求，但它却存在这一个比较大的问题就是L：性能。由于非对称加密在所需要的算法运算非常复杂，因此在性能上得不到很好的保证。也正是由于这个原因，现在的TLS主要采用的是一种叫混合加密的方式来进行加密。

混合加密其实很简单，就是使用非对称加密的方式，解决密钥交换的问题，然后用随机数产生对称算法使用的会话密钥，在对其使用公钥加密，并传送给通信对象。通信对象拿到密文后用私钥解开并取出会话密钥。这样就是实现了堆成密钥的安全交换了，后续就可以使用这个对称密钥来进行对称加密。

在前面我们有提到过安全的几大要素，其中机密性我们可以通过上面的对称加密 + 非对称加密来解决。而在完整性方面，我们则需要使用摘要算法来解决。

简单理解，我们可以将摘要算法理解为一种特殊的压缩算法，他可以将任意长度的数据压缩成固定长度且独一无二的摘要字符串，且这个加密的过程也是单向的，加密后的数据无法解密，不能从摘要中反向推出原文。

https://time.geekbang.org/column/article/176569

https://time.geekbang.org/column/intro/189 ——安全篇

⑺ 详解https是如何确保系统安全的

• https协议需要到CA申请证书。

• http是超文本传输协议，信息是明文传输；https 则是具有安全性的ssl加密传输协议。

• http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

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

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

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

客户端首次发出请求

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

客户端需要提供如下信息：

• 支持的协议版本，比如TLS 1.0版

• 一个客户端生成的随机数，稍后用于生成”对话密钥”

• 支持的加密方法，比如RSA公钥加密

• 支持的压缩方法

服务端首次回应

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

服务端需要提供的信息：

• 协议的版本

• 加密的算法

• 随机数

• 服务器证书

客户端再次回应

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

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

服务器再次响应

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

后续客户端与服务器间通信

确定秘钥之后，服务器与客户端之间就会通过商定的秘钥加密消息了，进行通讯了。整个握手过程也就基本完成了。

值得特别提出的是：
SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密，也就是说在SSL上传送的数据是使用对称密钥加密的！因为非对称加密的速度缓慢，耗费资源。其实当客户端和主机使用非对称加密方式建立连接后，客户端和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥，由于这个过程本身是安全可靠的，也即对称加密密钥是不可能被窃取盗用的，因此，保证了在传输过程中对数据进行对称加密也是安全可靠的，因为除了客户端和主机之外，不可能有第三方窃取并解密出对称加密密钥！如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解。

其他补充

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

PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

session的恢复

有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。

session ID

session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的”对话密钥”，而不必重新生成一把。

session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话

session ticket

客户端发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。

目前只有Firefox和Chrome浏览器支持。

总结

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

⑻ https加密是什么意思呢

HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的HTTP通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 。HTTPS在HTTP的基础下加入SSL层，HTTPS 的安全基础是SSL，因此加密的详细内容就需要SSL。 HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层（在HTTP与 TCP 之间）。

⑼ https交互过程

在这里整理一下最近这两天整理的https的相关知识。

大家都知道要使用https，需要在网站的服务器上配置https证书（一般是nginx，或者tomcat），证书可以使用自己生成，也可以向专门的https证书提供商进行购买。这两种的区别是自己生成的证书是不被浏览器信任的,所以当访问的时候回提示不安全的网站，需要点击信任之后才能继续访问

自己生成的

而购买的https证书会提示安全

DV,OV

EV

这是因为浏览器中预置了一些https证书提供商的证书，在浏览器获取到服务器的https证书进行验证的时候就知道这个https证书是可信的；而自己生成的证书，浏览器获取到之后无法进行验证是否可信，所以就给出不安全的提示。

下面对具体的一些知识点进行介绍

1. 什么是https

https简单的说就是安全版的http，因为http协议的数据都是明文进行传输的，所以对于一些敏感信息的传输就很不安全，为了安全传输敏感数据，网景公司设计了SSL（Secure Socket Layer），在http的基础上添加了一个安全传输层，对所有的数据都加密后再进行传输，客户端和服务器端收到加密数据后按照之前约定好的秘钥解密。

2. 加密和解密

Https的发展和密码学的发展是分不开的。大家应该知道加密方式可以大体分为对称加密和非对称加密（反正我就知道这两种）

对称加密，就是加密和解密都是用同一个秘钥，这种方式优点就是速度快，缺点就是在管理和分配秘钥的时候不安全。

非对称加密算法，非对称加密有一个秘钥对，叫做公钥和私钥，私钥自己持有，公钥可以公开的发送给使用的人。使用公钥进行加密的信息，只有和其配对的私钥可以解开。目前常见的非对称加密算法是RSA，非对称的加密算法的优点是安全，因为他不需要把私钥暴露出去。

在正式的使用场景中一般都是对称加密和非对称加密结合使用，使用非对称加密完成秘钥的传递，然后使用对称秘钥进行数据加密和解密

3. https证书的申请流程

1 在服务器上生成CSR文件（证书申请文件，内容包括证书公钥、使用的Hash算法、申请的域名、公司名称、职位等信息）

可以使用命令在服务器上生成；也可以使用线上的工具进行生成，线上的工具会把公钥加入到CSR文件中，并同时生成私钥。

CSR文件内容

2 把CSR文件和其他可能的证件上传到CA认证机构，CA机构收到证书申请之后，使用申请中的Hash算法，对部分内容进行摘要，然后使用CA机构自己的私钥对这段摘要信息进行签名，

CA机构进行签名

3 然后CA机构把签名过的证书通过邮件形式发送到申请者手中。

4 申请者收到证书之后部署到自己的web服务器中。下面会在写一篇关于部署的文章

当然这是不通过CA代理机构进行申请的流程，现在网上有好多CA的代理机构，像腾讯云，阿里云都可以申请https证书，流程都差不多。

阿里云申请证书流程

4. 客户端（浏览器）和服务器端交互流程

客户端服务端交互

client Hello,客户端（通常是浏览器）先向服务器发出加密通信的请求

（1） 支持的协议版本，比如TLS 1.0版。

（2） 一个客户端生成的随机数 random1，稍后用于生成"对话密钥"。

（3） 支持的加密方法，比如RSA公钥加密。

（4） 支持的压缩方法。

服务器收到请求,然后响应 (server Hello)

（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

（2） 一个服务器生成的随机数random2，稍后用于生成"对话密钥"。

（3） 确认使用的加密方法，比如RSA公钥加密。

（4） 服务器证书。

证书内容

证书内容

客户端收到证书之后会首先会进行验证

验证流程

我们知道CA机构在签发证书的时候，都会使用自己的私钥对证书进行签名

证书里的签名算法字段 sha256RSA 表示，CA机构使用sha256对证书进行摘要，然后使用RSA算法对摘要进行私钥签名，而我们也知道RSA算法中，使用私钥签名之后，只有公钥才能进行验签。

如果我们使用的是购买的证书，那么很有可能，颁发这个证书的CA机构的公钥已经预置在操作系统中。这样浏览器就可以使用CA机构的公钥对服务器的证书进行验签。确定这个证书是不是由正规的CA机构颁发的。验签之后得到CA机构使用sha256得到的证书摘要，然后客户端再使用sha256对证书内容进行一次摘要，如果得到的值和验签之后得到的摘要值相同，则表示证书没有被修改过。

如果验证通过，就会显示上面的安全字样，如果服务器购买的证书是更高级的EV类型，就会显示出购买证书的时候提供的企业名称。如果没有验证通过，就会显示不安全的提示。

生成随机数

验证通过之后，客户端会生成一个随机数pre-master secret，然后使用证书中的公钥进行加密，然后传递给服务器端

PreMaster secret

PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。在客户端使用服务端的公钥对PreMaster Secret进行加密之后传送给服务端，服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。

PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

pre-master secret

服务器收到使用公钥加密的内容，在服务器端使用私钥解密之后获得随机数pre-master secret，然后根据radom1、radom2、pre-master secret通过一定的算法得出session Key和MAC算法秘钥，作为后面交互过程中使用对称秘钥。同时客户端也会使用radom1、radom2、pre-master secret，和同样的算法生成session Key和MAC算法的秘钥。

生成session Key的过程中会用到PRF(Pseudorandom Function伪随机方法)来生成一个key_block,然后再使用key_block,生成后面使用的秘钥。

key_block = PRF(SecurityParameters.master_secret,"key expansion",SecurityParameters.server_random +SecurityParameters.client_random);

PRF是在规范中约定的伪随机函数

在信息交互过程中用到的秘钥有6个分别是。客户端和服务器端分别使用相同的算法生成。

秘钥名称秘钥作用

client_write_MAC_key[SecurityParameters.mac_key_length]客户端发送数据使用的摘要MAC算法

server_write_MAC_key[SecurityParameters.mac_key_length]服务端发送数据使用摘要MAC算法

client_write_key[SecurityParameters.enc_key_length]客户端数据加密，服务端解密

server_write_key[SecurityParameters.enc_key_length]服务端加密，客户端解密

client_write_IV[SecurityParameters.fixed_iv_length]初始化向量，运用于分组对称加密

server_write_IV[SecurityParameters.fixed_iv_length]初始化向量，运用于分组对称加密

然后再后续的交互中就使用session Key和MAC算法的秘钥对传输的内容进行加密和解密。

具体的步骤是先使用MAC秘钥对内容进行摘要，然后把摘要放在内容的后面使用sessionKey再进行加密。对于客户端发送的数据，服务器端收到之后，需要先使用client_write_key进行解密，然后使用client_write_MAC_key对数据完整性进行验证。服务器端发送的数据，客户端会使用server_write_key和server_write_MAC_key进行相同的操作。

链接：https://www.jianshu.com/p/b0b6b88fe9fe

⑽ 如何查看本机能够支持的https加密算法套件

WIN 2008 R2 IIS 7 以上版本
CentOS 6+ OpenSSL 1.0.1c+
Apache 2.4 +
Nginx 1.0.6+
JDK1.7
tomcat7.0.56+
(以上版本都可以）