tls加密后数据包变大

A. 什么是SSL加密，什么是TLS加密

SSL加密的英文全称是Secure Socket Layer，翻译过来就是安全套接层。

它是在传输通信协议（TCP/IP）上实现的一种网络安全协议，广泛支持各种类型的网络，并同时提供三种网络基本安全服务，而且这三种服务都是使用公开密钥技术。

TLS加密的英文全称是Transport Layer Security，翻译过来就是安全传输层协议。

TLS是用于在两个通信应用程序之间，为通信提供保密性和数据完整性。这个协议一共有两层，分别是记录协议和握手协议。通过这个协议可以对网站、网络传真、电子邮件等数据传输进行加密、保密。

(1)tls加密后数据包变大扩展阅读：

1、SSL

SSL协议优势

SSL协议的优势在于它是与应用层协议独立无关的。

高层的应用层协议（例如：HTTP、FTP、Telnet等等）能透明的建立于SSL协议之上。SSL协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的私密性。

SSL体系结构

SSL被设计成使用TCP来提供一种可靠的端到端的安全服务，不是单个协议，而是二层协议。

低层是SSL记录层，用于封装不同的上层协议，另一层是被封装的协议，即SSL握手协议，它可以让服务器和客户机在传输应用数据之前，协商加密算法和加密密钥，客户机提出自己能够支持的全部加密算法，服务器选择最适合它的算法。

2、TLS

优势

TLS协议的优势是与高层的应用层协议（如HTTP、FTP、Telnet等）无耦合。

应用层协议能透明地运行在TLS协议之上，由TLS协议进行创建加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。

TLS协议是可选的，必须配置客户端和服务器才能使用。

主要有两种方式实现这一目标：一个是使用统一的TLS协议通信端口（例如：用于HTTPS的端口443）；另一个是客户端请求服务器连接到TLS时使用特定的协议机制（例如：邮件、新闻协议和STARTTLS）。

算法

在客户端和服务器开始交换TLS所保护的加密信息之前，他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。

参考资料来源：网络-SSL安全套接层

参考资料来源：网络-TLS安全传输层

B. TLS协议的TLS握手协议

TLS 为传输层安全性协议，是 MySQL 在客户端与服务器之间进行加密连接的协议。TLS 有时被称为 SSL（安全套接层），但是 MySQL 实际上并不使用 SSL 协议进行加密连接，因为它的加密很弱。TLS 协议通过加密数据来确保在两个通信应用程序之间提供隐私和数据完整性，以便任何第三方都无法拦截通信。它还会验证对等方以验证其身份。通过在两个对等点之间提供安全的通信通道，TLS 协议可以保护消息的完整性并确保其不会被篡改。MySQL 支持多种 TLS 版本协议，此次测试使用 8.0 的 client 为 TLSv1.2。

从 wireshark 中看一下 TLS 握手的步骤：

C. tls是否具有防重放攻击机制，如何解决经过tls传输的数据的有效性检测

tls具有防重放攻击机制。

1. 加密，时间戳，每个包要有包序号，每次同向加1，收到重复序号认为是攻击，可以抵御重放攻击。此外借助于HTTPS/TLS其自身机制，保证了消息完整性，并且可以抵御重放攻击。由于加密，对方也无法看到明文内容。

2. 客户端生成一串随机数R1，发给服务器，服务器判断此R1是否重复，之后根据算法(R1+R2)生成密钥。最好是结合验签机制。

3. https 会被中间人攻击，Fiddler 能用替换证书的方式截获并还原明文。非对称加密（例如RSA）是个好办法，不过得防止别人。

D. SSL/TLS协议解析

本文借助wireshark抓包详细的讲解SSL/TLS协议。HTTPS是为了解决http报文明文传输过程中的安全问题。HTTPS是“HTTP over SSL”的缩写。所以要了解HTTPS就必须先了解SSL/TLS协议。

HTTP协议中所有消息都是明文传播，存在如下三大风险

为了解决这个三个风险，分别对应如下三个解决方案。

由于SSL的2个版本都已经退出历史舞台了，所以本文后面只用TLS这个名字。 一般所说的SSL就是TLS。

TLS建立连接的过程如下图，先有个大概的印象，后面我们再详细分析。整个需要四次握手。

SSL/TLS工作在应用层和传输层之间 ，在建立连接的之前需要先建立TCP连接（三次握手），如下图。

记录协议根据rfc描述 记录协议（Record Layer） 有如下4种类型，即上图中Content Type可以取的值。

记录协议（Record Layer） 数据结构

握手协议（Handshake Protocal） 有如下10种类型。

握手协议（Handshake Protocal） 数据结构

wireshark抓包显示客户端支持的加密套件有31种。 cipher的格式为：认证算法 密钥交换算法 加密算法_ 摘要算法 。server会从这些算法组合中选取一组，作为本次SSL连接中使用。

这个包告诉我们服务器和客户端是通过Diffie-Hellman算法来生成最终的密钥（也就是Sessionkey会话密钥），pubkey是Diffie-Hellman算法中的一个参数，这个参数需要通过网络传给客户端，即使它被截取也不会影响安全性。具体见参考文献三。
在client hello和server hello包中都有Random字段，上面我们是没有说明的，client和server这两个随机数加Diffie-Hellman算法生成出来的这个key。一共三个数字生成最终对称加密的key

从现在开始发送的数据就是采用上述步骤协商出的对称加密密钥加密过的数据了

再回过头来看一下这张图，加密过程总结如下：

E. TLS 详解

SSL (Secure Sockets Layer) 安全套接层，是一种安全协议，经历了 SSL 1.0、2.0、3.0 版本后发展成了标准安全协议 - TLS (Transport Layer Security) 传输层安全性协议。TLS 有 1.0 (RFC 2246)、1.1(RFC 4346)、1.2(RFC 5246)、1.3(RFC 8446) 版本。

TLS 在实现上分为 记录层 和 握手层 两层，其中握手层又含四个子协议: 握手协议 (handshake protocol)、更改加密规范协议 (change cipher spec protocol)、应用数据协议 (application data protocol) 和警告协议 (alert protocol)

