为什么建设的网站有时候访问慢,vs2012解决方案做网站,深圳做外贸网站公司哪家好,app排名目录 HTTP 与 HTTPS 有哪些区别#xff1f;HTTPS 解决了 HTTP 的哪些问题HTTPS 是如何建立连接的#xff1f;其间交互了什么TLS 协议建立的详细流程客户端校验数字证书的流程是怎样的#xff1f; HTTPS 的应用数据是如何保证完整性的HTTPS 一定安全可靠吗参考资料 HTTP 与 H… 目录 HTTP 与 HTTPS 有哪些区别HTTPS 解决了 HTTP 的哪些问题HTTPS 是如何建立连接的其间交互了什么TLS 协议建立的详细流程客户端校验数字证书的流程是怎样的 HTTPS 的应用数据是如何保证完整性的HTTPS 一定安全可靠吗参考资料 HTTP 与 HTTPS 有哪些区别
HTTP 是超文本传输协议信息是明文传输存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议使得报文能够加密传输。HTTP 连接建立相对简单 TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后还需进行 SSL/TLS 的握手过程才可进入加密报文传输。两者的默认端口不一样HTTP 默认端口号是 80HTTPS 默认端口号是 443。HTTPS 协议需要向 CA证书权威机构申请数字证书来保证服务器的身份是可信的。
HTTPS 解决了 HTTP 的哪些问题
HTTP 由于是明文传输所以安全上存在以下三个风险
窃听风险篡改风险冒充风险
HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议可以很好的解决了上述的风险
信息加密交互信息无法被窃取。校验机制无法篡改通信内容篡改了就不能正常显示。身份证书证明淘宝是真的淘宝网。
SSL/TLS 协议是能保证通信是安全的。 HTTPS 是如何解决上面的三个风险的 混合加密的方式实现信息的机密性解决了窃听的风险。摘要算法的方式来实现完整性它能够为数据生成独一无二的「指纹」指纹用于校验数据的完整性解决了篡改的风险。将服务器公钥放入到数字证书中解决了冒充的风险。
1. 混合加密
通过混合加密的方式可以保证信息的机密性解决了窃听的风险。
HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式
在通信建立前采用非对称加密的方式交换「会话秘钥」后续就不再使用非对称加密。在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。
采用「混合加密」的方式的原因
对称加密只使用一个密钥运算速度快密钥必须保密无法做到安全的密钥交换。非对称加密使用两个密钥公钥和私钥公钥可以任意分发而私钥保密解决了密钥交换问题但速度慢。
2. 摘要算法 数字签名
为了保证传输的内容不被篡改我们需要对内容计算出一个「指纹」然后同内容一起传输给对方。
对方收到后先是对内容也计算出一个「指纹」然后跟发送方发送的「指纹」做一个比较如果「指纹」相同说明内容没有被篡改否则就可以判断出内容被篡改了。
在计算机里会用摘要算法哈希函数来计算出内容的哈希值也就是内容的「指纹」这个哈希值是唯一的且无法通过哈希值推导出内容。
通过哈希算法可以确保内容不会被篡改但是并不能保证「内容 哈希值」不会被中间人替换因为这里缺少对客户端收到的消息是否来源于服务端的证明。
那为了避免这种情况计算机里会用非对称加密算法来解决共有两个密钥
一个是公钥这个是可以公开给所有人的一个是私钥这个必须由本人管理不可泄露。
这两个密钥可以双向加解密的比如可以用公钥加密内容然后用私钥解密也可以用私钥加密内容公钥解密内容。
流程的不同意味着目的也不相同
公钥加密私钥解密。这个目的是为了保证内容传输的安全因为被公钥加密的内容其他人是无法解密的只有持有私钥的人才能解密出实际的内容私钥加密公钥解密。这个目的是为了保证消息不会被冒充因为私钥是不可泄露的如果公钥能正常解密出私钥加密的内容就能证明这个消息是来源于持有私钥身份的人发送的。
一般我们不会用非对称加密来加密实际的传输内容因为非对称加密的计算比较耗费性能的。
所以非对称加密的用途主要在于通过「私钥加密公钥解密」的方式来确认消息的身份我们常说的数字签名算法就是用的是这种方式不过私钥加密内容不是内容本身而是对内容的哈希值加密。
私钥是由服务端保管然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息能被公钥解密就说明该消息是由服务器发送的。
引入了数字签名算法后你就无法模仿你爸爸的字迹来请假了你爸爸手上持有着私钥你老师持有着公钥。
这样只有用你爸爸手上的私钥才对请假条进行「签名」老师通过公钥看能不能解出这个「签名」如果能解出并且确认内容的完整性就能证明是由你爸爸发起的请假条这样老师才允许你请假否则老师就不认。
3. 数字证书
前面我们知道
可以通过哈希算法来保证消息的完整性可以通过数字签名来保证消息的来源可靠性能确认消息是由持有私钥的一方发送的
但是这还远远不够还缺少身份验证的环节万一公钥是被伪造的呢
在计算机里这个权威的机构就是 CA 数字证书认证机构将服务器公钥放在数字证书由数字证书认证机构颁发中只要证书是可信的公钥就是可信的。
通过数字证书的方式保证服务器公钥的身份解决冒充的风险。
HTTPS 是如何建立连接的其间交互了什么
SSL/TLS 协议基本流程
客户端向服务器索要并验证服务器的公钥。双方协商生产「会话秘钥」。双方采用「会话秘钥」进行加密通信。
前两步也就是 SSL/TLS 的建立过程也就是 TLS 握手阶段。
TLS 的「握手阶段」涉及四次通信使用不同的密钥交换算法TLS 握手流程也会不一样的现在常用的密钥交换算法有两种RSA 算法和 ECDHE 算法。
TLS 协议建立的详细流程
1. ClientHello
首先由客户端向服务器发起加密通信请求也就是 ClientHello 请求。
在这一步客户端主要向服务器发送以下信息
1客户端支持的 TLS 协议版本如 TLS 1.2 版本。
2客户端生产的随机数Client Random后面用于生成「会话秘钥」条件之一。
3客户端支持的密码套件列表如 RSA 加密算法。
2. SeverHello
服务器收到客户端请求后向客户端发出响应也就是 SeverHello。服务器回应的内容有如下内容
1确认 TLS 协议版本如果浏览器不支持则关闭加密通信。
2服务器生产的随机数Server Random也是后面用于生产「会话秘钥」条件之一。
3确认的密码套件列表如 RSA 加密算法。
4服务器的数字证书。
3.客户端回应
客户端收到服务器的回应之后首先通过浏览器或者操作系统中的 CA 公钥确认服务器的数字证书的真实性。
如果证书没有问题客户端会从数字证书中取出服务器的公钥然后使用它加密报文向服务器发送如下信息
1一个随机数pre-master key。该随机数会被服务器公钥加密。
2加密通信算法改变通知表示随后的信息都将用「会话秘钥」加密通信。
3客户端握手结束通知表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要用来供服务端校验。
上面第一项的随机数是整个握手阶段的第三个随机数会发给服务端所以这个随机数客户端和服务端都是一样的。
服务器和客户端有了这三个随机数Client Random、Server Random、pre-master key接着就用双方协商的加密算法各自生成本次通信的「会话秘钥」。
4. 服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后通过协商的加密算法计算出本次通信的「会话秘钥」。
然后向客户端发送最后的信息
1加密通信算法改变通知表示随后的信息都将用「会话秘钥」加密通信。
2服务器握手结束通知表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要用来供客户端校验。
至此整个 TLS 的握手阶段全部结束。接下来客户端与服务器进入加密通信就完全是使用普通的 HTTP 协议只不过用「会话秘钥」加密内容。 基于 RSA 算法的 HTTPS 存在「前向安全」的问题如果服务端的私钥泄漏了过去被第三方截获的所有 TLS 通讯密文都会被破解。 为了解决这个问题后面就出现了 ECDHE 密钥协商算法现在大多数网站使用的正是 ECDHE 密钥协商算法 客户端校验数字证书的流程是怎样的
CA 签发证书的过程
首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包然后对这些信息进行 Hash 计算得到一个 Hash 值然后 CA 会使用自己的私钥将该 Hash 值加密生成 Certificate Signature也就是 CA 对证书做了签名最后将 Certificate Signature 添加在文件证书上形成数字证书
客户端校验服务端的数字证书的过程
首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1通常浏览器和操作系统中集成了 CA 的公钥信息浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容得到一个 Hash 值 H2 最后比较 H1 和 H2如果值相同则为可信赖的证书否则则认为证书不可信。
但事实上证书的验证过程中还存在一个证书信任链的问题因为我们向 CA 申请的证书一般不是根证书签发的而是由中间证书签发的
假如百度是三级层级关系对于这种三级层级关系的证书的验证过程如下
客户端收到 baidu.com 的证书后发现这个证书的签发者不是根证书就无法根据本地已有的根证书中的公钥去验证 baidu.com 证书是否可信。于是客户端根据 baidu.com 证书中的签发者找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2”然后向 CA 请求该中间证书。请求到证书后发现 “GlobalSign Organization Validation CA - SHA256 - G2” 证书是由 “GlobalSign Root CA” 签发的由于 “GlobalSign Root CA” 没有再上级签发机构说明它是根证书也就是自签证书。应用软件会检查此证书有否已预载于根证书清单上如果有则可以利用根证书中的公钥去验证 “GlobalSign Organization Validation CA - SHA256 - G2” 证书如果发现验证通过就认为该中间证书是可信的。“GlobalSign Organization Validation CA - SHA256 - G2” 证书被信任后可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 证书中的公钥去验证 baidu.com 证书的可信性如果验证通过就可以信任 baidu.com 证书。
在这些步骤中最开始客户端只信任根证书 GlobalSign Root CA 证书的然后 “GlobalSign Root CA” 证书信任 “GlobalSign Organization Validation CA - SHA256 - G2” 证书而 “GlobalSign Organization Validation CA - SHA256 - G2” 证书又信任 baidu.com 证书于是客户端也信任 baidu.com 证书。
总的来说由于用户信任 GlobalSign所以由 GlobalSign 所担保的 baidu.com 可以被信任另外由于用户信任操作系统或浏览器的软件商所以由软件商预载了根证书的 GlobalSign 都可被信任。
操作系统里一般都会内置一些根证书。 为什么需要证书链这么麻烦的流程Root CA 为什么不直接颁发证书而是要搞那么多中间层级呢 这是为了确保根证书的绝对安全性将根证书隔离地越严格越好不然根证书如果失守了那么整个信任链都会有问题。
HTTPS 的应用数据是如何保证完整性的
TLS 在实现上分为握手协议和记录协议两层
TLS 握手协议就是我们前面说的 TLS 四次握手的过程负责协商加密算法和生成对称密钥后续用此密钥来保护应用程序数据即 HTTP 数据TLS 记录协议负责保护应用程序数据并验证其完整性和来源所以对 HTTP 数据加密是使用记录协议
TLS 记录协议主要负责消息HTTP 数据的压缩加密及数据的认证。
具体过程如下
首先消息被分割成多个较短的片段,然后分别对每个片段进行压缩。接下来经过压缩的片段会被加上消息认证码MAC 值这个是通过哈希算法生成的这是为了保证完整性并进行数据的认证。通过附加消息认证码的 MAC 值可以识别出篡改。与此同时为了防止重放攻击在计算消息认证码时还加上了片段的编码。再接下来经过压缩的片段再加上消息认证码会一起通过对称密码进行加密。最后上述经过加密的数据再加上由数据类型、版本号、压缩后的长度组成的报头就是最终的报文数据。
记录协议完成后最终的报文数据将传递到传输控制协议 (TCP) 层进行传输。
HTTPS 一定安全可靠吗
问题的场景是这样的客户端通过浏览器向服务端发起 HTTPS 请求时被「假基站」转发到了一个「中间人服务器」于是客户端是和「中间人服务器」完成了 TLS 握手然后这个「中间人服务器」再与真正的服务端完成 TLS 握手。
具体过程如下
客户端向服务端发起 HTTPS 建立连接请求时然后被「假基站」转发到了一个「中间人服务器」接着中间人向服务端发起 HTTPS 建立连接请求此时客户端与中间人进行 TLS 握手中间人与服务端进行 TLS 握手在客户端与中间人进行 TLS 握手过程中中间人会发送自己的公钥证书给客户端客户端验证证书的真伪然后从证书拿到公钥并生成一个随机数用公钥加密随机数发送给中间人中间人使用私钥解密得到随机数此时双方都有随机数然后通过算法生成对称加密密钥A后续客户端与中间人通信就用这个对称加密密钥来加密数据了。在中间人与服务端进行 TLS 握手过程中服务端会发送从 CA 机构签发的公钥证书给中间人从证书拿到公钥并生成一个随机数用公钥加密随机数发送给服务端服务端使用私钥解密得到随机数此时双方都有随机数然后通过算法生成对称加密密钥B后续中间人与服务端通信就用这个对称加密密钥来加密数据了。后续的通信过程中中间人用对称加密密钥A解密客户端的 HTTPS 请求的数据然后用对称加密密钥B加密 HTTPS 请求后转发给服务端接着服务端发送 HTTPS 响应数据给中间人中间人用对称加密密钥B解密 HTTPS 响应数据然后再用对称加密密钥A加密后转发给客户端。
从客户端的角度看其实并不知道网络中存在中间人服务器这个角色。那么中间人就可以解开浏览器发起的 HTTPS 请求里的数据也可以解开服务端响应给浏览器的 HTTPS 响应数据。相当于中间人能够 “偷看” 浏览器与服务端之间的 HTTPS 请求和响应的数据。
但是要发生这种场景是有前提的前提是用户点击接受了中间人服务器的证书。
中间人服务器与客户端在 TLS 握手过程中实际上发送了自己伪造的证书给浏览器而这个伪造的证书是能被浏览器客户端识别出是非法的于是就会提醒用户该证书存在问题。
如果用户执意点击「继续浏览此网站」相当于用户接受了中间人伪造的证书那么后续整个 HTTPS 通信都能被中间人监听了。
所以这其实并不能说 HTTPS 不够安全毕竟浏览器都已经提示证书有问题了如果用户坚决要访问那不能怪 HTTPS 。
另外如果你的电脑中毒了被恶意导入了中间人的根证书那么在验证中间人的证书的时候由于你操作系统信任了中间人的根证书那么等同于中间人的证书是合法的这种情况下浏览器是不会弹出证书存在问题的风险提醒的。
这其实也不关 HTTPS 的事情是你电脑中毒了才导致 HTTPS 数据被中间人劫持的。
所以HTTPS 协议本身到目前为止还是没有任何漏洞的即使你成功进行中间人攻击本质上是利用了客户端的漏洞用户点击继续访问或者被恶意导入伪造的根证书并不是 HTTPS 不够安全。 为什么抓包工具能截取 HTTPS 数据 很多抓包工具之所以可以明文看到 HTTPS 数据工作原理与中间人一致的。
对于 HTTPS 连接来说中间人要满足以下两点才能实现真正的明文代理:
中间人作为客户端与真实服务端建立连接这一步不会有问题因为服务端不会校验客户端的身份中间人作为服务端与真实客户端建立连接这里会有客户端信任服务端的问题也就是服务端必须有对应域名的私钥
中间人要拿到私钥只能通过如下方式
去网站服务端拿到私钥去CA处拿域名签发私钥自己签发证书切要被浏览器信任
抓包工具只能使用第三种方式取得中间人的身份。
使用抓包工具进行 HTTPS 抓包的时候需要在客户端安装 Fiddler 的根证书这里实际上起认证中心CA的作用。
抓包工具能够抓包的关键是客户端会往系统受信任的根证书列表中导入抓包工具生成的证书而这个证书会被浏览器信任也就是抓包工具给自己创建了一个认证中心 CA客户端拿着中间人签发的证书去中间人自己的 CA 去认证当然认为这个证书是有效的。 如何避免被中间人抓取数据 我们要保证自己电脑的安全不要被病毒乘虚而入而且也不要点击任何证书非法的网站这样 HTTPS 数据就不会被中间人截取到了。
还可以通过 HTTPS 双向认证来避免这种问题。
一般我们的 HTTPS 是单向认证客户端只会验证了服务端的身份但是服务端并不会验证客户端的身份。
如果用了双向认证方式不仅客户端会验证服务端的身份而且服务端也会验证客户端的身份。服务端一旦验证到请求自己的客户端为不可信任的服务端就拒绝继续通信客户端如果发现服务端为不可信任的那么也中止通信。
参考资料
《小林 coding》
《计算机网络》
