HTTPSが安全である理由

出典：r6a.cn/efZ2

1. HTTPプロトコル

HTTPSプロトコルについて説明する前に、HTTPプロトコルの概念を確認しましょう。

1.1 HTTPプロトコルの概要

HTTPプロトコルは、OSIネットワークモデルにあるテキストベースの送信プロトコルです应用层。

HTTPプロトコルは、クライアントとサーバーの要求と応答を介して通信します。現在のプロトコルは、以前のRFC 2616から6つの個別のプロトコル記述（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プロトコルのメッセージは暗号化されずにプレーンテキストで送信されることがわかっていますが、これによりどのような問題が発生しますか？次に例を示します。

Xiao MingがJAVA投稿バーに投稿します。コンテンツは我爱JAVA次のとおりです。
真ん中の男に襲われて内容は我爱PHP
小明はグループ（手動の犬の頭）にからかわれた

HTTP送信プロセスでは、仲介者がHTTP通信のすべての要求と応答の内容を確認および変更できるため、HTTPを使用することは非常に安全ではないことがわかります。

1.3中間者攻撃を防ぐ

現時点では、コンテンツがプレーンテキストである对称加密ため、仲介者がプレーンテキストを表示できないようにメッセージを暗号化する方法を使用していると考える人もいるかもしれません。次のように変更しました。

両当事者は暗号化方法に同意します
AESを使用してメッセージを暗号化する

仲介者は平文情報を取得できないようですが、実際には暗号化方式と秘密鍵が通信処理中に平文で公開されます。最初の通信が傍受されると秘密鍵が仲介者に漏洩し、仲介者は依然としてその後の通信は復号化できます：

したがって、この場合、秘密鍵を暗号化して仲介者がそれを見るのを防ぐことができるかどうかを確実に検討しますか？答えはyesです非对称加密。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协议上，还在应用在各种应用层协议上，例如：FTP、WebSocket。

其实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)。sign1そして、sign2それらが等しい場合、それは証明書がカバーされていないことを意味篡改か伪造。

ここで興味深いのは、証明書の検証に使用されるRSAが、秘密キーを使用して証明書の署名を暗号化し、公開キーを解読して証明書の有効性を巧みに検証することです。

このように、証明書認証システムを介して、仲介者による盗難を回避してAES_KEY、HTTP通信メッセージの傍受と変更を開始できます。

総括する

まず、HTTPが中間者攻撃によって安全でない理由を最初に理解し、次にセキュリティ攻撃と防御技術の進化からHTTPSの原理に至るまで、誰もがHTTPSをより深く理解できることを願っています。

方法はありませんが、テクニックは達成できます。方法がない場合は、テクニックで終わります

みんながJava Wayパブリックアカウントをフォローすることを歓迎します

良い記事、私は読んでいます❤️