Network-security-transport-layer
ネットワークセキュリティ-トランスポート層
ネットワークセキュリティでは、データがネットワーク上で転送されている間、攻撃からデータを保護する必要があります。 この目標を達成するために、多くのリアルタイムセキュリティプロトコルが設計されています。 S/MIME、SSL/TLS、SSH、IPsecなどのリアルタイムネットワークセキュリティプロトコルには一般的な標準があります。 前述のように、これらのプロトコルはネットワークモデルのさまざまな層で機能します。
前の章では、アプリケーション層のセキュリティを提供するように設計されたいくつかの一般的なプロトコルについて説明しました。 この章では、トランスポート層および関連するセキュリティプロトコルでネットワークセキュリティを実現するプロセスについて説明します。
TCP/IPプロトコルベースのネットワークの場合、物理層とデータリンク層は通常、ユーザー端末とネットワークカードハードウェアに実装されます。 TCPおよびIP層は、オペレーティングシステムに実装されています。 TCP/IPを超えるものはすべて、ユーザープロセスとして実装されます。
トランスポート層セキュリティの必要性
典型的なインターネットベースのビジネストランザクションについて説明しましょう。
ボブは商品を販売するためにアリスのウェブサイトにアクセスします。 ウェブサイトのフォームに、ボブは希望する商品と数量のタイプ、住所と支払いカードの詳細を入力します。 ボブは[送信]をクリックして、アカウントから価格金額を引き落とす商品の配達を待ちます。 これはすべて良いことのように聞こえますが、ネットワークセキュリティがない場合、ボブはいくつかの驚きに直面する可能性があります。
- 取引で機密性（暗号化）が使用されていない場合、攻撃者は支払いカード情報を入手する可能性があります。 その後、攻撃者はボブの費用で購入することができます。
- データの整合性の尺度が使用されていない場合、攻撃者は商品の種類または数量に関してボブの注文を変更する可能性があります。
- 最後に、サーバー認証を使用しない場合、サーバーはアリスの有名なロゴを表示できますが、サイトはアリスを装った攻撃者によって維持されている悪意のあるサイトである可能性があります。 ボブの注文を受けた後、彼はボブのお金を取って逃げることができました。 または、ボブの名前とクレジットカードの詳細を収集して、個人情報の盗難を行うこともできます。
トランスポートレイヤーセキュリティスキームは、TCP/IPベースのネットワーク通信を機密性、データ整合性、サーバー認証、クライアント認証で強化することにより、これらの問題に対処できます。
このレイヤーのセキュリティは、主にネットワーク上のHTTPベースのWebトランザクションを保護するために使用されます。 ただし、TCP上で実行される任意のアプリケーションで使用できます。
TLS設計の哲学
トランスポート層セキュリティ（TLS）プロトコルは、TCP層の上で動作します。 これらのプロトコルの設計では、TCP層とのインターフェース用の「ソケット」と呼ばれる、TCPに対する一般的なアプリケーションプログラムインターフェイス（API）を使用します。
アプリケーションは、TCPではなくTransport Security Layerに直接インターフェースされます。 Transport Security Layerは、TCPのAPIに類似した類似のソケットを備えたシンプルなAPIを提供します。
上の図では、TLSは技術的にアプリケーション層とトランスポート層の間に存在しますが、共通の観点から見ると、TLSはセキュリティサービスで強化されたTCP層として機能するトランスポートプロトコルです。
TLSは、「タイミングアウト」や「失われたデータの再送信」を心配する必要がないため、TLS（UDPプロトコル上ではない）の信頼できるレイヤー4プロトコル上で動作するように設計されており、TLSの設計をより簡単にします。 TCP層は、TLSの必要性に応える通常の処理を続けます。
TLSが人気がある理由
トランスポート層でセキュリティを使用することの人気の理由は、単純さです。 この層でのセキュリティの設計と展開では、オペレーティングシステムに実装されているTCP/IPプロトコルを変更する必要はありません。 ユーザープロセスとアプリケーションのみを設計/修正する必要があり、複雑さは軽減されます。
セキュアソケットレイヤー（SSL）
このセクションでは、TLS用に設計されたプロトコルファミリについて説明します。 このファミリには、SSLバージョン2および3とTLSプロトコルが含まれています。 SSLv2はSSLv3に置き換えられたため、SSL v3とTLSに焦点を当てます。
SSLの簡単な歴史
1995年、NetscapeはSSLv2を開発し、Netscape Navigator 1.1で使用しました。 SSLバージョン1が発行されて使用されたことはありません。 その後、MicrosoftはSSLv2を改良し、Private Communications Technology（PCT）という別の同様のプロトコルを導入しました。
Netscapeは、さまざまなセキュリティ問題に関するSSLv2を大幅に改善し、1999年にSSLv3を展開しました。 その後、インターネット技術特別調査委員会（IETF）は、同様のTLS（トランスポート層セキュリティ）プロトコルをオープンスタンダードとして導入しました。 TLSプロトコルはSSLv3と相互運用できません。
TLSは、キーの拡張と認証のための暗号化アルゴリズムを変更しました。 また、TLSは、SSLで使用されている特許取得済みのRSA暗号の代わりに、オープン暗号Diffie-Hellman（DH）およびデジタル署名標準（DSS）の使用を提案しました。 しかし、2000年にRSA特許が失効したため、ユーザーが広く導入されているSSLv3からTLSに移行する強い理由はありませんでした。
SSLの顕著な特徴
SSLプロトコルの顕著な特徴は次のとおりです-
- SSLは、ネットワーク接続のセキュリティを提供します-
- 機密性-情報は暗号化された形式で交換されます。
- 認証-通信エンティティは、デジタル証明書を使用して互いに識別します。 Webサーバー認証は必須ですが、クライアント認証はオプションです。
- 信頼性-メッセージの整合性チェックを維持します。
- SSLはすべてのTCPアプリケーションで使用できます。
- ほとんどすべてのWebブラウザーでサポートされています。
- 新しいオンラインエンティティとのビジネスを容易にします。
- 主にWeb eコマース向けに開発されました。
SSLのアーキテクチャ
SSLはTCPに固有であり、UDPでは機能しません。 SSLは、アプリケーションにApplication Programming Interface（API）を提供します。 CおよびJava SSLライブラリ/クラスはすぐに利用できます。
SSLプロトコルは、次の図に示すように、アプリケーションとトランスポート層の間で相互作用するように設計されています-
SSL自体は、画像に示されているような単一層のプロトコルではありません。実際、2つのサブレイヤーで構成されています。
- 下位サブレイヤーは、SSLレコードプロトコルと呼ばれるSSLプロトコルの1つのコンポーネントで構成されます。 このコンポーネントは、整合性と機密性のサービスを提供します。
- 上位サブレイヤーは、3つのSSL関連プロトコルコンポーネントとアプリケーションプロトコルで構成されます。 アプリケーションコンポーネントは、クライアント/サーバーインタラクション間の情報転送サービスを提供します。 技術的には、SSLレイヤーの上でも動作します。 3つのSSL関連のプロトコルコンポーネントは-
- SSLハンドシェイクプロトコル
- 暗号仕様プロトコルの変更
- アラートプロトコル。
- これらの3つのプロトコルは、すべてのSSLメッセージ交換を管理し、このセクションで後述します。
SSLプロトコルコンポーネントの機能
SSLプロトコルの4つのサブコンポーネントは、クライアントマシンとサーバー間の安全な通信のためのさまざまなタスクを処理します。
- 記録プロトコル
- レコード層は、上位層のプロトコルメッセージをフォーマットします。
- データを管理可能なブロックに分割します（最大長16 KB）。 オプションでデータを圧縮します。
- データを暗号化します。
- 各メッセージのヘッダーと最後にハッシュ（メッセージ認証コード（MAC））を提供します。
- 転送のために、フォーマットされたブロックをTCP層に引き渡します。
- SSLハンドシェイクプロトコル
- SSLの最も複雑な部分です。 アプリケーションデータが送信される前に呼び出されます。 クライアントとサーバーの間にSSLセッションを作成します。
- セッションの確立には、サーバー認証、キーとアルゴリズムのネゴシエーション、キーの確立とクライアント認証が含まれます（オプション）。
- セッションは、暗号化セキュリティパラメータの一意のセットによって識別されます。
- クライアントとサーバー間の複数の安全なTCP接続は、同じセッションを共有できます。
- 4段階のハンドシェイクプロトコルアクション。 これらについては、次のセクションで説明します。
- ChangeCipherSpecプロトコル
- SSLプロトコルの最も単純な部分。 これは、クライアントとサーバーという2つの通信エンティティ間で交換される単一のメッセージで構成されます。
- 各エンティティはChangeCipherSpecメッセージを送信すると、合意されたとおりに接続の側を安全な状態に変更します。
- 暗号パラメータの保留状態が現在の状態にコピーされます。
- このメッセージの交換は、将来のデータ交換がすべて暗号化され、整合性が保護されていることを示します。
- SSLアラートプロトコル
- このプロトコルは、予期しないメッセージ、不良レコードMAC、セキュリティパラメータネゴシエーションの失敗などのエラーを報告するために使用されます。
- また、TCP接続の終了を通知する、不良または未知の証明書の受信を通知するなど、他の目的にも使用されます。
SSLセッションの確立
前述のように、SSLセッションの確立には4つのフェーズがあります。 これらは主にSSLハンドシェイクプロトコルによって処理されます。
- フェーズ1 *-セキュリティ機能の確立。
- このフェーズは、_Client_hello_と_Server_hello_の2つのメッセージの交換で構成されます。
- _Client_hello_には、クライアントがサポートする暗号化アルゴリズムのリストが含まれており、優先度の高い順に並んでいます。
- _Server_hello_には、選択した暗号仕様（CipherSpec）と新しい_session_id_が含まれます。
- CipherSpecには次のようなフィールドが含まれます-
- 暗号アルゴリズム（DES、3DES、RC2、およびRC4）
- MACアルゴリズム（MD5、SHA-1に基づく）
- 公開鍵アルゴリズム（RSA）
- 両方のメッセージには、リプレイ攻撃を防ぐための「ノンス」があります。
- フェーズ2 *-サーバー認証とキー交換。
- サーバーは証明書を送信します。 クライアントソフトウェアには、証明書を確認するためのさまざまな「信頼できる」組織（CA）の公開キーが設定されています。
- サーバーは選択された暗号スイートを送信します。
- サーバーがクライアント証明書を要求する場合があります。 通常は行われません。
- サーバーは_Server_hello_の終わりを示します。
- フェーズ3 *-クライアント認証とキー交換。
- クライアントは、サーバーから要求された場合にのみ証明書を送信します。
- また、サーバーの公開キーで暗号化されたプリマスターシークレット（PMS）も送信します。
- クライアントは、この証明書に関連付けられた秘密キーを持っていることを証明するために証明書が送信された場合、_Certificate_verify_メッセージも送信します。 基本的に、クライアントは前のメッセージのハッシュに署名します。
- フェーズ4 *-終了。
- クライアントとサーバーは_Change_cipher_spec_メッセージを相互に送信して、保留中の暗号状態を現在の状態にコピーします。
- これ以降、すべてのデータは暗号化され、整合性が保護されます。
- 各端からの「完了」メッセージは、キー交換と認証プロセスが成功したことを確認します。
上記で説明した4つのフェーズはすべて、TCPセッションの確立中に発生します。 SSLセッションの確立は、TCP SYN/SYNACKの後に始まり、TCP Finの前に終わります。
切断されたセッションの再開
- クライアントが暗号化された_session_id_情報とともに_hello_request_をサーバーに送信すると、（_ Alert_メッセージを介して）切断されたセッションを再開することができます。
- サーバーは、_session_id_が有効かどうかを判断します。 検証されると、クライアントとChangeCipherSpecおよび_finished_メッセージを交換し、安全な通信を再開します。
- これにより、セッション暗号パラメータの再計算が回避され、サーバーとクライアント側での計算が節約されます。
SSLセッションキー
SSLセッションの確立のフェーズ3では、プリマスターシークレットがクライアントからサーバーの公開キーを使用して暗号化されたサーバーに送信されることがわかりました。 マスターシークレットとさまざまなセッションキーは次のように生成されます-
- マスターシークレットは（擬似乱数ジェネレーターを介して）を使用して生成されます-
- プリマスターシークレット。
- client_helloおよびserver_helloメッセージで交換された2つのノンス（RAおよびRB）。
- 次に、このマスターシークレットから6つのシークレット値が導出されます-
- MACで使用される秘密鍵（サーバーから送信されるデータ用）
- MACで使用される秘密鍵（クライアントから送信されるデータ用）
- 暗号化に使用される秘密鍵とIV（サーバーによる）
- 暗号化に使用される秘密鍵とIV（クライアントによる）
TLSプロトコル
SSLのオープンインターネット標準を提供するために、IETFは1999年1月にトランスポート層セキュリティ（TLS）プロトコルをリリースしました。 TLSは、RFC 5246で提案されているインターネット標準として定義されています。
顕著な特徴
- TLSプロトコルには、SSLと同じ目的があります。
- クライアント/サーバーアプリケーションは、認証、盗聴の防止、メッセージの変更への抵抗により、安全な方法で通信できます。
- TLSプロトコルは、ネットワーキングレイヤースタック内の信頼性の高い接続指向トランスポートTCPレイヤーの上にあります。
- TLSプロトコルのアーキテクチャは、SSLv3プロトコルに似ています。 TLS RecordプロトコルとTLS Handshakeプロトコルの2つのサブプロトコルがあります。
- SSLv3とTLSプロトコルのアーキテクチャは類似していますが、特にハンドシェイクプロトコルのアーキテクチャと機能にいくつかの変更が加えられました。
TLSプロトコルとSSLプロトコルの比較
TLSプロトコルとSSLv3プロトコルには、主に8つの違いがあります。 これらは次のとおりです-
- プロトコルバージョン-TLSプロトコルセグメントのヘッダーは、SSLプロトコルセグメントヘッダーによって運ばれる番号3を区別するためにバージョン番号3.1を運びます。
- メッセージ認証-TLSは、キー付きハッシュメッセージ認証コード（H-MAC）を使用します。 利点は、SSLプロトコルで明示的に述べられているように、MD5またはSHAだけでなく、H-MACが任意のハッシュ関数で動作することです。
- セッションキーの生成-キーマテリアルの生成には、TLSプロトコルとSSLプロトコルの間に2つの違いがあります。
- プリマスターおよびマスターシークレットの計算方法は似ています。 ただし、TLSプロトコルでは、マスターシークレットの計算では、アドホックMACの代わりにHMAC標準および擬似ランダム関数（PRF）出力が使用されます。
- セッションキーと開始値（IV）を計算するアルゴリズムは、TLSではSSLプロトコルと異なります。
- アラートプロトコルメッセージ-
- TLSプロトコルは、SSLのアラートプロトコルで使用されるすべてのメッセージをサポートしますが、「証明書なし」アラートメッセージは冗長化されます。 クライアント認証が不要な場合、クライアントは空の証明書を送信します。
- _record_overflow、decode_error_などの他のエラー条件のために、多くの追加のアラートメッセージがTLSプロトコルに含まれています。
- サポートされる暗号スイート-SSLはRSA、Diffie-Hellman、およびFortezza暗号スイートをサポートします。 TLSプロトコルは、Fortezzaを除くすべてのスーツをサポートします。
- クライアント証明書タイプ-TLSは、_certificate_request_メッセージで要求される証明書タイプを定義します。 SSLv3はこれらすべてをサポートしています。 さらに、SSLは、Fortezzaなどの他の特定の種類の証明書をサポートします。
- CertificateVerifyおよび終了したメッセージ-
- SSLでは、_certificate_verify_メッセージに複雑なメッセージプロシージャが使用されます。 TLSを使用すると、検証済みの情報がハンドシェイクメッセージ自体に含まれるため、この複雑な手順が回避されます。
- 終了したメッセージは、TLSとSSLv3でさまざまな方法で計算されます。
- データのパディング-SSLプロトコルでは、暗号化前にユーザーデータに追加されるパディングは、合計データサイズを暗号のブロック長の倍数にするために必要な最小量です。 TLSでは、パディングは、暗号のブロック長の倍数、最大255バイトまでのデータサイズになる任意の量にすることができます。
上記のTLSプロトコルとSSLv3プロトコルの違いを次の表にまとめます。
セキュアブラウジング-HTTPS
このセクションでは、安全なWebブラウジングを実行するためのSSL/TLSプロトコルの使用について説明します。
HTTPS定義
Webブラウジングには、ハイパーテキスト転送プロトコル（HTTP）プロトコルが使用されます。 HTTPSの機能はHTTPに似ています。 唯一の違いは、HTTPSが「安全な」Webブラウジングを提供することです。 HTTPSはHTTP over SSLの略です。 このプロトコルは、クライアントWebブラウザーとWebサイトサーバー間の暗号化および認証された接続を提供するために使用されます。
HTTPSを介した安全な閲覧により、次のコンテンツが暗号化されます-
- 要求されたWebページのURL。
- サーバーがユーザークライアントに提供するWebページコンテンツ。
- ユーザーが記入したフォームの内容。
- 双方向で確立されたCookie。
HTTPSの動作
HTTPSアプリケーションプロトコルは通常、2つの一般的なトランスポートレイヤーセキュリティプロトコルの1つ、SSLまたはTLSを使用します。 安全なブラウジングのプロセスは、次の点で説明されています。
- ブラウザのアドレスバーにhttps://の後にURLを入力して、WebページへのHTTPS接続を要求します。
- WebブラウザがWebサーバーへの接続を開始します。 httpsを使用すると、SSLプロトコルが使用されます。
- アプリケーション（この場合はブラウザー）は、ポート80（httpの場合に使用）の代わりにシステムポート443を使用します。
- SSLプロトコルは、前のセクションで説明したように、安全なセッションを確立するためにハンドシェイクプロトコルを通過します。
- Webサイトは最初にSSLデジタル証明書をブラウザに送信します。 証明書を検証すると、SSLハンドシェイクが進行して、セッションの共有秘密を交換します。
- 信頼されたSSLデジタル証明書がサーバーで使用されると、ユーザーはブラウザーのアドレスバーに南京錠のアイコンが表示されます。 拡張検証証明書がWebサイトにインストールされると、アドレスバーが緑色に変わります。
- 確立されると、このセッションは、Webサーバーとブラウザー間の多くの安全な接続で構成されます。
HTTPSの使用
- HTTPSを使用すると、ユーザーに機密性、サーバー認証、メッセージの整合性が提供されます。 インターネット上での電子商取引の安全な実施を可能にします。
- データが盗聴されるのを防ぎ、HTTPに対する一般的な攻撃である個人情報の盗難を拒否します。
現在のWebブラウザーとWebサーバーにはHTTPSサポートが装備されています。 ただし、HTTPS over HTTPを使用するには、暗号化とSSLハンドシェイクを実行するために、クライアントとサーバー側でより多くの計算能力が必要です。
セキュアシェルプロトコル（SSH）
SSHの顕著な特徴は次のとおりです-
- SSHは、TCP/IP層の上で実行されるネットワークプロトコルです。 リモートログオン機能の安全でない手段を提供するTELNETを置き換えるように設計されています。
- SSHは安全なクライアント/サーバー通信を提供し、ファイル転送や電子メールなどのタスクに使用できます。
- SSH2は、以前のバージョンのSSH1よりも改善されたネットワーク通信セキュリティを提供する一般的なプロトコルです。
SSH定義
SSHは3つのサブプロトコルとして構成されています。
- Transport Layer Protocol -SSHプロトコルのこの部分は、データの機密性、サーバー（ホスト）認証、およびデータの整合性を提供します。 オプションでデータ圧縮も提供できます。
- サーバー認証-ホストキーは公開/秘密キーのように非対称です。 サーバーは公開鍵を使用して、クライアントにその身元を証明します。 クライアントは、接続されたサーバーが、保持しているデータベースの「既知の」ホストであることを確認します。 サーバーが認証されると、セッションキーが生成されます。
- セッションキーの確立-認証後、サーバーとクライアントは使用する暗号について合意します。 セッションキーは、クライアントとサーバーの両方によって生成されます。 ユーザー名とパスワードを暗号化して送信できるように、ユーザー認証の前にセッションキーが生成されます。 これらのキーは通常、セッション中に定期的に（たとえば、1時間ごとに）交換され、使用後すぐに破棄されます。
- データの整合性-SSHはメッセージ認証コード（MAC）アルゴリズムを使用してデータの整合性をチェックします。 SSH1で使用される32ビットCRCよりも改善されています。
- ユーザー認証プロトコル-SSHのこの部分は、サーバーに対してユーザーを認証します。 サーバーは、アクセスが目的のユーザーのみに与えられていることを確認します。 現在、入力されたパスワード、Kerberos、公開鍵認証など、多くの認証方法が使用されています。
- 接続プロトコル-これは、単一の基盤となるSSH接続で複数の論理チャネルを提供します。
SSHサービス
SSHは、多くの安全なソリューションの提供を可能にする3つの主要なサービスを提供します。 これらのサービスは次のように簡単に説明されています-
- * Secure Command-Shell（リモートログオン）*-ユーザーは、ファイルを編集したり、ディレクトリの内容を表示したり、接続されたデバイス上のアプリケーションにアクセスしたりできます。 システム管理者は、サービスとプロセスをリモートで開始/表示/停止し、ユーザーアカウントを作成し、ファイル/ディレクトリのアクセス許可などを変更できます。 マシンのコマンドプロンプトで実行可能なすべてのタスクは、安全なリモートログオンを使用してリモートマシンから安全に実行できるようになりました。
- セキュアファイル転送-SSHファイル転送プロトコル（SFTP）は、セキュアファイル転送のためのSSH-2の拡張として設計されています。 本質的に、ファイル転送を処理するためにSecure Shellプロトコルの上に階層化された別個のプロトコルです。 SFTPは、ユーザー名/パスワードと転送されるファイルデータの両方を暗号化します。 Secure Shellサーバーと同じポート、つまり システムポート番号22。
- ポートフォワーディング（トンネリング）-保護されていないTCP/IPベースのアプリケーションからのデータを保護できます。 ポート転送が設定された後、Secure Shellはプログラム（通常はクライアント）からのトラフィックを再ルーティングし、暗号化されたトンネルを介して反対側のプログラム（通常はサーバー）に送信します。 複数のアプリケーションが単一の多重化された安全なチャネルでデータを送信できるため、ファイアウォールまたはルーターで多くのポートを開く必要がなくなります。
利点と制限
トランスポート層で通信セキュリティを採用する利点と制限は次のとおりです-
- 利点
- トランスポート層セキュリティは、アプリケーションに対して透過的です。
- サーバーが認証されます。
- アプリケーション層のヘッダーは非表示です。
- トランスポート接続レベルで機能するため、レイヤー3（IPsec）のセキュリティメカニズムよりもきめ細かいです。
- 制限事項
- TCPベースのアプリケーションにのみ適用可能（UDPではない）。
- TCP/IPヘッダーは明確です。
- クライアントとサーバー間の直接通信に適しています。 サーバーのチェーンを使用した安全なアプリケーションには対応していません（例： Eメール）
- クライアント認証はオプションであるため、SSLは否認防止を提供しません。
- 必要に応じて、SSLの上にクライアント認証を実装する必要があります。
概要
過去10年間に、インターネット上に多数のWebアプリケーションが登場しました。 多くの電子政府および電子商取引ポータルがオンラインになりました。 これらのアプリケーションでは、サーバーとクライアント間のセッションが安全であり、セッションの機密性、認証、および整合性が確保される必要があります。
ユーザーのセッション中に発生する可能性のある攻撃を軽減する1つの方法は、安全な通信プロトコルを使用することです。 この章では、このような通信プロトコルのうち2つ、SSL（Secure Sockets Layer）とTLS（Transport Layer Security）について説明します。 これらのプロトコルは両方ともトランスポート層で機能します。
TELNETを置き換えるように設計された別のトランスポート層プロトコルであるSecure Shell（SSH）は、リモートログオン機能の安全な手段を提供します。 Secure Command ShellやSFTPなどのさまざまなサービスを提供できます。
トランスポート層セキュリティの採用には多くの利点があります。 ただし、これらの層で設計されたセキュリティプロトコルはTCPでのみ使用できます。 UDPを使用して実装された通信のセキュリティは提供しません。
