Nginx学习笔记-HTTPS在Nginx中的使用

SSL/TLS通用模型

SSL/TLS层在网络模型的位置，它属于应用层协议。接管应用层的数据加解密，并通过网络层发送给对方。

TLS安全加密套件解读

1、ECDHE：在TLS中用于**交换，主要流程如下

ECDHE算法流程文字描述如下：

（1）：客户端随机生成随机值Ra，计算Pa(x, y) = Ra * Q(x, y)，Q(x, y)为全世界公认的某个椭圆曲线算法的基点。将Pa(x, y)发送至服务器。

（2）：服务器随机生成随机值Rb，计算Pb(x,y) - Rb * Q(x, y)。将Pb(x, y)发送至客户端。

（3）：客户端计算Sa(x, y) = Ra * Pb(x, y)；服务器计算Sb(x, y) = Rb *Pa(x, y)

（4）：算法保证了Sa = Sb = S，提取其中的S的x向量作为**（预主**）。

2、RSA：在TLS中用于**交换过程中的身份验证，主要流程如下

RSA算法流程文字描述如下：

（1）：任意客户端对服务器发起请求，服务器首先发回复自己的公钥到客户端（公钥明文传输）。

（2）：客户端使用随机数算法，生成一个**S，使用收到的公钥进行 加密，生成C，把C发送到服务器。

（3）：服务器收到C，使用公钥对应的私钥进行解密，得到S。

（4）：上述交换步骤后，客户端和服务器都得到了S，S为**（预主**）。

RSA同样也可以用于**交换，但是相比ECDHE，RSA并不是前向安全的，存在**泄漏的风险

前向安全：私钥不参与**的协商，故即使私钥泄漏，客户端和服务器之间加密的报文都无法被第三方解密

3、AES_128_GCM_SHA256

• AES：用于秘钥交换完成之后的数据加密算法
• 128：表示的是使用了AES中的128位的加密强度
• GCM：ASE有很多种分组模式，其中GCM是一种比较新的分组模式，可以提高多核CPU下加解密的性能
• SHA256：内容签名和摘要算法，用来把不定长度的字符串摘要成固定长度的字符串

套件中ECDHE、RSA是非对称加密，AES是对称加密

对称加密和非对称加密的区别

对称加密

双方持有的**相同，只需要遍历一次就可以得到密文/明文，性能非常好

如下图：Bob加密和Alice解密的**是相同的

非对称机密

公钥加密，私钥解密 -》常规用法

私钥加密，公钥解密 -》 身份验证

如下图：

• Alice和Bob都有自身的公钥和私钥
• 当Bob会给Alice发送消息时，Alice会提前将自身的公钥传递给Bob，Bob使用Alice的公钥对消息进行加密，Alice收到后再使用自身的公钥进行解密

SSL证书的公信力保证

PKL公钥基础设施

1. 证书订阅人向登记机构提交证书签名申请CSR，登记结构将CRS提交给CA，CA颁发证书，通过登记机构返还给订阅人
2. 订阅人部署证书到服务器上
3. 浏览器向服务器请求证书，服务器将证书发送给浏览器，浏览器验证证书的有效性

这里需要注意的是：证书会过期，一般为三个月到一年，而验证证书是否过期有多种方式，包括CRL，OCSP等

• CRL：浏览器主动发起验证，CRL包含了过期证书验证链条，验证性能极差
• OCSP：浏览器主动发起验证，OCSP是过期证书验证响应程序，性能一般，因此Nginx开启OCSP开关后会主动去OCSP查询证书是否过期，这样子信赖方(浏览器)就不用去访问OCSP服务器，提升性能

证书的组成

证书的分类

• DV证书：只要域名指向的是正在申请证书的服务器，就可以实时申请到证书，免费
• OV证书：组织验证，需要验证填写的企业名称是否是正确的，所以耗时需要几天时间，而且价格贵
• EV证书：扩展验证，使用更为严格的申请验证流程，浏览器会显示证书对应的企业

这三种证书安全效果是一致的，唯一不一致的是证书链

证书链

证书链包含根证书、二级证书、主证书，其中根证书验证是非常谨慎的，因为证书库存放在操作系统中，且大部分一年以上才会更新一次根证书库。

验证过程

当Nginx向浏览器发送证书时，首先验证主证书是否有效，然后浏览器在验证二级证书的时候会再次验证主证书是否有效。所以证书合法性验证归根结底就是验证证书的发行者是不是有效的

TLS通信过程

1. 浏览器向Nginx发送一个Client Hello消息，告诉服务器支持哪些加密算法
2. Nginx向浏览器发送一个Server Hello消息，Nginx中存有自身支持的加密算法链表以及自身倾向于使用的加密算法套件，Nginx会选择自己最喜欢的加密套件发送给客户端。如果我们想复用Session，也就是Nginx打开了SessionCache，希望在一天内断开连接的客户端不用再次协商秘钥，这里会直接复用之前的秘钥
3. Nginx把自己的公钥证书发送给浏览器，浏览器收到后根据证书链在根证书库中验证证书是否是有效的
4. Nginx发送一个Server Hello Dane

在第三步和第四步之间，Nginx会将选择的加密算法套件的公共参数（比如ECDHE使用的椭圆曲线算法的公共参数Q）发送给客户端，方便在第六步生成秘钥

5. 浏览器根据第四步的公共参数生成自己的私钥，再把公钥发送给服务器，这样Nginx会根据自身的私钥和服务器的公钥共同生成秘钥，也就是第六步

6. 客户端根据自身的私钥和服务器的公钥生成秘钥，此时服务端生成的秘钥和客户端生成的秘钥是相同的

7. 双方利用第六步生成的秘钥进行数据加密（AES）通信

从这里可以看到，TLS主要做两件事，交换秘钥和数据加密，所以最消耗性能也是这两点.

那么Nginx是如何优化这个性能的呢？

• 小文件传输：耗时主要发生在TLS握手，因此考验的是非对称加密的性能。可以优化椭圆曲线算法和RSA的性能，或者适当降低密码强度
• 大文件：耗时主要发生在文件传输，因此考验的是对称加密AES，可以替换比AES性能更好的算法，或者适当降低密码强度来提升性能

用免费的SSL证书实现一个HTTPS站点

安装certbot

yum install python2-certbot-nginx

域名申请https

certbot --nginx --nginx-server-root=/home/geek/nginx/conf/ -d nginx.test.com

执行过程中会出现以下提示，

代表是否要重定向，具体指的是不安全的http流量都使用301或者302重定向到https。

配置完成后查看nginx.conf发现，多了ssl的相关配置

其中include指令包含了Nginx的SSL的相关配置文件

/etc/letsencrypt/options-ssl-nginx.conf

查看这个配置文件，可以看到下图的配置

ssl_session_cache是SSL会话缓存。

SSL最消耗性能的是握手交换秘钥，所以为了降低交换秘钥的频次，ssl_session_cache为1m时能为大约4000个Https连接服务。也就是一个https连接在1440分钟的时间内是不需要再次握手交换秘钥的，可以复用之前的秘钥。

ssl_prefer_server_ciphers on 表示Nginx开始决定使用哪些安全算法与浏览器进行通信。那怎么决定使用哪些安全算法呢？ssl_ciphers中列出了所有支持的安全套件，每一个安全套件是由":"分隔的，排在前面的优先被使用。

到此，就是所有Nginx和SSL的相关内容了

参考资料
https://www.cnblogs.com/xdyixia/p/11642480.html
https://blog.****.net/mrpre/article/details/78025940