HTTPS原理:
HTTPS(超文本传输安全协议),HTTPS是在HTTP协议的基础上增加了安全的属性,HTTPS通过SSL/TLS(安全套阶层)来加密数据包,SSL再通过数字证书来验证服务器的身份,以此来实现数据在客户端到服务器之间的传输安全。
什么意思呢,通俗点理解就是HTTPS通过数据加密和身份验证的方法解决了HTTP在消息传输过程中不安全的问题。那HTTPS协议在数据的传输过程中又是怎么进行加密和身份验证的呢?首先我们来了解一下两种加密方式:对称加密和非对称加密。
对称加密:
有一段秘钥,能通过它来加密一段信息,形成一段密文,而这段密文是不能读取的,想要读取这段密文就需要通过加密它的秘钥来解密,还原成原始信息。就是一个门只能用一把钥匙来反锁和打开。用对称加密能解决消息传输中的安全问题吗?很显然是不能的,因为对称加密进行加密和解密需要用到相同的秘钥,而这把秘钥无论是由客户端产生,还是由服务器产生都需要将这把秘钥传送给对方,这样对方才能解密你所传输的密文,但是,秘钥是需要传送给对方的,也就是说秘钥同样在传输的过程中是能够被拦截的,除非能够直接把秘钥送到对方而不经过网络传输,很显然这样是不现实的,所以对称加密并不能解决数据传输中的安全问题。那我们再来看看非对称加密。
非对称加密:
有一个公钥和与之配对的私钥,用公钥加密的数据只能用私钥来进行解密,使用私钥加密的数据只能通过私钥进行解密。
那使用非对称加密能解决数据传输过程中的安全问题吗?很显然也是不行的,与对称加密一样,产生秘钥的一方需要将公钥传给对方,双方才能以这个秘钥为基础来进行通信,那在传输的过程中黑客仍然能够截取到所传输的公钥,客户端通过公钥加密数据发送给服务器,而通过公钥加密的数据只能用私钥解密,但黑客只有公钥,所以从客户端发送给服务器的消息可以认为是安全的,它不会被轻易读取,但是服务器用私钥加密传送给客户端的消息就不够安全了,因为黑客和客户端都拥有公钥,都可以对服务器发送的消息进行解密。所以用对称加密的方法只能解决单向的数据加密问题,并且消息仍是没有验证其完整性和真实性的,黑客仍然可以通过中间人攻击,所以非对称加密也不够安全。
那么对称加密+非对称加密:问题解决。
客户端拥有秘钥A,服务器拥有公钥B和私钥C,首先,客户端向服务器发送请求,服务器接到请求,响应请求并把它的公钥B传给客户端,客户端接收到公钥B后用公钥B加密秘钥A,形成一段密文,然后把密文传给服务器,而公钥加密的密文只能用私钥解密,但我们只传输过公钥,所以只有服务器拥有私钥,能够解密这段密文得到秘钥A,这样就只有客户端和服务器这个秘钥A了,中间没有任何人拥有秘钥A,然后客户端和服务器的通信就可以通过秘钥A来进行加密解密,这样就保证了数据传输过程中的加密问题。
客户端向服务器发送请求,然后服务器响应请求并返回公钥,这时黑客截取到公钥,然后自己生成一对公私钥,并把自己生成的公钥传给客户端,客户端无法验证其身份,误认为是服务器,就用黑客的公钥加密自己的秘钥,并把形成的密文返回给黑客,黑客用自己的私钥解密就得到了客户端的秘钥,再用截取到服务器的公钥加密客户端的秘钥,并将其发送给服务器,服务器用私钥解密得到秘钥,然后客户端服务器正常通信,但是黑客也有秘钥,这样数据仍然很危险。
所以只需要对服务器的响应进行身份认证就能解决身份冒用的问题了。怎么解决呢?–数字证书。
数字证书:数字证书由可信任的第三方颁发,相当于一个身份证,可以验证服务器的身份。数字证书包含了证书持有者的信息和公钥信息。

配置:
X.509通用的证书格式包含三个文件:
key:私钥文件
csr:证书签名请求文件,用于提交给证书颁发机构(CA)对证书签名
crt:是CA机构签名后的证书,包含证书中的信息。
配置安全web服务站点http://www.openlab.com配置SSL加密,
要求:生成自签名证书文件为openlab.crt,私钥文件为openlab.key
第一步:安装SSL
yum install mod_ssl -y
rpm -qa mod_ssl
第二步:创建访问文件目录及其内容
mkdir /www/openlab
echo this is openlab > /www/openlab/index.html
第三步:编辑配置文件
vim /etc/httpd/conf.d/vhost.conf
第四步:注册证书
cd /ect/pki/tls/certs
make openlab.crt
第五步:修改/etc/httpd/conf.d/vhost.conf中的.crt和.key
路径
第六步:在/etc/hosts下输入ip绑定的域名
第七步:重启http服务
#systemctl restart httpd
第八步:浏览器测试
虚拟主机,虚拟目录,目录权限的所有需求的配置如图