只需配置浏览器和服务器相关设置开启 TLS，即可实现 HTTPS，TLS 高度解耦，可装可卸，与上层高级应用层协议相互协作又相互独立。

TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

TLS 的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。

例如，在 HTTPS 协议中，客户端发出请求，服务端会将公钥发给客户端，客户端验证过后生成一个密钥再用公钥加密后发送给服务端（非对称加密），双方会在 TLS 握手过程中生成一个协商密钥（对称密钥），成功后建立加密连接。通信过程中客户端将请求数据用协商密钥加密后发送，服务端也用协商密钥解密，响应也用相同的协商密钥。后续的通信使用对称加密是因为对称加解密快，而握手过程中非对称加密可以保证加密的有效性，但是过程复杂，计算量相对来说也大。

记录协议负责在传输连接上交换的所有底层消息，并且可以配置加密。每一条 TLS 记录以一个短标头开始。标头包含记录内容的类型 (或子协议)、协议版本和长度。原始消息经过分段 (或者合并)、压缩、添加认证码、加密转为 TLS 记录的数据部分。

记录层将信息块分割成携带 2^14 字节 (16KB) 或更小块的数据的 TLSPlaintext 记录。

记录协议传输由其他协议层提交给它的不透明数据缓冲区。如果缓冲区超过记录的长度限制（2^14），记录协议会将其切分成更小的片段。反过来也是可能的，属于同一个子协议的小缓冲区也可以组合成一个单独的记录。

压缩算法将 TLSPlaintext 结构转换为 TLSCompressed 结构。如果定义 CompressionMethod 为 null 表示不压缩

流加密（BulkCipherAlgorithm）将 TLSCompressed.fragment 结构转换为流 TLSCiphertext.fragment 结构

MAC 产生方法如下：

seq_num（记录的序列号）、hash（SecurityParameters.mac_algorithm 指定的哈希算法）

块加密（如 RC2 或 DES），将 TLSCompressed.fragment 结构转换为块 TLSCiphertext.fragment 结构

padding: 添加的填充将明文长度强制为块密码块长度的整数倍。填充可以是长达 255 字节的任何长度，只要满足 TLSCiphertext.length 是块长度的整数倍。长度大于需要的值可以阻止基于分析交换信息长度的协议攻击。填充数据向量中的每个 uint8 必须填入填充长度值 (即 padding_length)。

padding_length: 填充长度应该使得 GenericBlockCipher 结构的总大小是加密块长度的倍数。合法值范围从零到 255（含）。 该长度指定 padding_length 字段本身除外的填充字段的长度

加密块的数据长度（TLSCiphertext.length）是 TLSCompressed.length，CipherSpec.hash_size 和 padding_length 的总和加一

加密和 MAC 功能将 TLSCompressed 结构转换为 TLSCiphertext。记录的 MAC 还包括序列号，以便可以检测到丢失，额外或重复的消息。

记录协议需要一种算法，从握手协议提供的安全性参数生成密钥、 IV 和 MAC secret.

主密钥 (Master secret): 在连接中双方共享的一个 48 字节的密钥
客户随机数 (client random): 由客户端提供的 32 字节值
服务器随机数 (server random): 由服务器提供的 32 字节值

握手是 TLS 协议中最精密复杂的部分。在这个过程中，通信双方协商连接参数，并且完成身 份验证。根据使用的功能的不同，整个过程通常需要交换 6~10 条消息。根据配置和支持的协议扩展的不同，交换过程可能有许多变种。在使用中经常可以观察到以下三种流程：(1) 完整的握手， 对服务器进行身份验证；(2) 恢复之前的会话采用的简短握手；(3) 对客户端和服务器都进行身份验证的握手。

握手协议消息的标头信息包含消息类型（1 字节）和长度（3 字节），余下的信息则取决于消息类型：

每一个 TLS 连接都会以握手开始。如果客户端此前并未与服务器建立会话，那么双方会执行一次完整的握手流程来协商 TLS 会话。握手过程中，客户端和服务器将进行以下四个主要步骤:

下面介绍最常见的握手规则，一种不需要验证客户端身份但需要验证服务器身份的握手:

这条消息将客户端的功能和首选项传送给服务器。

是将服务器选择的连接参数传回客户端。

这个消息的结构与 ClientHello 类似，只是每个字段只包含一个选项，其中包含服务端的 random_S 参数 (用于后续的密钥协商)。服务器无需支持客户端支持的最佳版本。如果服务器不支持与客户端相同的版本，可以提供某个其他版本以期待客户端能够接受

图中的 Cipher Suite 是后续密钥协商和身份验证要用的加密套件，此处选择的密钥交换与签名算法是 ECDHE_RSA，对称加密算法是 AES-GCM，后面会讲到这个

还有一点默认情况下 TLS 压缩都是关闭的，因为 CRIME 攻击会利用 TLS 压缩恢复加密认证 cookie，实现会话劫持，而且一般配置 gzip 等内容压缩后再压缩 TLS 分片效益不大又额外占用资源，所以一般都关闭 TLS 压缩

典型的 Certificate 消息用于携带服务器 X.509 证书链 。
服务器必须保证它发送的证书与选择的算法套件一致。比方说，公钥算法与套件中使用的必须匹配。除此以外，一些密钥交换算法依赖嵌入证书的特定数据，而且要求证书必须以客户端支持的算法签名。所有这些都表明服务器需要配置多个证书（每个证书可能会配备不同的证书链）。

Certificate 消息是可选的，因为并非所有套件都使用身份验证，也并非所有身份验证方法都需要证书。更进一步说，虽然消息默认使用 X.509 证书，但是也可以携带其他形式的标志；一些套件就依赖 PGP 密钥

携带密钥交换需要的额外数据。ServerKeyExchange 是可选的，消息内容对于不同的协商算法套件会存在差异。部分场景下，比如使用 RSA 算法时，服务器不需要发送此消息。

