https 是一种加密传输协议,基于非对称加密算法和对称加密算法的协作使用。https 主要作用:1.对数据加密 2.验证网站服务器身份
为什么不使用单一的加密算法?
单一使用对称加密
单一使用非对称加密 (RSA)
拦截客户端报文,伪造公钥
当客户端初次向服务器请求公钥时,报文可能被黑客截获,黑客伪装服务器向客户端返回一个黑客生成的公钥,并且自己保留私钥。当客户端使用该黑客虚假公钥加密发送报文时,黑客就可以用私钥解密客户端发送的报文信息。
拦截服务端报文,伪造公钥
当客户端初次向服务器请求秘钥时,服务器返回公钥报文,中途被黑客截获,并且黑客修改报文中的公钥信息为黑客生成的公钥。当客户端发送使用黑客虚假公钥加密的报文给服务器时,可能被黑客截获报文信息并且用黑客私钥解密。
拦截服务端报文,解密返回给客户的报文信息
当客户端安全获得服务器发放公钥并且请求服务器时,服务器返回加密后报文信息。黑客可以截获服务器返回的报文信息,并且用公钥解密(因为公钥是大家都知道的),从而盗取服务器响应报文。
从上面几种情况,可以看出
因此,最终我们的实际通信过程只能通过对称加密来实现,这样才能实现双向的安全通信,并且要解决的问题是安全地协商出一个对称秘钥。这个过程就是 https 加密的总体思路。
要安全地协商出一个对称加密密钥 DK,只能通过一个安全的通道来进行,也就是需要对协商 DK 的报文进行再次加密,显然不能再使用对称加密方式来进行加密协商报文。自然而然就想到使用非对称加密的方式。
我们假设非对称公钥 FK.pub 能够安全的发布到客户端,那么我们客户端只要把 DK 用 FK.pub 进行加密发送给服务端,服务器端用非对称私钥 FK.pri 解密,这样服务器和客户端都能获取到了 DK 。基于只有客户端和服务器端的知道的 DK 进行加密通信的过程是安全的。
那么问题就流转到 FK.pub 如何安全地发布到客户端?这就是我们需要解决的根源问题。
下面是我们整体分析的流程:
非对称要安全发布公钥需要解决的问题是
1.【拦截客户端报文,伪造公钥】
2.【拦截服务端报文,伪造公钥】
这时候,解决办法就是委托第三方 CA 证书机构,帮助我们完成这个公钥的安全发布过程。
这个过程一般可以这样描述。
1.服务器提供服务器的公钥给 CA机构,生成证书,证书一般包含以下内容:
Issuer (证书的发布机构)
Valid from , Valid to (证书的有效期)
Public key (公钥)
Subject (主题)
Signature algorithm (签名所使用的算法)
Thumbprint, Thumbprint algorithm (指纹以及指纹算法)
生成证书的过程一般是:把 Issuer, Public key, Subject, Valid from, Valid to 等信息以明文的形式写到证书里面作为内容,然后用一个指纹算法计算出这些数字证书内容的一个指纹(也就是签名),并把指纹和指纹算法用自己的私钥进行加密,然后生成证书
2.服务器获得 CA 机构发放的数字证书
3.一般 CA 机构都是得到认证的权威机构,这些机构的根证书都是被我们的操作系统所认可的。在客户端也是已经提前安装权威机构的根证书。
4.客户端建立连接后,向服务器发起请求
5.服务器返回 CA 机构为我们生成的数字证书
6.客户端根据根证书验证服务器返回的数字证书的可靠性。根据根证书中的写明的签名算法,对内容做签名,然后利用根证书解密签名内容,对比两个签名内容判断证书内容是否被篡改,最后获取到服务器的公钥。
以上就是对上图的步骤的一些解析,接下来客户端和服务器就要进行协商对称密钥操作了。但是这里需要对第5步做解析,为什么这里的 rsa 能够保证服务器公钥安全发布?
【拦截客户端报文,伪造公钥】这种情况在单一非对称加密中,是黑客冒充服务器返回公钥。那么在这里能不能冒充服务器返回数字证书呢?答案是不能。假设当黑客返回冒充数字证书,那么客户端用sa机构的根证书解密被加密的签名内容时,是取不到正确是值的,这一点保证的【拦截客户端报文,伪造公钥】不会出现。
【拦截服务端报文,伪造公钥】这种情况是属于黑客篡改服务器返回的公钥,那么在这里会不会出现黑客篡改服务器返回的证书呢?答案是不能。假设黑客篡改了,证书内容,那么客户端验签时就会不通过;假设黑客修改了签名,那么就会在客户端用根证书解密签名时失败。因此保证【拦截服务端报文,伪造公钥】不会出现。
好了,接下来是我们根据得到的正确的服务器公钥,进行安全的客户端 -> 服务器通信过程,并且协商对称密钥。
1.客户端拿到公钥之后先发送一个随机串到服务器,然服务器进行加密,并且返回
2.客户端用公钥解密收到的报文,发现果然能解开,于是确认这就是正确的公钥。
3.客户端生成一个对称加密密钥,公钥加密,并且发送给服务器。这个过程是安全的。
4.服务器收到对称密钥加密报文。用私钥进行解密,拿到到客户端发来的密钥,于是愉快的开始了通信~
现有如下的web架构(简化之后的),需要把原来的http访问修改到https访问!haproxy的认证有两种方式:第一种:haproxy提供ssl证书,后面的nginx访问使用正常的http。第二种:haproxy做正常的代理,后面的nginx提供ssl证书!
对已抓取的HTTPS流量数据包,如果对其进行解密,需要满足以下几个前提:1、在SSL/TLS协商阶段,被选中的加密套件使用的密钥交换方式为RSA,2、已经获取RSA证书的私钥。
步骤一:下载 Nginx 版证书文件,解压以后可以看到一个 .key 文件和 .crt/.pem 文件,步骤二:上传证书。把上面的 .key 文件和 .crt/.pem 文件上传到 /root 目录中,命名为 ssl.crt/ssl.pem 和 ssl.key,步骤三:LNMP 一键安装包的 Nginx 配置在 /usr/local/nginx/conf/vhost/ 目录中
发现了 acme.sh 这个库,这个是用Shell脚本编写的,不需要安装其他东西,比较纯净。准备工作:一个已解析好的域名(可以用http来访问)。开启服务器的443端口防火墙。
有时候使用电脑浏览器遇到网站安全https证书风险的时候,浏览器提示证书风险怎么办呢?下面来教大家几个方法:
当前电脑系统时间错误,所有的http安全证书都有颁发日期和截止日期,电脑系统时间在证书有效时间区间之外有可能导致浏览器提示网站https安全证书已过期或还未生效,网站的https安全证书确实已经过期
这里用的是集成开发环境XAMPP,假设已经配置好ssl证书,不知如何申请ssl证书者请自行百度。修改Apache相关配置文件,强制所有http跳转到https,假设网站域名为xxx.com。
一般我们本地预览的时候,一般就用 localhost + 端口 就行了,再有需要的话,会类似修改 Hosts ,然后进行域名的绑定,这样我们可以借助本地 hosts 来实现对域名访问本地的服务。
公钥和私钥是一对密钥对,它们可以互解密。使用公钥加密,私钥解密。能有效保证数据的安全性。但是如果使用私钥加密,公钥解密呢,则可以确定来源的合法性。因为只有知道私钥才能加密
HTTP是不安全的,我们的页面也被运营商插入过小黄图广告(数据被篡改),对于HTTP来说,再简单不过,只需要设定相应的DNS,做一个中间人攻击,再将修改后的数据返回,这一方面可能泄露用户隐私数据
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!