Web服务器

最新推荐文章于 2024-11-03 12:02:27 发布

疯狂的rabbit.

最新推荐文章于 2024-11-03 12:02:27 发布

阅读量650

点赞数 17

分类专栏： RHCE 文章标签： linux 运维服务器 rhce web openEuler

本文链接：https://blog.csdn.net/m0_61665967/article/details/140052050

版权

RHCE 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

一、概念解释

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息。
HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等。为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS。
HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext TransferProtocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道。
HTTPS并不是一个新协议，而是HTTP+SSL（TLS）。原本HTTP先和TCP（假定传输层是TCP协议）直接通信，而加了SSL后，就变成HTTP先和SSL通信，再由SSL和TCP通信，相当于SSL被嵌在了HTTP和TCP之间

SSL 是“Secure Sockets Layer”的缩写，中文叫做“安全套接层”。它是在上世纪90年代中期，由网景公司设计的。到了1999年，SSL 应用广泛，已经成为互联网上的事实标准。IETF 就把SSL 标准化。标准化之后SSL被改为 TLS（Transport Layer Security传输层安全协议）
1、SSL协议分为两层
SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能
SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等
2、SSL协议提供的服务
认证用户和服务器，确保数据发送到正确的客户机和服务器
加密数据以防止数据中途被窃取
维护数据的完整性，确保数据在传输过程中不被改变

二、HTTPS安全通信机制

1、图解

2、过程

（1）客户端（通常是浏览器）向服务端发送加密通信的请求，然后连接到服务端的443端口，这被叫做ClientHello请求,客户端主要向服务器提供以下信息

支持的协议版本，比如TLS 1.0版。
一个客户端生成的随机数1，稍后用于生成"会话密钥"。
支持的加密方法，比如RSA公钥加密。
支持的压缩方法。

（2）服务端回应（SeverHello）,接收到信息之后给予客户端响应握手信息,服务器的回应包含以下内容:

确认使用的加密通信协议版本，比如TLS 1.0版本,。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
一个服务器生成的随机数2，稍后用于生成"会话密钥"。
确认使用的加密方法，这个加密算法一定是client发送给server加密算法的子集,比如RSA公钥加密
服务器证书:可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，传送的证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名等
除此之外，如果服务器需要使用双向认证，就会再包含一项请求，要求客户端提供"客户端证书"。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书

（3）客户端回应：客户端收到服务器回应以后进行证书解析，首先会验证证书是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机数3(预主密钥"pre-master key"），接下来是通过随机值1、随机值2和随机数3组装会话秘钥。然后通过服务器端证书的公钥加密会话秘钥，传送加密信息，内容如下：

一个随机数C。该随机数用服务器公钥加密，防止被窃听。
编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验

（4）服务器的最后回应：服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"（对称密钥）。然后，向客户端最后发送下面信息。

编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。
大致分为三个阶段：

（1）（2）认证服务器：浏览器内置一个受信任的CA机构列表，并保存了这些CA机构的证书。第一阶段服务器会提供经CA机构认证颁发的服务器证书，如果认证该服务器证书的CA机构，存在于浏览器的受信任CA机构列表中，并且服务器证书中的信息与当前正在访问的网站（域名等）一致，那么浏览器就认为服务端是可信的，并从服务器证书中取得服务器公钥，用于后续流程。否则，浏览器将提示用户，根据用户的选择，决定是否继续。当然，我们可以管理这个受信任CA机构列表，添加我们想要信任的CA机构，或者移除我们不信任的CA机构。

（3）（4）协商会话密钥：客户端在认证完服务器，获得服务器的公钥之后，利用该公钥与服务器进行加密通信，协商出两个会话密钥，分别是用于加密客户端往服务端发送数据的客户端会话密钥，用于加密服务端往客户端发送数据的服务端会话密钥。在已有服务器公钥，可以加密通讯的前提下，还要协商两个对称密钥的原因，是因为非对称加密相对复杂度更高，在数据传输过程中，使用对称加密，可以节省计算资源。另外，会话密钥是随机生成，每次协商都会有不一样的结果，所以安全性也比较高。

加密通讯：此时客户端服务器双方都有了本次通讯的会话密钥，之后传输的所有Http数据，都通过会话密钥加密。这样网路上的其它用户，将很难窃取和篡改客户端和服务端之间传输的数据，从而保证了数据的私密性和完整性。

三、https网站配置

[root@localhost ~]# nmcli connection modify ens33 +ipv4.addresses 192.168.84.110/24
[root@localhost ~]# nmcli connection up ens33
连接已成功激活（D-Bus 活动路径：/org/freedesktop/NetworkManager/ActiveConnection/4）
[root@localhost ~]# mkdir -pv /www/https
mkdir: 已创建目录 '/www/https'
[root@localhost ~]# echo this is https > /www/https/index.html

#生成私钥
[root@localhost ~]# cd /etc/pki/tls/certs/
[root@localhost certs]# openssl genrsa -out https.key
Generating RSA private key, 2048 bit long modulus (2 primes)
..........+++++
...........+++++
e is 65537 (0x010001)

#基于私钥生成证书
[root@localhost certs]# openssl req -utf8 -new -key https.key -x509 -days 100 -out https.crt


[root@localhost ~]# vim /etc/nginx/conf.d/test_https.conf
    server {
        #listen 80;
        listen 192.168.84.110:443 ssl;
        root /www/https;
        ssl_certificate /etc/pki/tls/certs/https.crt;    #证书文件地址
        ssl_certificate_key /etc/pki/tls/certs/https.crt;
        location /{}
}

#重启服务
[root@localhost ~]# systemctl restart nginx
[root@localhost ~]# curl --insecure https://192.168.84.110
this is https
[root@localhost ~]# curl -k https://192.168.84.110
this is https