ServerKeyExchange 仅在服务器证书消息（也就是上述 Certificate 消息）不包含足够的数据以允许客户端交换预主密钥（premaster secret）时才由服务器发送。

比如基于 DH 算法的握手过程中，需要单独发送一条 ServerKeyExchange 消息带上 DH 参数:

表明服务器已经将所有预计的握手消息发送完毕。在此之后，服务器会等待客户端发送消息。

客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证内容包括如下:

由 PKI 体系 的内容可知，对端发来的证书签名是 CA 私钥加密的，接收到证书后，先读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性；然后去查询证书的吊销情况等

合法性验证通过之后，客户端计算产生随机数字的预主密钥（Pre-master），并用证书公钥加密，发送给服务器并携带客户端为密钥交换提供的所有信息。这个消息受协商的密码套件的影响，内容随着不同的协商密码套件而不同。

此时客户端已经获取全部的计算协商密钥需要的信息: 两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，然后得到协商密钥(用于之后的消息加密)

图中使用的是 ECDHE 算法，ClientKeyExchange 传递的是 DH 算法的客户端参数，如果使用的是 RSA 算法则此处应该传递加密的预主密钥

通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信

Finished 消息意味着握手已经完成。消息内容将加密，以便双方可以安全地交换验证整个握手完整性所需的数据。

这个消息包含 verify_data 字段，它的值是握手过程中所有消息的散列值。这些消息在连接两端都按照各自所见的顺序排列，并以协商得到的主密钥 (enc_key) 计算散列。这个过程是通过一个伪随机函数（pseudorandom function，PRF）来完成的，这个函数可以生成任意数量的伪随机数据。
两端的计算方法一致，但会使用不同的标签（finished_label）：客户端使用 client finished，而服务器则使用 server finished。

因为 Finished 消息是加密的，并且它们的完整性由协商 MAC 算法保证，所以主动网络攻击者不能改变握手消息并对 vertify_data 的值造假。在 TLS 1.2 版本中，Finished 消息的长度默认是 12 字节（96 位），并且允许密码套件使用更长的长度。在此之前的版本，除了 SSL 3 使用 36 字节的定长消息，其他版本都使用 12 字节的定长消息。

服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，同样计算得到协商密钥: enc_key = PRF(Pre_master, "master secret", random_C + random_S) ;

同样计算之前所有收发信息的 hash 值，然后用协商密钥解密客户端发送的 verify_data_C，验证消息正确性;

服务端验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信（图中多了一步 New Session Ticket，此为会话票证，会在会话恢复中解释）;

服务器也结合所有当前的通信参数信息生成一段数据 (verify_data_S) 并采用协商密钥 session secret (enc_key) 与算法加密并发送到客户端;

客户端计算所有接收信息的 hash 值，并采用协商密钥解密 verify_data_S，验证服务器发送的数据和密钥，验证通过则握手完成;

开始使用协商密钥与算法进行加密通信。

HTTPS 通过 TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能。加密过程中，需要用到非对称密钥交换和对称内容加密两大算法。

对称内容加密强度非常高，加解密速度也很快，只是无法安全地生成和保管密钥。在 TLS 协议中，最后的应用数据都是经过对称加密后传输的，传输中所使用的对称协商密钥(上文中的 enc_key)，则是在握手阶段通过非对称密钥交换而来。常见的 AES-GCM、ChaCha20-Poly1305，都是对称加密算法。

非对称密钥交换能在不安全的数据通道中，产生只有通信双方才知道的对称加密密钥。目前最常用的密钥交换算法有 RSA 和 ECDHE。

RSA 历史悠久，支持度好，但不支持 完美前向安全 - PFS(Perfect Forward Secrecy) ；而 ECDHE 是使用了 ECC（椭圆曲线）的 DH（Diffie-Hellman）算法，计算速度快，且支持 PFS。

在 PKI 体系 一节中说明了仅有非对称密钥交换还是无法抵御 MITM 攻击的，所以需要引入了 PKI 体系的证书来进行身份验证，其中服务端非对称加密产生的公钥会放在证书中传给客户端。

在 RSA 密钥交换中，浏览器使用证书提供的 RSA 公钥加密相关信息，如果服务端能解密，意味着服务端拥有与公钥对应的私钥，同时也能算出对称加密所需密钥。密钥交换和服务端认证合并在一起。

在 ECDH 密钥交换中，服务端使用私钥 (RSA 或 ECDSA) 对相关信息进行签名，如果浏览器能用证书公钥验证签名，就说明服务端确实拥有对应私钥，从而完成了服务端认证。密钥交换则是各自发送 DH 参数完成的，密钥交换和服务端认证是完全分开的。

可用于 ECDHE 数字签名的算法主要有 RSA 和 ECDSA - 椭圆曲线数字签名算法 ，也就是目前密钥交换 + 签名有三种主流选择:

比如我的网站使用的加密套件是 ECDHE_RSA，可以看到数字签名算法是 sha256 哈希加 RSA 加密，在 PKI 体系 一节中讲了签名是服务器信息摘要的哈希值加密生成的

内置 ECDSA 公钥的证书一般被称之为 ECC 证书，内置 RSA 公钥的证书就是 RSA 证书。因为 256 位 ECC Key 在安全性上等同于 3072 位 RSA Key，所以 ECC 证书体积比 RSA 证书小，而且 ECC 运算速度更快，ECDHE 密钥交换 + ECDSA 数字签名是目前最好的加密套件

以上内容来自本文: 开始使用 ECC 证书

关于 ECC 证书的更多细节可见文档: ECC Cipher Suites for TLS - RFC4492

使用 RSA 进行密钥交换的握手过程与前面说明的基本一致，只是没有 ServerKeyExchange 消息，其中协商密钥涉及到三个参数 (客户端随机数 random_C、服务端随机数 random_S、预主密钥 Premaster secret)，
其中前两个随机数和协商使用的算法是明文的很容易获取，最后一个 Premaster secret 会用服务器提供的公钥加密后传输给服务器 (密钥交换)，如果这个预主密钥被截取并破解则协商密钥也可以被破解。

