关于java:面试官HTTPS-是如何保证传输安全的你必须学会

43次阅读

共计 2871 个字符,预计需要花费 8 分钟才能阅读完成。

起源:segmentfault.com/a/1190000023936425

1. HTTP 协定

在议论 HTTPS 协定之前,先来回顾一下 HTTP 协定的概念。

1.1 HTTP 协定介绍

HTTP 协定是一种基于文本的传输协定,它位于 OSI 网络模型中的 应用层

HTTP 协定是通过客户端和服务器的申请应答来进行通信,目前协定由之前的 RFC 2616 拆分成立六个独自的协定阐明(RFC 7230、RFC 7231、RFC 7232、RFC 7233、RFC 7234、RFC 7235),通信报文如下:

  • 申请
POST http://www.baidu.com HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Content-Length: 7
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

wd=HTTP
  • 响应
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Thu, 14 Feb 2019 07:23:49 GMT
Transfer-Encoding: chunked

<html>...</html>

1.2 HTTP 中间人攻打

HTTP 协定应用起来的确十分的不便,然而它存在一个致命的毛病:不平安

咱们晓得 HTTP 协定中的报文都是以明文的形式进行传输,不做任何加密,这样会导致什么问题呢?上面来举个例子:

  1. 小明在 JAVA 贴吧发帖,内容为 我爱 JAVA

  1. 被中间人进行攻打,内容批改为 我爱 PHP

  1. 小明被群嘲(手动狗头)

能够看到在 HTTP 传输过程中,中间人能看到并且批改 HTTP 通信中所有的申请和响应内容,所以应用 HTTP 是十分的不平安的。

1.3 避免中间人攻打

这个时候可能就有人想到了,既然内容是明文那我应用 对称加密 的形式将报文加密这样中间人不就看不到明文了吗,于是如下革新:

  1. 单方约定加密形式

  1. 应用 AES 加密报文

这样看似中间人获取不到明文信息了,但其实在通信过程中还是会以明文的形式裸露加密形式和秘钥,如果第一次通信被拦挡到了,那么秘钥就会泄露给中间人,中间人依然能够解密后续的通信:

那么对于这种状况,咱们必定就会思考能不能将秘钥进行加密不让中间人看到呢?答案是有的,采纳 非对称加密,咱们能够通过 RSA 算法来实现。

在约定加密形式的时候由服务器生成一对 公私钥 ,服务器将 公钥 返回给客户端,客户端本地生成一串秘钥 (AES_KEY) 用于 对称加密 ,并通过服务器发送的 公钥 进行加密失去 (AES_KEY_SECRET),之后返回给服务端,服务端通过 私钥 将客户端发送的 AES_KEY_SECRET 进行解密失去 AEK_KEY, 最初客户端和服务器通过AEK_KEY 进行报文的加密通信,革新如下:

能够看到这种状况下中间人是窃取不到用于 AES 加密 的秘钥,所以对于后续的通信是必定无奈进行解密了,那么这样做就是相对平安了吗?

所谓道高一尺魔高一丈,中间人为了对应这种加密办法又想出了一个新的破解计划,既然拿不到 AES_KEY,那我就把本人模仿成一个客户端和服务器端的结合体,在 用户 -> 中间人 的过程中中间人模仿服务器的行为,这样能够拿到用户申请的明文,在 中间人 -> 服务器 的过程中中间人模仿客户端行为,这样能够拿到服务器响应的明文,以此来进行中间人攻打:

这一次通信再次被中间人截获,中间人本人也伪造了一对公私钥,并将公钥发送给用户以此来窃取客户端生成的 AES_KEY,在拿到AES_KEY 之后就能轻松的进行解密了。

中间人这样随心所欲,就没有方法制裁下吗,当然有啊,接下来咱们看看 HTTPS 是怎么解决通信平安问题的。

2. HTTPS 协定

2.1 HTTPS 简介

HTTPS 其实是 SSL+HTTP 的简称, 当然当初 SSL 根本曾经被 TLS 取代了,不过接下来咱们还是对立以 SSL 作为简称,SSL协定其实不止是利用在 HTTP 协定上,还在利用在各种应用层协定上,例如:FTPWebSocket

其实 SSL 协定大抵就和上一节 非对称加密 的性质一样,握手的过程中次要也是为了替换秘钥,而后再通信过程中应用 对称加密 进行通信,大略流程如下:

这里我只是画了个示意图,其实真正的 SSL 握手会比这个简单的多,然而性质还是差不多,而且咱们这里须要关注的重点在于 HTTPS 是如何避免中间人攻打的。

通过上图能够察看到,服务器是通过 SSL 证书来传递 公钥 ,客户端会对 SSL 证书进行验证,其中证书认证体系就是确保SSL 平安的要害,接下来咱们就来解说下CA 认证体系,看看它是如何避免中间人攻打的。

2.2 CA 认证体系

上一节咱们看到客户端须要对服务器返回的 SSL 证书进行校验,那么客户端是如何校验服务器 SSL 证书的安全性呢。

  • 权威认证机构

在 CA 认证体系中,所有的证书都是由权威机构来颁发,而权威机构的 CA 证书都是曾经在操作系统中内置的,咱们把这些证书称之为CA 根证书

  • 签发证书

咱们的应用服务器如果想要应用 SSL 的话,须要通过权威认证机构来签发 CA 证书,咱们将服务器生成的公钥和站点相干信息发送给CA 签发机构,再由CA 签发机构 通过服务器发送的相干信息用 CA 签发机构 进行加签,由此失去咱们应用服务器的证书,证书会对应的生成证书内容的 签名 ,并将该 签名 应用 CA 签发机构 的私钥进行加密失去 证书指纹,并且与下级证书生成关系链。

这里咱们把百度的证书下载下来看看:

能够看到百度是受信于 GlobalSign G2,同样的GlobalSign G2 是受信于 GlobalSign R1,当客户端(浏览器) 做证书校验时,会一级一级的向上做查看,直到最初的 根证书 ,如果没有问题阐明 服务器证书 是能够被信赖的。

  • 如何验证服务器证书

那么客户端 (浏览器) 又是如何对 服务器证书 做校验的呢,首先会通过层级关系找到下级证书,通过下级证书里的 公钥 来对服务器的 证书指纹 进行解密失去 签名 (sign1),再通过签名算法算出服务器证书的 签名 (sign2),通过比照sign1sign2,如果相等就阐明证书是没有被 篡改 也不是 伪造 的。

这里乏味的是,证书校验用的 RSA 是通过私钥加密证书签名,公钥解密来奇妙的验证证书有效性。

这样通过证书的认证体系,咱们就能够防止了中间人窃取 AES_KEY 从而发动拦挡和批改 HTTP 通信的报文。

总结

首先先通过对 HTTP 中间人攻打的来理解到 HTTP 为什么是不平安的,而后再从平安攻防的技术演变始终到 HTTPS 的原理概括,心愿能让大家对 HTTPS 有个更粗浅的理解。

近期热文举荐:

1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)

2. 劲爆!Java 协程要来了。。。

3.Spring Boot 2.x 教程,太全了!

4. 别再写满屏的爆爆爆炸类了,试试装璜器模式,这才是优雅的形式!!

5.《Java 开发手册(嵩山版)》最新公布,速速下载!

感觉不错,别忘了顺手点赞 + 转发哦!

正文完
 0