hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
百獣戦隊ガオレンジャー 音楽
Quest 24・28・35・46ではインストゥルメンタル版が使用された。
「その翼で…」
作詞：吉野麻希 / 作曲・編曲：中川幸太郎 / 歌：山形ユキオ / コーラス：広谷順子
「絆 〜Spirit of Gao Ranger〜」（Quest 48）
作詞：磯谷佳江 / 作曲・編曲：中川幸太郎 / 歌：Salia & 山形ユキオ / コーラス：佐々木久美・高尾直樹
「EYES OF JUSTICE」（Quest 31・35・41・47）
作詞：加藤清美 / 作曲・編曲：中川幸太郎 / 歌：MoJo
ガオイカロスのテーマソング。
Quest 31ではインストゥルメンタル版と併用された。
上記の他、Quest 11でEvery Little Thingの「force of heart」、Quest 34で並木路子の「リンゴの唄」が使用された。また、Quest 12ではツエツエ、ヤバイバ、シュテンに化けたコピーオルグがモーニング娘。の「恋愛レボリューション21」の一部を歌っている。
百獣戦隊ガオレンジャー 評価
明快なストーリーとも相まって老若男女を問わず多くの視聴者に支持された本作品は、日曜の朝としては異例の2桁の視聴率をたたき出すほどの人気を獲得した。特に最高視聴率はテレビ朝日の同時間帯における最高記録を20年ぶりに塗り替えた。児童向けの番組でありながら、年齢層を問わない支持を集め、各種メディアなどで話題となった。
また放送終了後も根強い人気があり、2011年の『gooランキング』の『夢中になったスーパー戦隊シリーズは?』のアンケートでは、ランキング1位に輝いた。ガオブラックを演じた酒井一圭は2006年に「放送から数年を経た今でも街で子供たちやその親から声がかかる。その子たちはどう見ても本放送を見た世代じゃないし、しかも俺はレッドじゃなくてブラックなのに」とコメントしている。西川貴教や藤井隆が本作品のファンで、出演者を自分の番組にゲストとして招くなど芸能人にもファンが多い。
本作品の大ヒットに伴い、東映サイドに局側やスポンサーから翌年の続編制作の打診もなされていたものの、「続編を作るとマニアックな内容に変貌してしりすぼみになる可能性が高い」という理由から断ったことが、放送終了後の東映専務・鈴木武幸へのインタビューにより明らかとなっている。
百獣戦隊ガオレンジャー 放送日程
放送回のカウントは「Quest」の語句を使用。サブタイトルは一部を除き二文節で構成されている。
百獣戦隊ガオレンジャー 他媒体展開
個別に項目が存在するものは当該項目を参照。
『劇場版 百獣戦隊ガオレンジャー 火の山、吼える』
2001年9月22日公開。
『百獣戦隊ガオレンジャーVSスーパー戦隊』
2001年8月10日リリース。
『忍風戦隊ハリケンジャーVSガオレンジャー』
2003年3月21日リリース。
いずれも発売元は東映ビデオ。本作品より従来のVHSに加え、DVDも放送期間中にリリースが開始されるようになった。
ビデオ
テレビシリーズのVHS（セル・レンタル共通）は2002年1月から12月にかけて全12巻（各巻4話（10 - 12巻のみ5話）収録）がリリースされた他、放送期間中には「HEROクラブ」よりテレビシリーズの再編集版も全3巻がリリースされている。
DVD
2001年12月8日から2002年11月21日にかけて、全12巻（各巻4話（10 - 12巻のみ5話）収録）をリリース。レンタルは2001年10月12日より開始。
PlayStation専用ソフトとして2001年11月にバンダイより発売。プレイヤーキャラクターである等身大戦ではガオレッド、巨大戦ではガオキングなどの精霊王を操作し、他の仲間と協力しながらオルゲットやオルグ魔人と戦っていくアクションゲームで、等身大戦と巨大ロボ戦を組み合わせた構成となっている。テレビシリーズのキャラクターのほか、オリジナルのオルグ魔人・キングオルグも登場する。
百獣戦隊ガオレンジャー 他媒体展開
百獣戦隊ガオレンジャー スーパービデオ「対決!ガオレンジャーVSガオシルバー 炎のピヨちゃんたんじょう!」
講談社の児童誌『テレビマガジン』『たのしい幼稚園』『おともだち』の合同企画として応募者全員にプレゼントされたオリジナルビデオ。ガオズロックに現れたシルバー/月麿が、5人に五つの「ガオのおしえ」を問う。正解した褒美に炎のピヨちゃん（声：今野宏美）が誕生し、それをガオゴッドが「戦士のガオの心臓」に変えて6人に与える。
百獣戦隊ガオレンジャー ガオアクセスCD 「ガオパンダあらわる!!」
小学館の児童誌『てれびくん』2002年2月号同梱付録のオリジナルドラマCD。ある冬に、雪合戦をして遊んでいたガオレンジャーたちの前に現れた雪ダルマオルグ（声：松本大）の攻撃によりパワーアニマルたちが冬眠してしまったが、ガオパンダが現れガオレンジャーに加勢するというストーリーになっている。登場したオリジナルパワーアニマルのガオパンダは応募者当選品として実際に作られた。限定100個で、応募方法はガオレンジャーの絵を描いて送るというもの。脚本：赤星政尚。
百獣戦隊ガオレンジャーVS秘密戦隊ゴレンジャー
『てれコロコミック』2001年9月増刊号に掲載された読み切り漫画。作画を犬木栄治が担当した。『秘密戦隊ゴレンジャー』とのクロスオーバー。
百獣戦隊ガオレンジャー シリーズ内の他作品への登場
各作品における詳細はそれぞれの項目を参照。
スーパー戦隊大集合
『未来戦隊タイムレンジャー』第51話として放送された特別総集編。本作品の開始に先駆け、ガオレンジャーの初期メンバーが登場。
『轟轟戦隊ボウケンジャーVSスーパー戦隊』
『轟轟戦隊ボウケンジャー』のスーパー戦隊Vシネマ作品。ガオレッド（アカレッドが変身）およびツエツエが登場。
『海賊戦隊ゴーカイジャー』
関連する映画も含め、複数のキャラクターが同作品にて登場。
テレビシリーズ：獅子 走（第9話）、ガオライオン（第9話以降）
ゴーカイジャー ゴセイジャー スーパー戦隊199ヒーロー大決戦：ガオキング
海賊戦隊ゴーカイジャー THE MOVIE 空飛ぶ幽霊船：オルゲット
特命戦隊ゴーバスターズVS海賊戦隊ゴーカイジャー THE MOVIE：ゴーバスターライオーがレンジャーキーの力で変身した姿としてガオキングおよびガオケンタウロスが登場。
『4週連続スペシャル スーパー戦隊最強バトル!!』
獅子走 /ガオレッドが出演。他の5人も、変身後の姿のみ登場。
『機界戦隊ゼンカイジャー THE MOVIE 赤い戦い! オール戦隊大集会!!』
『機界戦隊ゼンカイジャー』の劇場作品。ガオレッドが登場。
聖マリアンナ医科大学
聖マリアンナ医科大学（せいマリアンナいかだいがく、英語: St. Marianna University School of Medicine）は、神奈川県川崎市宮前区菅生2-16-1に本部を置く日本の私立大学。1971年創立、1971年大学設置。大学の略称は聖マリ、聖医大、聖マリ医大（内部では「マリアンナ」又は「聖マリ」と略す傾向が強い）。
聖マリアンナ医科大学 概観
聖マリアンナ医科大学は、神奈川県川崎市宮前区に、カトリック系の財団法人聖マリアンナ会東横病院を母体として、1971年明石嘉聞博士によって東洋医科大学の名で創立された。民間病院が母体として開学した新設医大としては、当学と川崎医科大学・埼玉医科大学・杏林大学のみとなっている。
建学の精神は、「キリスト教的人類愛に根ざした、生命の尊厳を基調とする医師としての使命感を自覚し、人類社会に奉仕する人間の育成、ならびに専門的研究の成果を人類の福祉に活かしていく医師の養成」。学部では宗教学の講座がある。
6年間の学費は3,440万円(2014年度、自治会費や父兄会費等は別途)。付属の聖マリアンナ医科大学病院は、川崎市北西部では数少ない大規模な医療施設であり、地域医療の中核を担う。神奈川県初の救命救急センターの指定を受けている。
聖マリアンナ医科大学 概観
東急田園都市線・小田急小田原線の中間に位置し、両線の駅から離れているため、溝の口駅・宮前平駅・あざみ野駅・向ヶ丘遊園駅・生田駅・百合ヶ丘駅・新百合ヶ丘駅など、両線の複数の駅へ放射状にバス路線が伸び、バスが頻発している。各駅へはそれぞれ15～30分程度の時間を要する。
世界で5番目、アジアで初となるFIFA（国際サッカー連盟）メディカルセンターに指定されており、サッカー日本代表を支えている。
2014年4月22日、上智大学と教育・研究活動の交流と連携の推進を目的とした大学間交流に関する包括協定を締結。
2016年7月1日、田園調布学園大学及び川崎市宮前区との連携・協力に関する協定を締結。
聖マリアンナ医科大学 学費
聖マリアンナ医科大学医学部の学費は以下のとおりである。
学費
初年度学費
入学金　1,500,000円、授業料　3,700,000円、教育維持費　1,200,000円、教育充実費　500,000円、
・・・合計6,900,000円
次年度以降
授業料　3,700,000円、教育維持費　1,200,000円、教育充実費　600,000円、
・・・合計　5,500,000円
その他の徴収する費用
初年度
学生自治会費　5,000円、保護者会会費　112,000円、聖医会会費（同窓会費）　200,000円
次年度以降
学生自治会費　3,000円
聖マリアンナ医科大学 学生生活
現校名改称時に制定。作詞：藤浦洸、作曲：古関裕而
学園祭は「聖医祭」と呼ばれている。校内関係者や近隣住民の他、入院患者にも公開されている。
Transport Layer Security
Transport Layer Security（トランスポート・レイヤー・セキュリティ、TLS）は、インターネットなどのコンピュータネットワークにおいてセキュリティを要求される通信を行うためのプロトコルである。主な機能として、通信相手の認証、通信内容の暗号化、改竄の検出を提供する。TLSは非営利組織IETFによって策定された。
当プロトコルは（特に区別する場合を除いて）SSL (Secure Sockets Layer) と呼ばれることも多い。これは、TLSの元になったプロトコルがSSLであり、そのSSLという名称が広く普及していることによる。SSLはNetscapeが設計・開発した。当初のSSLを元にして、以後、SSL 2（1994年）、SSL 3（1995年）がそれぞれ前バージョンの欠陥や脆弱性を修正するものとして公開された。SSLを拡張して、TLS（1999年）、TLS 1.2（2008年）、TLS 1.3（2018年）が作られた。
2022年現在の最新版はTLS 1.3である。
Transport Layer Security 概要
TLSは多くの場合、コネクション型のトランスポート層プロトコル（通常はTCP）とアプリケーション層の間で使われる。特にHTTPでの利用を意識して設計されているが、アプリケーション層の特定のプロトコルには依存せず、様々なアプリケーションにおいて使われている。TLS 1.1以降を元にしたプロトコルが、UDPやDCCPといったデータグラム型プロトコル上でも実装されており、こちらはDatagram Transport Layer Security (DTLS) として独立して標準化されている。
TLSはHTTPなどのアプリケーション層のプロトコルと組み合わせることで、HTTPSなどセキュアな通信プロトコルを実現している。そのようなプロトコルとして以下のものがある。
TLSは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。
Transport Layer Security 概要
既存のアプリケーション層プロトコルでTLSを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにTLSのネゴシエーションを開始し、TLS接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式である。切り替えコマンドとしてSTARTTLSが広まっているため、この方式自体をSTARTTLSと呼ぶこともある。
前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、平文で接続を開始する実装と共存できなくなるため、既存のポート番号とは別にTLS対応用のポート番号が必要となる。実態としては、SSL/TLSの最初の適用例であるHTTPSをはじめとして、前者の方式を使うことが多い。ただし、この方式はバーチャルホストを構成する際に問題となる可能性がある。詳細は#バーチャルホストの節を参照。
なお、ポート番号を分ける方式をSSL、同一ポート番号で切替える方式（STARTTLS方式）をTLSと呼んでいる実装もある。TLS/SSLという用語の区別がプロトコルのバージョンを指しているか、アプリケーション層プロトコルへの適用方式を指しているかは、文脈で判断する必要がある。
Transport Layer Security 概要
TLSを導入さえすればセキュリティが確保できるという認識は誤っている。TLS通信は、平文での通信に比べて（主に暗号化・復号時）余分な計算機能力を使用するため、本当に必要なとき以外は使用しないことが多い。システムはデータの重要性を判断することができないので、TLSが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。
World Wide Webでは、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信で TLS (HTTPS) が使用されているか把握することが重要になる。多くのウェブブラウザは、画面のどこかに南京錠のアイコンを表示したり、アドレスバーの色を変化させたりして、利用者に情報を提供していた。一方 Google は南京錠のアイコンが適切ではなくなったとして、Chrome での南京錠の表示を廃止した。背景として、HTTPS が普及したこと、南京錠アイコンの意味を正しく理解している人が少ないことを挙げている。さらに、Chrome では HTTPS を使っていない通信を行う前に警告画面を出すようにした。
Transport Layer Security 概要
また実際に使用するアルゴリズムは双方のネゴシエーションによって決まるため、TLSを使用していても、システムとして許容はするが推奨できないアルゴリズムが採用される可能性がある。このような場合もダイアログメッセージなどを使って利用者に警告すべきである。
TLSは公開鍵証明書を用いて認証を行い、なりすましを極力排除しようとする。しかしシステムの自動的な対応には限界があり、すべてのなりすましを検出できるわけではない。
公開鍵証明書には認証局による電子署名が与えられる。その署名の正当性を評価するためには認証局の証明書が必要であり、最終的にはルート証明書と呼ばれる一群の証明書に行きつく。各システムは、認証局の証明書として信用できるルート証明書を、あらかじめ保持している。認証局は自身の秘密鍵を厳重に秘匿し、また証明書の発行にあたっては正当なサーバ管理者かどうか確認することが求められる。これらが保証されない認証局のルート証明書を組み込むことは、TLSにおける認証機能を破綻させることになる。仮に認証局自体は安全でも、入手したルート証明書が本当に意図する認証局のものかどうか判断することは難しいという点も注意すべきである。
Transport Layer Security 概要
TLSで認証を行うためには、認証局の署名に加えて、証明書の発行先を確認する必要がある。確認しない場合、サーバAの管理権限を持たない者がサーバBとして正当な証明書を取得し、その証明書を使ってサーバAを名乗ることができてしまう。TLS用のサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。
現実には「正当な」サーバであっても、これらの検証において「問題がある」と判断される証明書を使って運用されているサーバが少なからず存在する。セキュリティ研究者の高木浩光は、このような証明書のことを、オレオレ詐欺をもじって「オレオレ証明書」と呼んで批判している。
この検証は、システムに指示された接続先のホスト名と実際に接続した先のホスト名が一致することを検証しているのであり、利用者が意図する接続先とは必ずしも一致しないことに注意する必要がある。
Transport Layer Security 概要
例として、利用者が意図する接続先であるサーバAがホスト名www.example.comでサービスを提供しており、攻撃者はサーバBおよびホスト名www.example.orgを取得している場合を考える。仮に攻撃者がDNS偽装に成功して、www.example.comへの接続をサーバBに導くことができたとしても、www.example.comのサーバ証明書を入手できないので、TLS接続を提供することはできない。しかし攻撃者も、www.example.orgのサーバ証明書を入手することはできる。したがって、サーバAに接続しようとしている利用者を、www.example.comではなくwww.example.orgへ接続させることができれば、クライアントからは正当な証明書を持ったサーバとしか見えない。
上記のような例も考慮した上で、利用者が意図している接続先かどうかを判断するためには、以下の2つの条件を満たす必要がある。
2は、情報処理推進機構 (IPA) が公開している「安全なウェブサイトの作り方」という文書の「フィッシング詐欺を助長しないための対策」に対応する。
Transport Layer Security 概要
他の多くの近代暗号と同様に、TLSもまた、暗号としての強度は乱数の品質に依存している。桁数（ビット長）の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている（これは、公開鍵暗号システムにも言える）。もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、総当たり攻撃で解読される可能性が上昇する。通常は、これは実装の問題に起因している。
古い例では、Netscapeの初期の実装における乱数生成の脆弱性がある。プロセスIDや時刻から乱数を生成していることが判明し、これらの情報を取得できる場合には総当たり攻撃の所要時間が大幅に短くなるという問題があった。
2008年5月15日にはDebianが脆弱性に関する報告を発表した。OpenSSLライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536 (= 216) 通りの予測可能な物が生成されてしまった事を明らかにした（なお、この問題はOpenSSLそのものの脆弱性ではない）。この影響を受けるのはDebian sargeより後のバージョンのDebianと、それから派生したDamn Small Linux、KNOPPIX、Linspire、Progeny Debian、sidux、Ubuntu、UserLinux、Xandrosである。脆弱性のあるバージョンのOpenSSLは2006年9月17日に公開された。安定バージョンがリリースされた2007年4月8日以降は確実に影響を受ける。脆弱性のあるバージョンのOpenSSLで作られた鍵全て、SSH鍵、OpenVPN鍵、DNSSEC鍵、X.509証明書を生成するのに使われる鍵データ、およびSSL/TLSコネクションに使うセッション鍵等が影響を受ける。これらの鍵は65536通り全てを総当たり攻撃で試すだけでいずれの鍵が使われているか解読可能であり（SSHでは20分間で解読できたと報告されている）、また脆弱な鍵がインストールされたDebianを含む全てのオペレーティングシステムにおいて緊急の対応が必要であると専門家が注意を呼びかけている。生成された鍵に問題があるため、Debian GNU/Linuxで生成した鍵をMicrosoft Windowsのような非UNIXシステムに導入しているような場合も、この脆弱性の影響を受ける。具体的対応については、Debianの報告の他、JPCERTコーディネーションセンター (JPCERT/CC) の勧告等に従うべきである。
Transport Layer Security プロトコル概要
本説ではTLS 1.2の概要を説明する。
TLSには主なプロトコルとして暗号通信に必要な鍵 (master secret) を鍵共有してセッションを確立するTLSハンドシェイクプロトコルと、master secretを用いて暗号通信することで確立されたセッションにおけるコネクションをセキュアにするTLSレコードプロトコルがある。
その他に用いている暗号方式やハッシュ関数等のアルゴリズムを変更する Change Cipher Spec プロトコルと通信相手からの通信終了要求や何らかのエラーを通知する アラートプロトコルがある。
TLSハンドシェイクプロトコルは4つのフェーズに大別できる。
第一のフェーズではサーバ・クライアント間で通信に必要情報の合意を図る。このフェーズでは、まずクライアントからサーバにClientHelloが送信され、次にサーバからクライアントにServerHelloが送信される。
ClientHelloはTLSのバージョン、乱数、セッションID、通信に用いる暗号方式やハッシュアルゴリズムのリスト (cipher_suites)、通信内容の圧縮方法、および拡張領域の6つからなる。乱数は鍵共有におけるリプレイ攻撃を防ぐためのものである。
Transport Layer Security プロトコル概要
ServerHelloもClientHelloと同様の6つからなっている（名称は一部異なる）。ServerHelloの主な目的は、ClientHelloで提示された選択肢の中でサーバにとって好ましいものを選択する事で、例えばClientHelloで提示されたcipher_suitesの中から、サーバが通信に使いたいcipher_suiteを一組選ぶ。乱数はClientHelloとは独立して選ぶ。これもリプレイ攻撃を回避するためである。セッションIDは特に問題がなければClientHelloと同一のものを返す。
第二フェーズではサーバからクライアントに対して鍵共有に必要な情報を送る。具体的にはサーバはCertificate、ServerKeyExchange、CertificateRequest、ServerHelloDoneを（第一フェーズServerHelloに引き続き）クライアントに送信する。
Certificateは鍵共有で用いる公開鍵とその証明書で別途取り決めがない限りX.509v3のフォーマットに従う。なお鍵共有方式としてDH_anonを用いている場合にはcertificateは必要ない。
Transport Layer Security プロトコル概要
ServerKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、gx mod pという形のデータを送る。ここでxはサーバの秘密の乱数である。鍵共有プロトコルがDHE_DSS、DHE_RSA、DH_anonでは何らかのserver_key_exchangeを送るが、RSA、DH_DSS、DH_RSAでは何も送らない。
CertificateRequestはクライアントの公開鍵とその証明書を送ることを要求するためのもので、サーバが許容できる証明書の種別、ハッシュと署名方式、および認証局のリストからなっている。
そして最後にサーバ側からのメッセージ送信が終わった事を示すServerHelloDoneをクライアントに送る。
第三フェーズではクライアントからサーバに対して鍵共有に必要な情報を送る。具体的にはクライアントはCertificate、ClientKeyExchange、CertificateVerifyをサーバに送る。
Certificateは鍵共有で用いるクライアントの公開鍵とその証明書である。証明書はサーバから送られてきたCertificateRequestの条件を満たさねばならない。
Transport Layer Security プロトコル概要
ClientKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、gy mod pという形のデータを送る。ここでyはクライアントの秘密の乱数である。
ここまでのプロトコルにより、サーバとクライアントの間でpremaster secretが共有された事になる。DH_anonであればpremaster secretはgxy mod pである。premaster secretを鍵にした擬似ランダム関数にServerHelloとClientHelloの乱数などを並べたものを入力した結果得られたものがmaster secretである。
CertificateVerifyはクライアントが署名能力を持っていることを証明するためにこれまでTLSハンドシェイクプロトコルで送受信された全メッセージに対し、共有されたmaster secret で署名したものである。
クライアントは必要ならChange Cipher Spec プロトコルのメッセージをサーバに送り、終了を意味するFinishedをサーバに送る。同様にサーバも必要ならChange Cipher Spec プロトコルのメッセージをクライアントに送り、終了を意味するFinishedをクライアントに送る。
Transport Layer Security プロトコル概要
TLSレコードプロトコルはアプリケーション層から受け取った通信内容を214バイト以下のブロックに分解 (fragmentation) し、各ブロックを圧縮 (compress) し、圧縮されたブロックを認証暗号で暗号化するレコード Payload 防護を施した上で、通信内容を通信相手に送信する。
認証暗号は、TLS 1.1まではMACをつけた後で共通鍵暗号化するMAC-then-Encrypt (MtE) のみが利用可能であった。TLS 1.2からは、AES-GCMのようなAEADに分類される認証暗号専用の暗号利用モードも利用可能になり、TLS 1.3ではAEADのみが利用可能となっている。
認証暗号にブロック暗号（AEAD以外）を選択した場合、TLS 1.1以降においてIVはTLSレコードプロトコルの送信者がランダムに選ぶ。ランダムなIVは、BEAST攻撃への対策として有効である。一方、認証暗号で用いる共通鍵はTLSハンドシェイクプロトコルで共有されたmaster secretを用いる。
Transport Layer Security バージョン
コンピュータの計算能力の向上とともに、認証の突破、暗号の解読、改竄も以前よりは容易に行えるようになり、セキュリティ確保のための技術も厳しさを増している。
2017年現在では、TLS 1.2 以上のバージョンの実装が推奨され、TLS 1.1 以下のサポートを停止するサイトも出てきている。2021年3月にはRFC 8996により、TLS 1.0〜TLS 1.1の使用禁止が求められている。
ネットスケープコミュニケーションズ社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな脆弱性が発見され、破棄された。このため、2018年現在ではSSL 1.0を実装した製品はない。
ネットスケープコミュニケーションズ社はSSL 1.0の問題を修正して再設計し、1994年にSSL 2.0として発表した。また、同社のウェブブラウザであるNetscape Navigator 1.1においてSSL 2.0を実装した。
Transport Layer Security バージョン
その後、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以降へ対応する動きが広まっている。
SSL 2.0にはチェーン証明書がなく、ルートCAから発行したSSLサーバ証明書しか使うことができない。
Transport Layer Security バージョン
2011年3月、RFC 6176 によってSSL 2.0の使用は禁止された。
ネットスケープコミュニケーションズ社はSSL 2.0の問題を修正するとともに機能追加を行い、1995年にSSL 3.0を発表した。また、Netscape Navigator 2.0においてSSL 3.0を実装した。SSL 3.0の仕様書については、2011年にIETFから歴史的文書という扱いでRFC 6101として公開された。
2014年10月にSSL 3.0の仕様上の脆弱性（POODLE攻撃）が発見されたため、SSL 3.0への対応を打ち切り、TLS 1.0以降のみ対応への移行が望まれている。2015年6月、RFC 7568 によってSSL 3.0の使用は禁止された。
SSLについては、使うべきではない。
IETFのTLSワーキンググループはRFC 2246としてTLS 1.0を公表した。TLS 1.0の標準化作業は1996年に開始され、年内に完了する予定だったが、いくつかの問題に阻まれ、公表は1999年まで遅延した。
Transport Layer Security バージョン
TLS 1.0が提供する機能はSSL 3.0とあまり変わらないが、アルゴリズムやルートCAの自己署名証明書の取扱いなどの仕様の詳細が変更されたことに加え、これまであまり実装されていなかった選択肢のいくつかが必須と定められた。このため、TLS 1.0を実装した製品が普及するまでには、さらに数年を要した。
2021年3月、RFC 8996によりTLS 1.0を使用しないことが呼びかけられている。
なおTLS 1.0はSSL 3.0より新しい規格であることを示すため、ネゴシエーションにおけるバージョン番号は3.1となっている。
2006年にRFC 4346としてTLS 1.1が制定された。TLS 1.0からの変更点は、新しく発見された攻撃手法に対する耐性の強化が中心である。特にCBC攻撃に対する耐性を上げるため、初期化ベクトルを明示的に指定することにし、さらにパディングの処理も改善された。また、予期せぬ回線クローズ後に、セッションを再開できるようになった。共通鍵暗号アルゴリズムとしてAESが選択肢に加わった。
2021年3月、RFC 8996によりTLS 1.1を使用しないことが呼びかけられている。2024年10月より、WindowsはTLS 1.0、TLS 1.1をサポートしない旨を発表した。
Transport Layer Security バージョン
ネゴシエーションにおけるバージョン番号は3.2となっている。
2008年8月にRFC 5246としてTLS 1.2が制定された。ハッシュのアルゴリズムにSHA-256が追加されたほか、ブロック暗号について、従来のCBCモードだけではなく、GCM、CCMといった認証付き暗号を用いたcipher suiteが利用可能となった。また、AESに関する記述がRFC 5246自体に含まれるようになった。
ネゴシエーションにおけるバージョン番号は3.3となっている。
新たなTLSのバージョンとしてTLS 1.3が提案されてきたが、IETFは2018年3月23日に、ドラフト28を標準規格として承認し、同年8月10日にRFC 8446として公開した。
TLS 1.2からの変更点としては、データ圧縮の非サポート、forward secrecyではないcipher suite（RSAのみを用いたもの）および認証付き暗号ではないcipher suite（CBCモードのブロック暗号やRC4を用いたもの）の廃止が挙げられる。なお名称をTLS 2.0やTLS 4等に変更することが検討されたが、最終的にTLS 1.3に落ち着いた。
Transport Layer Security 暗号スイート
TLSではハンドシェイクプロトコルのClientHello・ServerHelloで、以後の通信で用いる暗号スイート (ciphersuite) を決定する。TLS 1.2を策定しているRFC 5246では、暗号スイートを以下のフォーマットで表現している：
これは次の意味である。
TLS1.2では認証暗号としてMtE型のもののみならず、AES-GCMのような認証暗号専用に作られた暗号利用モードも用いる事ができるようになった。この場合MACはそもそも必要ない。
なお、RSA暗号とRSA署名を組み合わせる事で実現した鍵共有方式に対してはTLS_RSA_RSA_WITH…のようにRSAを2回書かず、TLS_RSA_WITH_…のように略記する。
鍵共有、共通鍵暗号、ハッシュ関数の全ての組み合わせが網羅されているわけではないので、同時に利用できない組み合わせも存在する。
SSL/TLS（の1つ以上のバージョンで）使用できる鍵共有方式は以下のとおりである。ここでDHはDiffie-Hellmanの事である。なおDH-ANON、ECDH-ANONは中間者攻撃に対して脆弱であることから安全とはみなされていない。
Transport Layer Security 暗号スイート
DH-***はFixed DHもしくはnon-interactive DHと呼ばれるもので、Diffie-Hellmanで用いるパラメータ（クライアントのgx、サーバのgy）がクライアントやサーバの公開鍵として認証局から公開鍵証明書を受け取っているケースのDiffie-Hellman鍵共有である。gx、gyに対する公開鍵証明書内の署名文を作成する署名方式は「***」の部分に記載されたものを使う。ECDH-*** (Fixed ECDH) はFixed DHの楕円DH版である。
いずれの鍵共有においても共有された鍵 (premaster secret) を用いた擬似ランダム関数にクライアントが選んだ乱数とサーバが選んだ乱数等を並べたものを入力する事で最終的なmaster secretを得る。これによりリプレイ攻撃を防いでいる。
これらの鍵共有方式の対応状況は以下のとおりである：
事前共有鍵を用いた TLS_PSK、Secure Remote Password protocolを用いた TLS_SRP、ケルベロス認証を用いた KRB5 も存在する。
独立国家共同体のGOST規格によって規定された鍵共有アルゴリズムであるGOST R 34.10も提案されている（同じGOST規格による暗号化・改竄検出アリゴリズムとの組み合わせに限定）。
Transport Layer Security 暗号スイート
認証暗号に用いる共通鍵暗号として以下のものがある。
AES CBCはTLS 1.0を定義する RFC 2246 には含まれていないが、RFC 3268 で追加された。TLS 1.1を定義する RFC 4346 からは RFC 3268 が参照されており、さらにTLS 1.2では定義である RFC 5246 にAES CBCに関する記述が取り込まれた。また、認証付き暗号によるAES GCM (RFC 5288, RFC 5289)、AES CCM (RFC 6655, RFC 7251) が追加されている。IDEA CBC、DES CBCはTLS 1.2で廃止された（RFC 5469 に解説がある）。
ブロック暗号のCBCモードでの利用については、TLS 1.0以前においてBEAST攻撃と呼ばれる攻撃が可能であることが明らかとなっており、クライアント側、サーバ側での対応が必要とされている。TLS 1.1以降ではこの攻撃への根本的な対処として初期化ベクトルを明示的に指定し、パディングの処理が改善された。ブロック暗号であってもGCM、CCMなどの認証付き暗号を用いる場合にはこれらの攻撃を受けない。
Transport Layer Security 暗号スイート
ストリーム暗号であるRC4は前述のBEAST攻撃を受けることはないが、RC4には仕様上の脆弱性が存在する（RC4攻撃）。2015年2月、TLSのすべてのバージョンにおいてRC4の利用を禁止する RFC 7465 が公開された。ストリーム暗号であるChaCha20と認証のためのPoly1305を組み合わせたChaCha20+Poly1305が RFC 7905 として標準化されている。
いくつかの国家標準に基づく暗号化アルゴリズムもTLSで利用可能であり、日本のCRYPTRECによる推奨暗号であるCamellia（CBCモード：RFC 4132、RFC 5932、RFC 6367、GCM：RFC 6367）、韓国の情報通信標準規格に採用されているSEED（CBCモード：RFC 4162）、ARIA（CBCモードおよびGCM：RFC 6209）が追加されている。また、独立国家共同体のGOST規格によって規定された暗号化アルゴリズムであるGOST 28147-89も提案されている。
SSLが設計された当時は、アメリカ合衆国によって高強度暗号アルゴリズムの輸出が規制されていた。そのため、全世界で共通して利用できるアルゴリズムとして、DES・RC2・RC4に関して暗号強度を40ビットに制限したものが導入されていた。これらはTLS 1.1以降では利用が禁止されている。
Transport Layer Security 暗号スイート
また、鍵共有のみを行い暗号化は行わないこと (NULL) も可能であるが、平文でのやりとりとなることから安全とはみなされていない。
TLS/SSLの各バージョンで使用できるMACの選択肢は以下のとおりである。下欄の「AEAD」（Authenticated Encryption with Associated Data、認証暗号）は、共通鍵暗号として認証暗号を選んでいるのでMACを用いない事を意味する。
独立国家共同体のGOST規格によって規定されたアルゴリズムであるGOST 28147-89に基づくMACおよび、GOST R 34.11も提案されている（同じGOST規格による鍵共有・暗号化アリゴリズムとの組み合わせに限定）。
Transport Layer Security 実装
注
2021年1月現在、主要なウェブブラウザの最新版ではTLS 1.2、1.3が既定で有効であるが、過去のバージョンのOS向けなどサポートが継続しているウェブブラウザのいくつかのバージョンではそうではない。
TLS 1.0、1.1は脆弱性が危惧され、2020年から無効化が実施され始めている。
既知の脆弱性のいくつかへの対応は十分ではない。
Transport Layer Security 実装
POODLE攻撃への対応：いくつかのブラウザではTLS_FALLBACK_SCSVを実装済みでSSL 3.0へのフォールバックを抑止することが可能となっているが、これはクライアント側だけでなくサーバ側での対応も必要である。SSL 3.0そのものの無効化、"anti-POODLE record splitting"の実装、あるいはSSL 3.0におけるCBCモードのcipher suiteの無効化が根本的な対策となる。
Google Chrome：完了（バージョン33においてTLS_FALLBACK_SCSVを実装、バージョン39においてSSL 3.0へのフォールバックを無効化、バージョン40においてSSL 3.0を既定で無効化。バージョン44においてSSL 3.0のサポートを廃止）
Mozilla Firefox：完了（バージョン34においてSSL 3.0を既定で無効化およびSSL 3.0へのフォールバックを無効化、バージョン35においてTLS_FALLBACK_SCSVを実装。延長サポート版でもESR 31.3においてSSL 3.0を無効化およびTLS_FALLBACK_SCSVを実装。バージョン39においてSSL 3.0のサポートを廃止）
Transport Layer Security 実装
Internet Explorer：部分的（バージョン11のみ、2015年2月のアップデートにおいて保護モードにおけるSSL 3.0へのフォールバックを既定で無効化。2015年4月にSSL 3.0自体を既定で無効化。バージョン10以前では対策は講じられていない）
Opera：完了（バージョン20においてTLS_FALLBACK_SCSVを実装、バージョン25において"anti-POODLE record splitting"を実装、バージョン27においてSSL 3.0を既定で無効化。バージョン31においてSSL 3.0のサポートを廃止）
Safari：完了（OS X v10.8以降およびiOS 8.1以降のみ、POODLEへの対策としてSSL 3.0においてCBCモードのcipher suiteを無効化した。これによりPOODLEの影響を受けることはなくなるが、SSL 3.0においてCBCモードを無効化したことで、脆弱性が指摘されているRC4しか利用できなくなるという問題が生じている。OS X v10.11およびiOS 9においてSSL 3.0のサポートを廃止）
Transport Layer Security 実装
RC4攻撃への対応
Google Chromeでは、バージョン43以降はホストがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限りRC4を用いたCipher Suiteがフォールバックとして利用されるようになった。バージョン48以降では、RC4を用いたCipher Suiteのすべてが既定で無効化された。
Firefoxでは、バージョン36以降はホストがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限りRC4を用いたCipher Suiteがフォールバックとして利用されるようになった。バージョン44以降では、RC4を用いたCipher Suiteのすべてが既定で無効化された。
Operaでは、バージョン30以降はホストがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限りRC4を用いたCipher Suiteがフォールバックとして利用されるようになった。バージョン35以降では、RC4を用いたCipher Suiteのすべてが既定で無効化された。
Transport Layer Security 実装
Windows 7 / Server 2008 R2およびWindows 8 / Server 2012向けのInternet Explorerでは、RC4の優先度を最低としている。Windows 8.1 / Server 2012 R2向けのInternet Explorer 11およびWindows Phone 8.1向けのInternet Explorer Mobile 11およびWindows 10向けのEdgeでは、ホストが他のアルゴリズムに非対応の場合のフォールバックを除きRC4を無効としている（Windows 7 / Server 2008 R2およびWindows 8 / Server 2012向けのInternet Explorerでもレジストリからフォールバックを除きRC4を無効化することが可能）。2016年8月の月例アップデートにおいて、Inter Explorer 11およびEdgeにおいてRC4を用いたCipher Suiteのすべてが既定で無効化。
FREAK攻撃への対応:
Android 4以前の標準ブラウザはFREAK攻撃に対して脆弱である。
Internet Explorer 11 MobileはFREAK攻撃に対して脆弱である。
Google Chrome（Windows版を除く）、Internet Explorer、Safari（デスクトップ版、iOS版）、Opera（Windows版を除く）はFREAK攻撃に対して対応済みである。
Mozilla Firefox、Google Chrome（Windows版）、Opera（Windows版）はFREAK攻撃の影響を受けない。
注
完全な対策としては、SSL 3.0そのものの無効化、"anti-POODLE record splitting"の実装。"anti-POODLE record splitting"はクライアント側のみの対応で有効でありSSL 3.0の仕様にも準拠しているが、サーバによっては互換性の問題が生じる可能性がある。
部分的な対策としては、クライアント側でのSSL 3.0へのフォールバックの無効化、TLS_FALLBACK_SCSVの実装、CBCモードによるCipher Suiteの無効化など。TLS_FALLBACK_SCSVはSSL 3.0へのフォールバックの抑止の一つであるがクライアント、サーバ双方での対応が必要であり、サーバ側がこれに非対応かつSSL 3.0対応の場合には効果がない。SSL 3.0においてCBCモードによるCipher Suiteを無効化した場合には、RC4を用いたCipher Suiteしか利用できなくなるためRC4攻撃に対する脆弱性が増大する。
手動でSSL 3.0を無効化した場合にはPOODLE攻撃を受けることはない。
TLS/SSLライブラリの多くはオープンソースソフトウェアである。
注
Transport Layer Security 課題および制限事項
TLSは、TCP/IPネットワークでホスト名ベースのバーチャルホストを構成する際に問題となる。TCP/IPでは通信を開始する前にホスト名を解決し、実際にはIPアドレスとポート番号で接続先を識別している。このためTLSのネゴシエーションの時点では、バーチャルホストのうちどのホスト名を期待しているのか判断できず、ホスト名ごとに異なるサーバー証明書を使い分けることができない。
TLSの拡張機能を定義するRFC 6066では、ネゴシエーション時にホスト名を伝える手段としてServer Name Indication (SNI) を規定している。用例としては、HTTPの最新バージョンであるHTTP/2においてTLSを利用する際はSNIの利用が必須とされている。
一方、証明書を使い分けず、1つの証明書を複数のバーチャルホストで使い回す方式も広く利用されている。X.509証明書のフォーマットについて記述したRFC5280では、発行先ホスト名を保持するsubjectAltNameはひとつの証明書に複数のエントリを作成できると規定している。これを利用して、ホストに収容されたすべてのバーチャルホストに対応したsubjectAltNameを保持する証明書をクライアントに提示すれば良い。
Transport Layer Security 課題および制限事項
また、発行先ホスト名にワイルドカードを使う方法も考えられる。HTTP over SSL/TLS (HTTPS) を定義するRFC 2818は、ワイルドカードの適用について記述している。バーチャルホストの対象が、ひとつのドメイン名の中のホストであれば、この方法で対応できる場合もある。
どの方法も実装によって対応状況にバラつきがあり、環境によっては使えない可能性がある。なおIPアドレスベースのバーチャルホストであれば、ネゴシエーションの時点で確実にどのバーチャルホストを期待しているか判断できるので、問題なく証明書を使い分けることができる。
TLSそのものはTLS自身に依存することがないように設計されている。しかし、TLS運用のために必要となる他の要素技術は設定次第でTLSに依存してしまう場合があり、そのような設定の下では再帰的なTLS依存性によりTLSが期待通りに運用できなくなる恐れがある。
Transport Layer Security 課題および制限事項
例として、公開鍵証明書やCRLの転送手段にTLSを用いているが、そのTLSにおける認証が転送される公開鍵証明書やCRL自身に再帰的に依存してしまう設定ミスがある。このような設定の下でTLSを運用した場合、公開鍵証明書やCRLを取得しようとしてTLSハンドシェークを実行すると、そのために元来取得しようとしていた公開鍵証明書やCRLがTLSハンドシェークに先立って必要となる卵と鶏問題が発生し、結果として無限ループに陥ってしまう。
この問題を根本から防止するため、TLS実装によっては公開鍵証明書やCRLの転送にてTLSの使用を禁止していることがある。また、この問題はTLSを用いてセキュリティを確保することが理論上不可能な通信が存在することも示している。
Transport Layer Security TLS/SSLの既知の脆弱性
TLS/SSLに対する攻撃のうち主なものを以下に挙げる。2015年2月に、TLS/SSLに対する既知の攻撃についての情報をまとめたRFC 7457がIETFから公開されている。
TLS 1.2ではすでに危殆化したRC4、MD5、SHA1が選択可能であり、この事が脆弱性の原因となっている。
MD5はすでに衝突が容易に見つかるレベルまで危殆化しているため、これを利用したSLOTH攻撃 (CVE-2015-7575) が知られている。
SHA1もFreestart Collisionが見つかっており安全ではない。
RC4もTLSのすべてのバージョンにおいて利用を禁止するRFC 7465が公開された。MozillaおよびマイクロソフトではRC4を無効化することを推奨している。
Transport Layer Security TLS/SSLの既知の脆弱性
RC4そのものに対する攻撃法は多く報告されているが、TLS/SSLにおいてRC4を用いたCipher Suiteについては、その脆弱性に対処されており安全であると考えられていた。2011年には、ブロック暗号のCBCモードの取り扱いに関する脆弱性であったBEAST攻撃への対応策の一つとして、ストリーム暗号であるためその影響を受けないRC4に切り替えることが推奨されていた。しかし、2013年にTLS/SSLでのRC4への効果的な攻撃が報告され、BEASTへの対応としてRC4を用いることは好ましくないとされた。RC4に対する攻撃は、AlFardan、Bernstein、Paterson、Poettering、Schuldtによって報告された。新たに発見されたRC4の鍵テーブルにおける統計的な偏りを利用し、平文の一部を回復可能であるというものである。この攻撃では、13 × 220の暗号文を用いることで128ビットのRC4が解読可能であることが示され、2013年のUSENIXセキュリティシンポジウムにおいて「実現可能」と評された。2013年現在では、NSAのような機関であればTLS/SSLを利用したとしてもRC4を解読可能であるとの疑惑がある。
Transport Layer Security TLS/SSLの既知の脆弱性
2015年現在ではクライアントのほとんどは既にBEASTへの対処が完了していることから、RC4はもはや最良の選択肢ではなくなっており、TLS 1.0以前においてもCBCモードを用いることがより良い選択肢となっている。
かつてアメリカ合衆国からの暗号の輸出規制が厳しかった時期に、規制を回避するために一時的に512ビットのRSA鍵を生成して、そちらで通信を行うというような手法が存在した。この手法については、一時的な公開鍵を素因数分解することが可能であれば中間者攻撃が成立することが1998年時点で指摘されていたが、コンピュータの性能向上、クラウドコンピューティングの普及により素因数分解が個人レベルですら現実的となったこと、さらに2015年には、OpenSSL、Safari、Androidなどでは輸出用でない暗号スイートでも512ビットの一時鍵を受け入れてしまう実装となっていたことが判明し、FREAK (Factoring RSA Export Keys)として問題が再浮上している。
対策としては、すでに脆弱となっている輸出対応暗号の無効化、クライアント側では規格書通り、輸出暗号以外で一時的RSA鍵を使わないようにする、ということが挙げられる。
Transport Layer Security TLS/SSLの既知の脆弱性
2015年5月、Logjamと呼ばれる脆弱性が発見された。これも、FREAKと同様に輸出用の512ビットの一時鍵を受け入れてしまうものである。FREAKとは異なり、LogjamはTLSプロトコル自体の脆弱性である。発見時点において、主要なブラウザのすべてがLogjamに対して脆弱である。
False Start（Google Chromeで有効化された）やSnap StartといったTLS/SSLを高速化する変法は、攻撃者が一定条件下において本来利用可能なTLS/SSLのバージョンよりも低いバージョンでTLS/SSL接続を行うよう仕向けることや、クライアントからサーバへ送られる利用可能なCipher Suiteの一覧を改竄し、より低い暗号強度やより弱い暗号化アルゴリズム・鍵交換アルゴリズムを使用するよう仕向けることが可能であると報告されている。さらに、特定の環境においては、攻撃者がオフラインで暗号化に用いられた鍵を回復し、暗号化されたデータにアクセスすることも可能であることがAssociation for Computing Machinery (ACM) のコンピュータセキュリティカンファレンスで報告された。
Transport Layer Security TLS/SSLの既知の脆弱性
2011年9月23日、暗号研究者のThai DuongとJuliano Rizzoが、BEAST (Browser Exploit Against SSL/TLS) と呼ばれるTLS 1.0におけるブロック暗号のCBCモードの取り扱いに関する脆弱性のコンセプトをJavaアプレットの同一生成元ポリシー違反によって実証した。この脆弱性そのものは2002年にPhillip Rogawayによって発見されていたが、2011年の発表までは実用的なエクスプロイトは報告されていなかった。
2006年に発表されたTLS 1.1においてBEASTへの脆弱性は修正されていたが、2011年の実証までTLS 1.1への対応はクライアント、サーバの双方でほとんど進んでいなかった。
Transport Layer Security TLS/SSLの既知の脆弱性
Google ChromeおよびFirefoxはBEASTによる影響を直接的に受けることはないが、MozillaはTLS/SSLのためのライブラリであるNetwork Security Services (NSS) に対して、BEASTおよびそれに類似した選択平文攻撃に対するTLS 1.0以前で有効な対応策を2011年に施した。NSSは、Mozilla FirefoxなどのMozillaのソフトウェアだけでなく、Google Chromeなど他のブラウザでも用いられているライブラリである。NSSでのTLS 1.1以降への対応は2012年までずれこみ、FirefoxでTLS 1.1以降を既定で利用可能となったのは2014年のバージョン27である。
マイクロソフトは2012年1月10日にSecurity Bulletin MS12-006を発表し、Windowsで用いられているライブラリであるSChannelに対して修正を加えた。Windows 7以降では、TLS 1.1以降が利用可能である。