RSA 算法的细节见: wiki 和 RSA算法原理（二）- 阮一峰

RSA 的算法核心思想是利用了极大整数 因数分解 的计算复杂性

而使用 DH(Diffie-Hellman) 算法 进行密钥交换，双方只要交换各自的 DH 参数(在 ServerKeyExchange 发送 Server params，在 ClientKeyExchange 发送 Client params)，不需要传递 Premaster secret，就可以各自算出这个预主密钥

DH 的握手过程如下，大致过程与 RSA 类似，图中只表达如何生成预主密钥:

服务器通过私钥将客户端随机数 random_C，服务端随机数 random_S，服务端 DH 参数 Server params 签名生成 signature，然后在 ServerKeyExchange 消息中发送服务端 DH 参数和该签名；

客户端收到后用服务器给的公钥解密验证签名，并在 ClientKeyExchange 消息中发送客户端 DH 参数 Client params；

服务端收到后，双方都有这两个参数，再各自使用这两个参数生成预主密钥 Premaster secret，之后的协商密钥等步骤与 RSA 基本一致。

关于 DH 算法如何生成预主密钥，推荐看下 Wiki 和 Ephemeral Diffie-Hellman handshake

其核心思想是利用了 离散对数问题 的计算复杂性

算法过程可以抽象成下图:

双方预先商定好了一对 P g 值 (公开的)，而 Alice 有一个私密数 a(非公开，对应一个私钥)，Bob 有一个私密数 b(非公开，对应一个私钥)

对于 Alice 和 Bob 来说通过对方发过来的公钥参数和自己手中的私钥可以得到最终相同的密钥

而第三方最多知道 P g A B，想得到私钥和最后的密钥很困难，当然前提是 a b P 足够大 (RFC3526 文档中有几个常用的大素数可供使用)，否则暴力破解也有可能试出答案，至于 g 一般取个较小值就可以

如下几张图是实际 DH 握手发送的内容:

可以看到双方发给对方的参数中携带了一个公钥值，对应上述的 A 和 B

而且实际用的加密套件是 椭圆曲线 DH 密钥交换 (ECDH) ，利用由椭圆曲线加密建立公钥与私钥对可以更进一步加强 DH 的安全性，因为目前解决椭圆曲线离散对数问题要比因式分解困难的多，而且 ECC 使用的密钥长度比 RSA 密钥短得多(目前 RSA 密钥需要 2048 位以上才能保证安全，而 ECC 密钥 256 位就足够)

关于 椭圆曲线密码学 - ECC ，推荐看下 A Primer on Elliptic Curve Cryptography - 原文 - 译文

尽管可以选择对任意一端进行身份验证，但人们几乎都启用了对服务器的身份验证。如果服务器选择的套件不是匿名的，那么就需要在 Certificate 消息中跟上自己的证书。

相比之下，服务器通过发送 CertificateRequest 消息请求对客户端进行身份验证。消息中列出所有可接受的客户端证书。作为响应，客户端发送自己的 Certificate 消息（使用与服务器发送证书相同的格式），并附上证书。此后，客户端发送 CertificateVerify 消息，证明自己拥有对应的私钥。

只有已经过身份验证的服务器才被允许请求客户端身份验证。基于这个原因，这个选项也被称为相互身份验证（mutual authentication）。

在 ServerHello 的过程中发出，请求对客户端进行身份验证，并将其接受的证书的公钥和签名算法传送给客户端。

它也可以选择发送一份自己接受的证书颁发机构列表，这些机构都用其可分辨名称来表示:

在 ClientKeyExchange 的过程中发出，证明自己拥有的私钥与之前发送的客户端证书中的公钥匹配。消息中包含一条到这一步为止的所有握手消息的签名：

最初的会话恢复机制是，在一次完整协商的连接断开时，客户端和服务器都会将会话的安全参数保存一段时间。希望使用会话恢复的服务器为会话指定唯一的标识，称为会话 ID(Session ID)。服务器在 ServerHello 消息中将会话 ID 发回客户端。

希望恢复早先会话的客户端将适当的 Session ID 放入 ClientHello 消息，然后提交。服务器如果同意恢复会话，就将相同的 Session ID 放入 ServerHello 消息返回，接着使用之前协商的主密钥生成一套新的密钥，再切换到加密模式，发送 Finished 消息。
客户端收到会话已恢复的消息以后，也进行相同的操作。这样的结果是握手只需要一次网络往返。

Session ID 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话 ID 以及协商的通信信息，占用服务器资源较多。

用来替代服务器会话缓存和恢复的方案是使用会话票证（Session ticket）。使用这种方式，除了所有的状态都保存在客户端（与 HTTP Cookie 的原理类似）之外，其消息流与服务器会话缓存是一样的。

其思想是服务器取出它的所有会话数据（状态）并进行加密 (密钥只有服务器知道)，再以票证的方式发回客户端。在接下来的连接中，客户端恢复会话时在 ClientHello 的扩展字段 session_ticket 中携带加密信息将票证提交回服务器，由服务器检查票证的完整性，解密其内容，再使用其中的信息恢复会话。

这种方法有可能使扩展服务器集群更为简单，因为如果不使用这种方式，就需要在服务集群的各个节点之间同步会话。
Session ticket 需要服务器和客户端都支持，属于一个扩展字段，占用服务器资源很少。

F. HTTPS 到底加密了些什么内容

https其实是有两部分组成：http + SSL / TLS，也就是在http上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。

1. 客户端发起https请求

客户端发起https请求就是指用户在浏览器里输入一个https网址，然后连接到server的443端口。

2. 服务器端的配置

采用https协议的服务器必须要有一套SSL数字证书，需要向CA组织(如WoSign沃通CA)申请。这套SSL证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，证书过期时间等等。

4. 客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息

这部分传送的是用SSL证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务段解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

8. 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

G. 深入TLS/SSL协议

TLS/SSL 协议是为了解决网络通讯中的信息安全问题而诞生的。

