scsfv.org

AESはTLS 1.0を定義するRFC 2246には含まれていませんが、RFC 3268で追加されました。また、個別のRFCで導入された暗号化アルゴリズムとして、Camellia（RFC 4132）、SEED（RFC 4162）があります。

共通鍵は、クライアントとサーバの双方から提供される乱数に基づいて決定されます。双方で生成した乱数を組み合わせて使用するため、リプレイ攻撃では同一の共通鍵を得ることはできません。共通鍵は4つセットで生成し、クライアントから送信するデータの暗号化用とサーバから送信するデータの暗号化用にひとつずつ割り当てられます（残り2つは後述するハッシュ値の生成に使われます）。

鍵の盗聴を防ぐ仕組みとして、サーバ証明書がRSA暗号を用いて署名されている場合は、クライアントから送る鍵情報の一部をサーバの公開鍵で暗号化することができます。サーバの秘密鍵を知らない部外者は、この情報を復号できません。あるいは（RSA暗号を使っていない場合などは）Diffie-Hellman鍵共有アルゴリズムを使うこともできます。

TLSの一般的な用途では、サーバだけが証明書を提示し、クライアントがその正当性を確認します。オプションでクライアント認証も可能であり、必要な場合にはサーバがクライアントに対して証明書の提示を求めます。

なりすましを防ぐために、証明書には認証局 (CA; Certification Authority) による電子署名が必要です。また、サーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができます。

この確認を行わない場合、攻撃者はサーバAの管理者でなくても、自分が管理するサーバBの正当な証明書を取得して、その証明書を使ってサーバAを名乗ることができてしまいます。

なお証明書には有効期限が設定されています。暗号理論およびコンピュータの計算能力は日々進歩しており、現在安全とみなされる技術であっても長年にわたって安全性を保てる保証はありません。また暗号技術の制約上、莫大な計算能力をつぎ込んで解読を続ければ、いつか暗号は解読されると考えるべきです。このため、一定期間ごとに証明書を再発行し、鍵を変更するとともに必要に応じて使用するアルゴリズムも更新しています。

TLSは、認証・暗号化・改竄検出の機能を提供します。具体的なアルゴリズムはそれぞれ複数の選択肢が定義されており、TLS通信の開始時に行われるネゴシエーション時に、双方が許容するアルゴリズムの中から選択されます。

選択肢によっては、攻撃への耐性の強度が大きく変化する場合もあります（極端な例だが、双方が同意すれば「暗号化なし」を選択することもできます）。

許容できない選択肢はあらかじめネゴシエーションの候補から外しておいたり、また望ましくないアルゴリズムが選択された場合はユーザーに警告したりといった対策が考えられます。一般に公開されている製品は、実際にこれらの対策が取られています。

なお、選択できるアルゴリズムはTLS/SSLのバージョンによって異なっています。また、暗号化、認証、改竄検出の3つをひとまとめにして選択肢が定義されており、しかも全ての組み合わせが網羅されているわけではないので、同時に利用できない組み合わせも存在しています。

ネットスケープコミュニケーションズ社はSSL 2.0の問題を修正するとともに機能追加を行い、1995年にSSL 3.0を発表しました。また、Netscape Navigator 2.0においてSSL 3.0を実装しました。

ネットスケープコミュニケーションズ社はSSL 1.0の問題を修正して再設計し、1994年にSSL 2.0として発表しました。また、同社のウェブブラウザであるNetscape Navigator 1.1においてSSL 2.0を実装しました。

その後、SSL 2.0にもいくつかの脆弱性が発見され、SSL 3.0において修正されました。SSL 2.0の脆弱性のひとつは、ネゴシエーションの情報を改竄すると、提示する選択肢のうち最弱のアルゴリズムを使わせることができ（ダウングレード攻撃）、改竄を受けたことを検出できないというものです。さらに悪いことに、この脆弱性を利用すると、双方がSSL 3.0をサポートしていてもSSL 2.0で接続させることさえ可能になります。

SSL 3.0ではSSL 2.0との互換性を提供するにあたり、乱数領域を使った細工を加えることで、このような攻撃を検出する仕組みを組み込みました。しかしこの細工が無効にされているサーバ環境も存在し、クライアントから見るとSSL 2.0を無効にしない限りこの脆弱性の影響を受ける可能性を否定できません。

SSL 3.0以降に対応した実装が十分に普及したものとして、Internet Explorer 7やMozilla Firefox 2、Opera 9などは、初期状態でSSL 2.0を無効にしています。この決定を受け、SSL 2.0しか対応していなかったサーバでも、SSL 3.0以降へ対応する動きが広まっています。
SSL2.0にはチェーン証明書がありません。 したがって、ルートCAから発行したSSLサーバ証明書しか使うことができません。

ネットスケープコミュニケーションズ社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな脆弱性が発見され、破棄されました。このため、SSL 1.0を実装した製品はありません。

Transport Layer Security（トランスポート・レイヤー・セキュリティー、TLS）は、セキュリティーを要求される通信のためのプロトコルです。

また、このプロトコルを発表したIETFの作業部会の名前でもあります。
歴史的な理由により、当プロトコルは、しばしば（特に区別する場合を除いて）Secure Sockets Layer (SSL) とも呼ばれています。これは、TLSの元になったプロトコルがSSLだったことと、SSLという名称が広く普及していることによります。以下においては、特にことわりのないかぎり、作業部会ではなく、プロトコルのほうを指しています。

TLSは、コネクション型のトランスポート層プロトコルの上位に位置し、通常はTCPをラップする形で利用されます。特にHTTPでの利用を意識して設計されているが、アプリケーション層の特定のプロトコルには依存していません。

WordPress へようこそ。これは最初の投稿です。編集もしくは削除してブログを始めてください !