HTTPS (Hypertext Transfer Protocol over Secure Socket Layer、Hypertext Transfer Protocol based on Secure Socket Layer) は、セキュリティを目的とした HTTP チャネルであり、簡単に言えば、HTTP の安全なバージョンです。つまり、HTTP に SSL 層が追加されており、HTTPS のセキュリティ基盤は SSL であり、SSL 証明書によってサーバーの身元が検証され、ブラウザとサーバー間の通信が暗号化されます。使用されるポート番号は 443 です。
SSLとTLS
SSL: SSL (Secure Socket Layer) は、Netscape によって主に Web 用に設計された安全な伝送プロトコルです。このプロトコルは WEB で広く使用されています。証明書認証により、クライアントと Web サイト サーバー間の通信データが暗号化され、安全であることが保証されます。
SSL プロトコルは、TCP/IP プロトコルとさまざまなアプリケーション層プロトコルの間に位置し、データ通信のセキュリティ サポートを提供します。SSL プロトコルは 2 つの層に分けることができます。 SSL レコード プロトコル: 信頼性の高い伝送プロトコル (TCP など) に基づいて構築され、データのカプセル化、圧縮、高レベル プロトコルの暗号化などの基本機能のサポートを提供します。SSL ハンドシェイク プロトコル: SSL レコード プロトコルに基づいて構築されており、実際のデータ送信が開始される前に、通信当事者が ID を認証し、暗号化アルゴリズムをネゴシエートし、暗号化キーを交換するために使用されます。
TLS: TLS (トランスポート層セキュリティ、トランスポート層セキュリティ プロトコル) は、2 つのアプリケーション間の機密性とデータの整合性を提供するために使用されます。
SSL が v3 に開発されたとき、それ自体が非常に優れた安全な通信プロトコルであることが証明されたため、インターネット エンジニアリング グループ IETF は 1999 年にこれを TLS (Transport Layer Security) と改名し、正式に標準化し、バージョン番号も 1.0 から変更されました。 , したがって、TLS1.0 は実際には SSLv3.1 です。TLS 1.0 は、IETF (Internet Engineering Task Force、インターネット エンジニアリング タスク フォース) によって開発された新しいプロトコルです。SSL 3.0 プロトコル仕様に基づいており、SSL 3.0 の後継バージョンです。SSL 3.1 (または単に、同じものの異なる段階での異なる名前として理解されます)。このプロトコルは、TLS レコードと TLS ハンドシェイクの 2 つの層で構成されます。下位層は TLS レコード プロトコルで、信頼性の高いトランスポート プロトコル (TCP など) の上に位置します。TLS の主な目標は、SSL をより安全にし、プロトコルの仕様をより正確かつ完全なものにすることです。
TLS は、2006 年に 1.1、2008 年に 1.2、2018 年に 1.3 の 3 つのバージョンを開発しました。新しいバージョンはそれぞれ、暗号化の発展とインターネットの現状を厳密に追跡し、セキュリティとパフォーマンスを継続的に強化し、情報セキュリティの分野で権威ある標準となっています。
現在最も広く使用されている TLS は 1.2 で、以前のプロトコル (TLS1.1/1.0、SSLv3/v2) は安全ではないと考えられています。
HTTPS を使用する理由
HTTPS プロトコルは、主に HTTP プロトコルのセキュリティ問題を解決するものであり、HTTP プロトコルを使用して通信を行うことには、
(1) 通信リンク上で通信内容が取得され、ユーザーの情報が盗まれるなどの盗聴リスクがあります。アカウント。
(2) スパム広告の強制設置などの改ざんにより、視覚的汚染を引き起こす危険性。
(3) 他人になりすまして購入するなど、ユーザーが損失を被るなどのなりすましリスク。
HTTPSの原則
HTTPS は、アプリケーション層とネットワーク層で SSL/TSL を補完します。HTTP リクエスト/レスポンスは一般に 6 つのステップに分けることができます: (1) TCP 接続を確立する; (2) HTTP リクエストを送信する; (3) サーバーがリクエストを処理する; (4) HTTP レスポンスを返す; (5) HTTP リクエストを解放するTCP 接続; (6) ブラウザは返されたリソースとデータを解析します。しかし、HTTPSではTCP接続確立完了後にSSL接続確立処理が追加され、安全な接続を確立した上でHTTPリクエスト等が送信されます。次に、SSL (ここでは TLS 1.2) 経由で接続を確立するプロセスに焦点を当てます。
(1) TCP 接続が確立された後、ブラウザはまず「Client Hello」メッセージを送信し、サーバーに「挨拶」します。これには、クライアントのバージョン番号、サポートされている暗号スイート、およびその後のセッション キーの生成のための乱数 (クライアント ランダム) プレーン テキストが含まれています。
(2) サーバーは「Client Hello」を受信すると、「Server Hello」メッセージを返します。バージョン番号を確認し、平文の乱数（Server Random）を与え、この通信に使用する暗号スイート（ECDHEアルゴリズムなど）として、クライアントから提供された暗号スイートリストから暗号スイートを選択します。同時に、サーバーは自分の身元を証明するために、証明書 (サーバー証明書) をクライアントに送信します。サーバーは暗号スイートを選択しているため、証明書の後に「サーバー キー交換」メッセージを送信します。このメッセージには、キー交換アルゴリズムを実装するための公開キー (サーバー パラメーター) と独自の秘密キー署名認証が含まれています。
これに「Server Hello Done」メッセージが続きます。これは、「挨拶が完了した」ことを意味します。これで最初のメッセージの往復 (2 つの TCP パケット) が完了し、その結果、クライアントとサーバーは、クライアント ランダム、サーバー ランダム、およびサーバー パラメータという 3 つの情報をクリア テキストで共有することになります。
(3) ブラウザはサーバーの証明書を取得した後、証明書の信頼性の確認を開始し、証明書の公開キーを使用して署名を検証します。サーバーの ID を確認した後、ブラウザーは選択された暗号スイートに基づいて公開キー (Client Params) を生成し、それを「クライアント キー交換」メッセージを使用してサーバーに送信します。これで、ブラウザとサーバーは鍵交換アルゴリズムの 2 つのパラメーター (クライアント パラメーター、サーバー パラメーター) を持ち、暗号スイート アルゴリズムを使用して「プレマスター」を計算します。これで、ブラウザとサーバーには、クライアント ランダム、サーバー ランダム、プレマスターという 3 つの乱数が与えられます。これら 3 つを原材料として使用すると、「マスター シークレット」と呼ばれる、セッションの暗号化に使用されるマスター キーを生成できます。そして、ハッカーは「プレマスター」を取得できないため、マスターキーを取得できません。
クライアントランダム、サーバーランダム、プレマスターという 3 つの乱数が必要なのはなぜですか? これは主に、TLS プロトコルがブラウザやサーバーの擬似乱数の信頼性を信頼していないためであり、真に「完全にランダム」かつ「予測不能」であることを保証するために、信頼性の低い 3 つの乱数を混合するため、「ランダム」になっています。レベルが高く、安全性がより保証されます。
マスター キーと、マスター キーに基づいて導出されたセッション シークレットがあれば、ハンドシェイクはほぼ終了します。ブラウザは「暗号仕様の変更」メッセージを送信し、次に「完了」メッセージを送信して、以前に送信されたすべてのデータをダイジェストして暗号化し、サーバーに検証させます。
(4) ブラウザの検証要求を受信した後、サーバーは同じ手順に従い、それぞれ「暗号仕様の変更」および「完了」メッセージを送信します。
(5) 上記の操作が完了すると、TSL 接続が確立され、次のステップでは HTTP リクエストとレスポンスを暗号化して送信します。
証明書を使用する理由
簡単に言えば、証明書 + デジタル署名方式は、証明書の内容が改ざんされていないことを保証し、「中間者攻撃」を防ぐことができます。これは、サーバーの ID を検証する方法をブラウザーに指示するのと同じです。 、一方向認証。
一方向認証と双方向認証
一方向認証とは、クライアントがサーバーを認証する必要があることを意味します。
双方向認証と一方向認証の原理は基本的に同じですが、主な違いは、クライアントがサーバーを認証する必要があることに加えて、サーバーもクライアントを認証する必要があることです。どのようなシナリオでクライアントを確認する必要がありますか? たとえば、一部の銀行サービスでは、銀行が顧客に発行した USB シールドをコンピュータに挿入するか、何らかの制御をインストールすることを要求しますが、これはクライアント証明書の概念に似ており、この証明書がない人は提供されるサービスを利用できません。銀行のそばで。
HTTPS リクエストを行うたびに、SSL/TLS レイヤーでハンドシェイクを実行してキーを転送する必要がありますか?
リクエストごとにキーの送信プロセスを実行するのは非常に時間がかかるため、送信を 1 回だけ実現するにはどうすればよいでしょうか? サーバーは各ブラウザのセッション ID を維持し、TLS ハンドシェイク フェーズ中にそれをブラウザに渡します。ブラウザがキーを生成してサーバーに渡した後、サーバーは対応するセッション ID の下にキーを保存します。その後、ブラウザは各リクエストにセッション ID を伝え、サーバーはセッション ID に基づいて対応するキーを見つけて復号化および暗号化操作を実行します。そのため、毎回キーを作成して送信する必要はありません。
HTTPS は対称暗号化と非対称暗号化のどちらを使用しますか?
この質問に答えるには、HTTPS の原則を確認する必要があります。HTTPS の原則については上記を参照してください。
HTTPS の原理を紹介すると、HTTPS は非対称暗号化を使用して対称キーを送信し、サーバーとブラウザーの両方がそれを認識できることがわかります。その後、双方がこの対称キーを使用して、送受信データの暗号化と復号化を行います。送信鍵Ｋは非対称暗号化を採用しているため、解読されにくく安全性が高い。特定の送信データは対称暗号化を使用して送信を高速化します。両方の長所。
クラウド サービスが HTTPS を実装する方法
クラウド サービスの場合、すべてのマイクロサービスに HTTPS を実装する必要はありませんが、インターネット上には Spring Boot への HTTPS の実装に関する多くの記事もありますが、これは誤解を招きます。クラウド サービスの場合、サービスの入り口でのみ実装する必要があり、一般的な実装シナリオは 2 つあり、1 つは静的リソース指向の CDN、もう 1 つはサービス指向の LB です。もちろん、ファイアウォールなどの他の状況も含まれる場合があります。詳細については、次の 2 つの WIKI を参照してください。 1 つの記事は、Alibaba CloudおよびTencent Cloud のフルサイト HTTPS ソリューションでの HTTPS 構成を理解するのに役立ちます。開発者とアーキテクトは、HTTPS の原理を理解するだけで済みます。HTTPS を実装する必要がある場合は、既存の設計に従って対応するコンポーネントに HTTPS 構成を実装します。この構成は通常、クラウド プラットフォームに依存します。
HTTPS の欠点
HTTPS プロトコルには次の欠点があります。
(1) HTTPS プロトコルには複数のハンドシェイクがあり、ページの読み込み時間が 50% 近く長くなります。
(2) HTTPS 接続のキャッシュは HTTP ほど効率的ではないため、データのオーバーヘッドと電力消費が増加します。
(3) SSL 証明書の申請には費用がかかり、強力な証明書ほど費用も高くなります。
(4) SSL に含まれるセキュリティ アルゴリズムは CPU リソースを消費し、大量のサーバー リソースを消費します。
HTTPとHTTPSの違い
HTTP はハイパーテキスト転送プロトコルであり、情報はクリア テキストで送信されるため、セキュリティ リスクが生じます。HTTPS は、HTTP のセキュリティ上の欠点を解決し、TCP と HTTP ネットワーク層の間に SSL/TLS セキュリティ プロトコルを追加して、メッセージを暗号化して送信できるようにします。
HTTP 接続の確立は比較的簡単で、TCP スリーウェイ ハンドシェイク後に HTTP メッセージの送信を実行できます。TCP の 3 ウェイ ハンドシェイクの後、HTTPS は暗号化されたメッセージの送信を開始する前に、SSL/TLS ハンドシェイク プロセスを実行する必要があります。
HTTPのポート番号は80、HTTPSのポート番号は443です。
HTTPS プロトコルでは、サーバーの ID が信頼できるものであることを確認するために、CA (認証局) からのデジタル証明書を申請する必要があります。
参考
https://blog.csdn.net/hguisu/article/details/8680808 HTTPS 実装原則
https://zhuanlan.zhihu.com/p/466239718面接の要点: コンピューター ネットワークでよく聞かれる 62 の質問
https://zhuanlan .zhihu.com/p/27395037 HTTPS シリーズの辛口情報 (1): HTTPS 原理の詳細な説明
https://www.zhihu.com/tardis/zm/art/72616216 HTTP および HTTPS プロトコルを 10 分で理解するには?
https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3
https://developer.mozilla.org/zh-CN/docs/Web/Security/Transport_Layer_Securityトランスポート層セキュリティ
https://www.cnblogs.com /huansky /p/13977181.html HTTPS を簡単に理解する (詳細版)
https://zhuanlan.zhihu.com/p/43789231 HTTPS の暗号化原理を徹底的に理解する
https://zhuanlan.zhihu.com/p/96494976 HTTPS は対称暗号化と非対称暗号化のどちらを使用しますか?
https://www.jianshu.com/p/918d9f517749 https の対称暗号化と非対称暗号化
https://zhuanlan.zhihu.com/p/162082184対称または非対称 - https では何が使用されますか?
https://cloud.tencent.com/document/product/400/6813Tencent Cloud がフルサイト HTTPS ソリューションを実装
https://help.aliyun.com/practice_detail/444367この記事は、Alibaba Cloud の HTTPS 構成を理解するのに役立ちます