它的设计目的主要有三个：

TLS/SSL 协议主要包含两部分：

对称加密算法是指在加密和解密过程中使用相同的密钥。

举例：
张三在与李四通讯时为了防止第三方窃听，使用莫斯密码将通讯内容加密。李四接收到通讯内容后，使用相同的莫斯密码将内容解密。

因为使用了相同的莫斯密码，所以这属于对称加密。

网络通讯中的对称加密之所以能够使用相同的密钥对内容进行加/解密，是因为使用了异或运算。

在数学领域中异或运算：当两两数值相同为否，而数值不同时为真。

举例：
现有一把密钥：1010，与明文：0110。

可见 XOR 异或运算是对称加密的关键！

优点：

缺点：

异或运算要求双方长度一致的这个缺点要怎么解决呢？聪明的同学或许已经想到解决方法了：就是将明文划分为多个等长的块。

比如密钥为16字节的，那就将明文划分为多个16字节的块，分别用密钥对这些明文块进行加解密。

Block cipher 分组加密原理就是这样：将明文划分为多个等长的 Block 块，对每一个 Block 块分别加解密。

但并不是所有的明文都能恰好的划分为16字节的块。这时就需要填充！

填充的目的：

填充主要有两种方法：

其中字节填充有4种填充方式：

对明文进行分组、填充后，还要按照一定的规律或方法进行加/解密。这些规律或者方法就是工作模式。

分组工作模式： block cipher mode of operation

1、 电子密码本 ECB 模式-- Electronic codebook
就是直接将明文分解为多个块，对每个块进行加密。

这种工作方法非常简单、快速。但是缺点在于同样的明文块会被加密成相同的密文块；因此，它不能很好的隐藏数据模式。

举例：
对图片进行 ECB 之后，是无法隐藏到图像的轮廓特性的。如下图所示：

CTR 模式同样存在问题：无法提供密文的完整性校验。当密文在传输过程中存在丢失的情况下，是无法保证密文的完整性的。

MAC 算法-- Message Authentication Code 。
MAC 算法能够实现消息的完整性校验。工作原理是基于hash函数的。

hash 函数是一种从任何一种数据中创建小的数字“指纹”的方法。 hash 函数把消息或数据压缩成摘要，使得数据量变小，将数据的格式固定下来。
简而言之就是：无论输入多长的字符串，通过 hash 函数，都能得到定长较短的字符串。

MAC 工作流程如图所示：

CTR 分组工作模式加上 MAC 算法就诞生了 GCM 分组工作模式。

高级加密标准 AES 算法-- Advanced Encryption Standard

AES 的分组 Block 块长度固定为128比特，也就是16字节。
密钥长度则可以是128，192或256比特。

所以从上图中看出，分组长度128比特分为4个32比特。而不同长度的密钥则分为4、6. 8组32位比特的矩阵。

AES 加密流程：如图所示

10轮加密可分为初始轮、普通轮和最终轮。

addRoundKey 轮密钥加

SubBytes 字节替代

ShiftRows 行移位

对称加密的最大的问题是怎么把密钥传递给对方。非对称密码可以实现密钥的安全传递。

每一个参与方都有一对密钥：

非对称加解密过程：

举例：
张三要和李四通讯
第一步：张三用李四的公钥进行加密，将密文发送给李四。
第二步：李四用自己的私钥进行解密。

密文是无法通过公钥解密的，只有私钥才能解密。

张三怎么拿到李四的公钥？有两种办法：

RSA 是基于公开密钥密码体制的。

公开密钥密码体制是一种“由已知加密密钥推导出解密密钥在计算上是不可行的”密码体制。

RSA 算法中公私钥的产生：

RSA 的安全性依赖于大数因数分解非常非常困难，也就是通过一个大数 n 是非常难的分解出 p 和 q 。

RSA 算法的加解密流程：如下图所示

由于进行大量的大数乘法运算，RSA的速度是对应同样安全级别的对称密码算法的1/1000左右。

PKI 是非对称密码学的一个非常重要的应用。

基于私钥加密，只能使用公钥解密的原理实现身份验证的作用。

签名与验签的流程

签名：

验签：

证书类型：

从加密安全性上看，三类证书的保密性都是一样的，只有在站长的个人信息验证上有所不同。

上面说到张三有两种办法可以拿到李四的公钥：

RSA 算法一般是第一种方法中用于 CA 机构的身份验证上的。事实上 RSA 算法用于第二种方法也是可行的。

举例：
张三与李四建立链接。李四用RSA算法生成一对公私钥，在握手中李四将公钥传递给张三。然后张三将对称加密的密钥用公钥进行加密后传递给李四，李四用私钥解密得到密钥。

就算第三方拿到公钥，没有私钥是无法解密密文的。

但这种方式有一个缺点：没有前向保密性。
也就是说当第三方将通讯的报文全部保存下来后，在破解出私钥之后，就能知道所有密文内容。

而 DH 密钥交换协议就解决了这个问题。它可以双方在完全没有对方任何预先信息的条件下通过不安全信道创建起一个密钥。所以每一次通讯中密钥都是实时生成的

具体流程：

DH密钥交互协议的原理：

DH 交换协议的问题：容易遭到中间人伪造攻击。

简单来说：第三方假装自己是张三向李四进行一次 DH 密钥交换，然后又假装李四向张三进行一个 DH 密钥交换。就可以知道密钥 K 。

解决这个方法很简单，就是使用 PKI 公钥基础体系中的身份验证。第三方就无法假装李四这个站长了。

从图中看出 DH 协议也涉及到大量的大数乘法运算，速度也是非常慢的。而目前使用的 DH 密钥交换协议是基于 ECC 椭圆曲线加持过的，速度非常的快。称为 ECDHE 密钥交换算法。具体细节可以自己去搜索查询。

TLS1.2 中经常使用的一个安全套件是：
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

具体说明一下：

分组密码工作模式 --wiki
高级加密标准 --wiki
RSA算法 --wiki
DH密钥交换协议 --wiki
《计算机网络：自顶向下方法》
Web协议详解与抓包实战--陶辉

