ネットワークセキュリティプロトコル
設計され、受信者が送信者の身元を確認することができない、送信時の情報セキュリティを保証することはできません、アカウントのセキュリティ問題になりませんでしたTCP / IPプロトコルスイートは、受信した情報を決定することはできません元の情報と同じです。
したがって、リンク層、ネットワーク層とトランスポート層セキュリティのネットワークセキュリティ研究者は、すべてのレベルで所望の補助プロトコルに対応する開発、それぞれ、機密性、完全性および否認防止のセキュリティ目標。EAPと802.1Xプロトコルは、リンク層の送信者の認証に使用され、IPSecとSSLは、ネットワーク層であり、トランスポート層は、3つの基本的な目的のセキュリティを実現するために暗号化技術を用いて形成され、802.11iのプロトコルファミリは、WLANの暗号化を定義し、整合性の検出メカニズム。
SSLプロトコル
必要に応じてTCP / IP接続のためのプライバシ、整合性、サーバー認証、およびを提供するために、ソケットレイヤプロトコル(ソケットレイヤー、SSLセキュア)アプリケーション層プロトコルとTCP / IPプロトコル間のデータセキュリティを提供するためのメカニズムを指定し、セキュアクライアント認証は、主にWebサーバとブラウザ間の安全な通信のために使用されています。
SSLプロトコル・スタックの構成は次のとおりです。
SSLハンドシェイクプロトコル |
SSLパスワード変更プロトコル |
SSL警告プロトコル |
HTTP |
SSLレコードプロトコル |
|||
TCP |
|||
IP |
図組成物1-1 SSLプロトコルスタック
- SSLレコードプロトコルは、一般的にSSLレコードプロトコルの上に実装されたHTTP、アプリケーション層のプロトコルに基本的なセキュリティサービスを提供しています。
- SSLハンドシェイクプロトコルは、予め確立された安全なチャネルに接続された両方の、安全な接続を確立する前に、クライアントとサーバとの間で使用され、特定の暗号化アルゴリズムはお互いを識別することができます。
- 仕様プロトコル暗号SSL変化は、比較的単純なプロトコルは、現在の状態と現在のキーセットを設定するために、1つのバイトのメッセージの長さを含む、使用される、対応する暗号化ポリシーが設定されていることを示しています。
- データの暗号化または他の操作のためのアラートプロトコルSSLハンドシェイクプロトコルエラーが発生した場合、警報メッセージを他の当事者に送信されるか、現在の接続が終了され、それはデータ、即ち、アラームおよびアラームレベルの2つのバイトを有し、アラームレベル」が「警告」に分割され致命的な「2種類、アラームの致命的なタイプは、接続が直ちに終了される原因となります。
SSLレコードプロトコル
レコードは、二つの部分、すなわちヘッドと記録データで構成されています。
コンテンツの種類 |
メジャーバージョン番号 |
マイナーバージョン番号 |
データ長 |
|
圧縮されたデータ |
暗号化 |
|||
マック |
図1-2 SSLレコードプロトコルフォーマット
(1)コンテンツタイプ:このようなスペックプロトコル20暗号変化として8ビット、上位層プロトコルタイプ、プロトコル22は、ハンドシェイクプロトコルで、アラーム21です。
(2)プロトコルバージョン:16ビット、テーブル名SSLバージョン番号、上位8ビットは、メジャーバージョン番号、下位8ビットのマイナーバージョン番号です。
(3)データ長:圧縮された場合、それが圧縮された後に長さ。
SSLハンドシェイクプロトコル
データのタイプ(表1-1)、データ長(3バイト)とデータ内容:SSL SSLハンドシェイクプロトコルSSLレコードプロトコル処理の基礎である最も複雑なプロトコルネゴシエーションの結果であり、それは、3つの部分に分割されています(関連パラメータ・タイプ)。
両方の送信に先立ちとは、最初のプロトコルバージョン、暗号化アルゴリズム、関連キー、MACアルゴリズム、およびID認証など、様々なパラメータのハンドシェイクプロトコルのネゴシエーションを使用して、通信を受信、最後のクライアントは、サーバの公開とのプレマスターキーとして乱数を生成し、暗号化キーの後、サーバーに、その後、すべてのデータは、セキュリティを確保するために、セッション鍵を生成プレマスターキーは、キー交換アルゴリズムに従って、暗号化されて使用することができます。
データの種類 |
パラメータ |
hello_request |
ノー |
CLIENT_HELLO |
バージョン番号、ナンス、セッションID、パスワードのパラメータ、圧縮方法 |
server_hello |
|
証明書 |
X. 509 v3証明書チェーン |
server_key_exchange |
パラメータの署名 |
証明書要求 |
タイプ、CA |
server_hello_done |
ノー |
certificate_verify |
署名を検証します |
client_key_exchange |
パラメータの署名 |
完成 |
ハッシュコード |
フォームデータタイプとハンドシェイクプロトコルパラメータ1-1
ハンドシェイクプロセスは、次の3つのフェーズに分けられます。
1.ハロー段階
主な仕事は、バージョン番号、セッションID、暗号スイート、圧縮アルゴリズムと交換乱数を交渉することです。
(1)CLIENT_HELLO:クライアント初期化メッセージ、パラメータの設立の顧客サポートは、安全な通行を選択するためにサーバーに送信されました。
(2)server_hello:サーバはハンドシェイクが失敗した表現、または回答server_helloに答えることができCLIENT_HELLOアラームメッセージを受信すると、サーバはパラメータの組み合わせを選択することを決定し、サーバによって生成された新しい乱数を含め、クライアントに転送されます。
2.キー交渉段階
主な仕事は、サーバー証明書を送信することで、クライアント証明書の要求(オプション)は、顧客が必要な場合は証明書が送信されます。
(1)certificate:服务器发送自己的证书给客户,表明身份。客户检查证书的签名并获得服务器的公钥,随后使用该公钥加密随机产生的预主密钥。
(2)server_key_exchange:当hello阶段协商的算法仅仅使用certificate的信息无法进行密钥交换时,使用该报文发送密钥交换所必需的其他信息。
(3)server_hello_done:服务器表明server_hello结束,等待客户响应。
(4)client_key_exchange:客户用服务器的公钥加密一个随机生成的预主密钥,然后发送给服务器,服务器收到后,用自己的私钥解开,然后根据hello阶段协商的算法,各自计算主密钥,最后产生通信使用的会话密钥。
3. finished阶段
主要工作是改变密码组,完成握手。
(1)密码规范变更报文:表示记录协议的加密算法和认证方式的改变,随后将启用新的密钥。
(2)finished:双方互相验证收到的finished类型的报文是否正确无误,从而确定对方已经生成正确的会话密钥。此时握手协议完成,双方可以用新的会话密钥安全传输数据。
记一次SSL握手协议过程
图 1‑1 SSL协议握手过程
① 客户向服务器(www.baidu.com)发送Client Hello报文;
② 服务器向客户发送Server Hello报文,同时选择了14种参数中的一种参数;
③ 然后服务器通过Certificate报文和Server Key Exchange报文向客户发送服务器证书及其他密钥交换所必需的信息;
④ 发送完毕后用Server Hello Done报文表明Server Hello结束,等待客户响应;
⑤ 客户用Client Key Exchange报文发送用公钥加密的预主密钥;
⑥ 服务器发送密码规范变更报文和finished报文改变密码组,完成握手;
⑦ 至此,握手完成,可以注意到接下来的数据都是加密传输的。