SSL连接断开后如何恢复？-一一网

问： SSL连接断开后如何恢复？

啥连接？ SSL连接还是TCP连接？还是？MySql数据库连接？还是电脑网络连接断开了之后呢？

哈哈哈哈,对这个问题的概念一脸懵逼！忘记的差不多了

那么先来了解一下什么是SSL吧

一、深入TLS/SSL协议

关于http协议是明文传输，安全性差，因此要利用https来进行加密传输，关键点在于 TLS/SSL协议。

1.1 TLS/SSL协议的发展

SSL（安全套接字）最初在1994年创建，作为http的扩展，后来逐步发展为独立协议，并更新了三个版本（v1.0、v2.0、v3.0），后来在v3.0 基础上标准化了该协议，并命名为TLS（传输层安全协议v1.0）。因此TLS可以理解为SSL协议的升级版。

1.2 HTTPS = HTTP + TLS/SSL

由于TCP协议可保证数据传输的可靠性（完整性），因此任何数据到达TCP之前经过TLS/SSL协议处理即可。

http方案的服务端默认端口为80
https方案的服务端默认端口为443

http通信风险

冒充风险：冒充他人身份与通信
窃听风险：通信内容被获取
篡改分享：通信内容被修改

TLS/SSL协议核心：

认证
密钥协商
数据加密

TLS/SSL协议主要由两层构成

握手层
加密层

1.3TLS/SSL握手

开始加密通信之前，客户端和服务器首先必须建立连接和交换参数，此过程称为握手。

相关概念：

一、认证： 客户端要通过CA机构，采用签名数字证书的技术方案，对服务端进行身份认证，避免中间人攻击。

二、密码套件协商： 客户端和服务端需要协商出双方都认可的密码套件，密码套件决定了本次连接采用的加密算法、密钥协商算法等各类算法。

三、密钥协商： 不同的密钥协商算法会有不同的握手过程，由于RSA算法和静态DH算法都存在前向安全性问题，因此目前使用最多的DHE算法和ECDH算法（与服务器密钥对的关系不大。）

四、握手消息完整性校验： 握手消息会经过TLS/SSl协议加密层保护，可以确保握手消息的机密性和完整性，如果握手消息被篡改，则整个握手过程会失败。

基于RSA算法的握手：
1、客户端给出加密协议的版本号、客户端生成的随机数和客户端支持的加密套件。
2、服务端确认使用加密协议的版本、确认双方使用的加密套件、提供数字证书（包含公钥）和随机数。
3、客户端确认数字认证有效性，并返回一个新的使用数字证书中的公钥加密的随机数（预主密钥）
4、服务端使用自己的密钥获取客户端发来的预主密钥。
客户端和服务端根据约定的加密套件，使用前面两个随机数和预主密钥生成主密钥，之后的通信使用主密钥加密解密。

由于整个握手阶段是明文的，因此也存在安全风险（第三个随机数存在被破解出的风险），可以将默认的RSA算法改为DH算法提高安全性。

基于DH算法的握手：
1、客户端给出加密协议的版本号、客户端生成的随机数和客户端支持的加密套件。
2、服务端确认使用加密协议的版本、确认双方使用的加密套件、提供数字证书（包含公钥）和随机数。
3、服务器利用私钥将客户端随机数、服务器随机数、服务器DH参数签名，生成服务器签名。
4、服务端向客户端发送服务器DH参数以及服务器签名。
5、客户端向服务端发送客户端DH参数。

之后，客户端利用公钥验证服务器签名，客户端与服务端各自利用服务端DH参数、客户端DH参数生成预主密钥，再通过预主密钥、客户端随机数、服务端随机数生成主密钥（会话密钥），最后握手完成，之后的通信使用主密钥加密解密。

此外，在认证过程中，如果客户端发现服务端证书无效，就会向用户发出警告，由其选择是否要继续通信

1.4 TLS/SSL加密

握手层协商出加密层需要的算法、算法的密钥块、加密层则进行加密运算和完整性保证。

目前主要有三种加密方式

流密码加密模式
分组加密模式
AEAD模式

考虑到加密和完整性运算涉及到的安全性问题，建议采用AEAD加密模式。

1.5 OpenSSL和TLS/SSL的关系

TLS/SSL协议是设计规范，OpenSSL是目前最通用的TLS/SSL协议实现。

OpenSSL是一个底层密码库，封装了所有的密码学算法、证书管理、TLS/SSL协议实现。

对于开发者来讲，正确地理解并使用底层OpenSSL库。

SSL连接断开后如何恢复？

一共有两种方法来恢复断开的SSL连接，一种是sessionID，一种是session ticket.

使用sessionID 的方式，每一次的会话都有一个编号，当对话中断后，下一次重新连接时，只要客户端给出这个编号，服务器如果有这个编号的记录，那么双方就可以继续使用以前的密钥，而不用重新生成一把。
- 目前所有的浏览器都支持一种方法。
- 但是这种方法有一个缺点是：session ID 只能够存在一台服务器上，如果我们的请求通过负载平衡被转移到了其他的服务器上，那么就无法恢复对话。
另一种方式是session ticket的方式，session ticket是服务器在上一次对话中发送给客户的，这个ticket是加密的，只有服务器能够解密，里面包含了本次对话的信息，比如对话秘钥和加密方法等。
- 这样不管我们的请求是否转移到其他的服务器上，当服务器将ticket解密以后，就能够获取上次对话的信息，就不用重新生成对话秘钥了。