H. 【opensips】使用tls加密后的sip流如何通过wireshark查看

使用tls加密sip后，所有的sip都是密文，所以即使抓包，也无法查看到sip信令流。

实际上如果有tls服务器端certificate的private key的话，是可以把tls的sip流解密的。

选择 wireshark首先项，在prototols中选择TLS（有的版本是SSL）
选择 RSA keys list 弹出第二页配置窗

配置tls 的private key

整个pcap包里有两个IP，一个是server ip（这里是private IP），一个是client IP。

I. HTTP，SSL/TLS和HTTPS协议的区别与联系

概述：HTTP是普通明文传输协议，HTTPS是加密协议，相当于HTTP的安全版本，但需要HTTPS加密必须拥有SSL证书与TLS协议交流产生，SSL证书在线签发：网页链接

1、“HTTP”是什么？

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议，所有的WWW文件都必须遵守这个标准，设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法（具体可查看马海祥博客《深入解析互联网协议的原理》的相关介绍）。

1960年美国人Ted Nelson构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext），这成为了HTTP超文本传输协议标准架构的发展根基。

简单来说，HTTP就是一个网络协议，是专门用来帮你传输Web内容的，关于这个协议，就算你不了解，至少也听说过吧？比如你访问我的博客的主页，浏览器地址栏会出现的网址：http://www.mahaixiang.cn，大部分网站都是通过HTTP协议来传输Web页面、以及Web页面上包含的各种东东（图片、CSS 样式、JS 脚本）。

2、“SSL/TLS”是什么？

SSL是“Secure Sockets Layer”的缩写，中文叫做“安全套接层”，它是在上世纪90年代中期，由网景公司设计的（顺便插一句，网景公司不光发明了 SSL，还发明了很多 Web 的基础设施——比如“CSS 样式表”和“JS 脚本”）。

为啥要发明SSL这个协议捏？因为原先互联网上使用的HTTP协议是明文的，存在很多缺点——比如传输内容会被偷窥（嗅探）和篡改，发明SSL协议，就是为了解决这些问题。

到了1999年，SSL因为应用广泛，已经成为互联网上的事实标准，IETF就在那年把SSL标准化，标准化之后的名称改为TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。

很多相关的文章都把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。

3、“HTTPS”是什么意思？

解释完 HTTP 和 SSL/TLS，现在就可以来解释 HTTPS 啦，咱们通常所说的 HTTPS 协议，说白了就是“HTTP 协议”和“SSL/TLS 协议”的组合，你可以把 HTTPS 大致理解为——“HTTP over SSL”或“HTTP over TLS”（反正 SSL 和 TLS 差不多）。

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

它是一个URI scheme（抽象标识符体系），句法类同http:体系，用于安全的HTTP数据传输。

https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间），这个系统的最初研发由网景公司(Netscape)进行，并内置于其浏览器Netscape Navigator中，提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。

4、谈谈“对称加密”和“非对称加密”的概念

如果我们想搞明白“对称加密”和“非对称加密”的概念，首先，我们就要先知道什么是“加密”和“解密”？

（1）、什么是“加密”和“解密”？

通俗而言，你可以把“加密”和“解密”理解为某种互逆的数学运算，就好比“加法和减法”互为逆运算、“乘法和除法”互为逆运算。

“加密”的过程，就是把“明文”变成“密文”的过程；反之，“解密”的过程，就是把“密文”变为“明文”，在这两个过程中，都需要一个关键的东东——叫做“密钥”——来参与数学运算。

（2）、什么是“对称加密”？

所谓的“对称加密技术”，意思就是说：“加密”和“解密”使用相同的密钥。这个比较好理解，就好比你用 7zip 或 WinRAR 创建一个带密码（口令）的加密压缩包，当你下次要把这个压缩文件解开的时候，你需要输入同样的密码，在这个例子中，密码/口令就如同刚才说的“密钥”。

对称加密是最快速、最简单的一种加密方式，加密（encryption）与解密（decryption）用的是同样的密钥（secret key），这种方法在密码学中叫做对称加密算法，对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。

（3）、什么是“非对称加密”？

所谓的“非对称加密技术”，意思就是说：“加密”和“解密”使用不同的密钥，这玩意儿比较难理解，也比较难想到，当年“非对称加密”的发明，还被誉为“密码学”历史上的一次革命。

非对称加密为数据的加密与解密提供了一个非常安全的方法，它使用了一对密钥，公钥（public key）和私钥（private key），私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人，非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。

由于篇幅有限，对“非对称加密”这个话题，我就不展开了，有空的话，我会再单独写一篇文章在马海祥博客上发布。

（4）、各自有啥优缺点？

看完刚才的定义，很显然：（从功能角度而言）“非对称加密”能干的事情比“对称加密”要多，这是“非对称加密”的优点，但是“非对称加密”的实现，通常需要涉及到“复杂数学问题”，所以，“非对称加密”的性能通常要差很多（相对于“对称加密”而言）。

这两者的优缺点，也影响到了 SSL 协议的设计。

5、HTTP协议的特点

作为背景知识介绍，还需要再稍微谈一下 HTTP 协议本身的特点，HTTP本身有很多特点，考虑到篇幅有限，马海祥只谈那些和HTTPS相关的特点，想要了解更深入的HTTP知识，可查看马海祥博客《HTTP服务的七层架构技术解析及运用》的相关介绍。

（1）、HTTP的版本和历史

如今咱们用的 HTTP 协议，版本号是 1.1（也就是 HTTP 1.1），这个 1.1 版本是1995年底开始起草的（技术文档是RFC2068），并在1999年正式发布（技术文档是RFC2616）。

在 1.1 之前，还有曾经出现过两个版本“0.9 和 1.0”，其中的 HTTP 0.9 没有被广泛使用，而 HTTP 1.0 被广泛使用过。

（2）、HTTP 和 TCP 之间的关系

简单地说，TCP 协议是 HTTP 协议的基石——HTTP 协议需要依靠 TCP 协议来传输数据。

在网络分层模型中，TCP 被称为“传输层协议”，而 HTTP 被称为“应用层协议”。

有很多常见的应用层协议是以 TCP 为基础的，比如“FTP、SMTP、POP、IMAP”等。

TCP被称为“面向连接”的传输层协议，关于它的具体细节，俺就不展开了（否则篇幅又失控了），你只需知道：传输层主要有两个协议，分别是TCP和UDP，TCP比UDP更可靠，你可以把 TCP 协议想象成某个水管，发送端这头进水，接收端那头就出水，并且 TCP 协议能够确保，先发送的数据先到达（与之相反，UDP不保证这点）。

（3）、HTTP协议如何使用 TCP 连接？

HTTP对 TCP 连接的使用，分为两种方式：俗称“短连接”和“长连接”（“长连接”又称“持久连接”，叫做“Keep-Alive”或“Persistent Connection”）

假设有一个网页，里面包含好多图片，还包含好多外部的CSS文件和JS文件，在“短连接”的模式下，浏览器会先发起一个 TCP 连接，拿到该网页的 HTML 源代码（拿到 HTML 之后，这个 TCP 连接就关闭了）。然后，浏览器开始分析这个网页的源码，知道这个页面包含很多外部资源（图片、CSS、JS）。然后针对每一个外部资源，再分别发起一个个 TCP 连接，把这些文件获取到本地（同样的，每抓取一个外部资源后，相应的 TCP 就断开）。

相反，如果是“长连接”的方式，浏览器也会先发起一个 TCP 连接去抓取页面，但是抓取页面之后，该 TCP 连接并不会立即关闭，而是暂时先保持着（所谓的“Keep-Alive”），然后浏览器分析 HTML 源码之后，发现有很多外部资源，就用刚才那个 TCP 连接去抓取此页面的外部资源。

在 HTTP 1.0 版本，默认使用的是“短连接”（那时候是 Web 诞生初期，网页相对简单，“短连接”的问题不大）。

到了1995年底开始制定 HTTP 1.1 草案的时候，网页已经开始变得复杂（网页内的图片、脚本越来越多了），这时候再用短连接的方式，效率太低下了（因为建立 TCP 连接是有“时间成本”和“CPU成本”），所以，在 HTTP 1.1 中，默认采用的是“Keep-Alive”的方式。

6、SSL/TLS协议的基本运行过程

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密，但是这里有两个问题：

（1）、如何保证公钥不被篡改？

解决方法：将公钥放在数字证书中，只要证书是可信的，公钥就是可信的。

（2）、公钥加密计算量太大，如何减少耗用的时间？

解决方法：每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。

因此，SSL/TLS协议的基本过程是这样的：

（1）、客户端向服务器端索要并验证公钥。

（2）、双方协商生成“对话密钥”。

（3）、双方采用“对话密钥”进行加密通信。

7、SSL、HTTP和HTTPS协议的联系

SSL是Netscape公司所提出的安全保密协议，在浏览器(如Internet Explorer、Netscape Navigator)和Web服务器(如Netscape的Netscape Enterprise Server、ColdFusion Server等等)之间构造安全通道来进行数据传输，SSL运行在TCP/IP层之上、应用层之下，为应用程序提供加密数据通道，它采用了RC4、MD5 以及RSA等加密算法，使用40位的密钥，适用于商业信息的加密。

同时，Netscape公司相应开发了HTTPS协议并内置于其浏览器中，HTTPS实际上就是SSL over HTTP，它使用默认端口443，而不是像HTTP那样使用端口80来和TCP/IP进行通信。HTTPS协议使用SSL在发送方把原始数据进行加密，然后在接受方进行解密，加密和解密需要发送方和接受方通过交换共知的密钥来实现，因此，所传送的数据不容易被网络黑客截获和解密。

然而，加密和解密过程需要耗费系统大量的开销，严重降低机器的性能，相关测试数据表明使用HTTPS协议传输数据的工作效率只有使用HTTP协议传输的十分之一。

假如为了安全保密，将一个网站所有的Web应用都启用SSL技术来加密，并使用HTTPS协议进行传输，那么该网站的性能和效率将会大大降低，而且没有这个必要，因为一般来说并不是所有数据都要求那么高的安全保密级别，所以，我们只需对那些涉及机密数据的交互处理使用HTTPS协议，这样就做到鱼与熊掌兼得（具体可查看马海祥博客《从SEO的角度来分析网站是否该采用HTTPS协议》的相关介绍）。

总之不需要用https的地方，就尽量不要用。

8、HTTPS协议的需求是什么？

花了好多口水，终于把背景知识说完了，下面正式进入正题，先来说说当初设计HTTPS是为了满足哪些需求？

很多介绍 HTTPS 的文章一上来就给你讲实现细节，对此，马海祥觉得这是不好的做法，一上来就给你讲协议细节，你充其量只能知道如何做，无法理解为什么，我在前一个章节讲了“背景知识”，在这个章节讲了“需求”，这就有助于你理解了。

为什么要设计成这样？——这就是 WHY 型的问题。

（1）、兼容性

因为是先有 HTTP 再有 HTTPS，所以，HTTPS 的设计者肯定要考虑到对原有 HTTP 的兼容性。

这里所说的兼容性包括很多方面，比如已有的 Web 应用要尽可能无缝地迁移到 HTTPS；比如对浏览器厂商而言，改动要尽可能小。

基于“兼容性”方面的考虑，很容易得出如下几个结论：

①、HTTPS还是要基于 TCP 来传输

如果改为 UDP 作传输层，无论是 Web 服务端还是浏览器客户端，都要大改，动静太大了。

②、单独使用一个新的协议，把 HTTP 协议包裹起来

所谓的“HTTP over SSL”，实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装，HTTP 协议原有的 GET、POST 之类的机制，基本上原封不动。

打个比方：如果原来的 HTTP 是塑料水管，容易被戳破；那么如今新设计的 HTTPS 就像是在原有的塑料水管之外，再包一层金属水管，一来，原有的塑料水管照样运行；二来，用金属加固了之后，不容易被戳破。

（2）、可扩展性

前面说了，HTTPS 相当于是“HTTP over SSL”。

如果 SSL 这个协议在“可扩展性”方面的设计足够牛逼，那么它除了能跟 HTTP 搭配，还能够跟其它的应用层协议搭配，岂不美哉？

现在看来，当初设计 SSL 的人确实比较牛，如今的 SSL/TLS 可以跟很多常用的应用层协议（比如：FTP、SMTP、POP、Telnet）搭配，来强化这些应用层协议的安全性。

接着刚才打的比方：如果把 SSL/TLS 视作一根用来加固的金属管，它不仅可以用来加固输水的管道，还可以用来加固输煤气的管道。

（3）、保密性（防泄密）

HTTPS需要做到足够好的保密性。

说到保密性，首先要能够对抗嗅探（行话叫 Sniffer），所谓的“嗅探”，通俗而言就是监视你的网络传输流量，如果你使用明文的 HTTP 上网，那么监视者通过嗅探，就知道你在访问哪些网站的哪些页面。

嗅探是最低级的攻击手法，除了嗅探，HTTPS 还需要能对抗其它一些稍微高级的攻击手法——比如“重放攻击”（后面讲协议原理的时候，会再聊）。

（4）、完整性（防篡改）

除了“保密性”，还有一个同样重要的目标是“确保完整性”。

在发明 HTTPS 之前，由于 HTTP 是明文的，不但容易被嗅探，还容易被篡改。

举个例子：比如咱们的网络运营商（ISP）都比较流氓，经常有网友抱怨说访问某网站（本来是没有广告的），竟然会跳出很多中国电信的广告，为啥会这样呢？因为你的网络流量需要经过 ISP 的线路才能到达公网，如果你使用的是明文的 HTTP，ISP 很容易就可以在你访问的页面中植入广告。

所以，当初设计 HTTPS 的时候，还有一个需求是“确保 HTTP 协议的内容不被篡改”。

（5）、真实性（防假冒）

在谈到 HTTPS 的需求时，“真实性”经常被忽略，其实“真实性”的重要程度不亚于前面的“保密性”和“完整性”。

举个例子：你因为使用网银，需要访问该网银的 Web 站点，那么，你如何确保你访问的网站确实是你想访问的网站？

有些天真的同学会说：通过看网址里面的域名，来确保，为啥说这样的同学是“天真的”？因为 DNS 系统本身是不可靠的（尤其是在设计 SSL 的那个年代，连 DNSSEC 都还没发明），由于 DNS 的不可靠（存在“域名欺骗”和“域名劫持”），你看到的网址里面的域名未必是真实滴！

所以，HTTPS 协议必须有某种机制来确保“真实性”的需求（至于如何确保，后面会细聊）。

9、HTTPS和HTTP的区别

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等。

为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS。

为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

一般来说，HTTPS和HTTP的区别主要为以下四点：

（1）、https协议需要到ca申请证书，一般免费证书很少，需要交费。

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

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

（4）、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全（具体可查看马海祥博客《HTTP与HTTPS的区别》的相关介绍）。

10、HTTPS和HTTP的性能比较

再来说最后一个需求——性能。

本来简单的http协议，一个get一个response，由于https要还密钥和确认加密算法的需要，单握手就需要6、7个往返，任何应用中，过多的round trip肯定影响性能，接下来才是具体的http协议，每一次响应或者请求，都要求客户端和服务端对会话的内容做加密/解密。

尽管对称加密/解密效率比较高，可是仍然要消耗过多的CPU，为此有专门的SSL芯片，如果CPU信能比较低的话，肯定会降低性能，从而不能serve更多的请求，加密后数据量的影响，所以，才会出现那么多的安全认证提示（具体可查看马海祥博客《HTTPS对网站性能优化的影响》的相关介绍）。

一般来说，引入HTTPS之后，不能导致性能变得太差，否则的话，谁还愿意用？

为了确保性能，SSL 的设计者至少要考虑如下几点：

（1）、如何选择加密算法（“对称”or“非对称”）？

（2）、如何兼顾 HTTP 采用的“短连接”TCP 方式？

SSL 是在1995年之前开始设计的，那时候的 HTTP 版本还是 1.0，默认使用的是“短连接”的 TCP 方式——默认不启用 Keep-Alive。

HTTPS的关键性能影响是CPU和往返，如果CPU很强的话，性能可能就是有人讲的80%；如果cpu是瓶颈的话，有人讲原来可以server330-500个请求每秒，现在只有30-50%，因此在使用https请求数据的时候要注意看看你的项目里面是否真的需要。

J. 什么是SSL加密，什么是TLS加密

SSL加密是Netscape公司所提出的安全保密协议，在浏览器和Web服务器之间构造安全通道来进行数据传输，SSL运行在TCP/IP层之上、应用层之下，为应用程序提供加密数据通道，它采用了RC4、MD5以及RSA等加密算法，使用40 位的密钥，适用于商业信息的加密。

TLS是安全传输层协议。安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议上面。

(10)tls加密后数据包变大扩展阅读：

SSL加密并不保护数据中心本身，而是确保了SSL加密设备的数据中心安全，可以监控企业中来往于数据中心的最终用户流量。

从某个角度来看，数据中心管理员可以放心将加密装置放在某个地方，需要使用时再进行应用，数据中心应该会有更合理的方法来应对利用SSL的恶意攻击，需要找到SSL加密应用的最佳实践。

TLS协议是可选的，必须配置客户端和服务器才能使用。主要有两种方式实现这一目标：一个是使用统一的TLS协议通信端口（例如：用于HTTPS的端口443）。另一个是客户端请求服务器连接到TLS时使用特定的协议机制（例如：邮件、新闻协议和STARTTLS）。

一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手，客户端和服务器协商各种参数用于创建安全连接。

参考资料来源：网络-SSL加密技术

参考资料来源：网络-TLS