stanford-oval/wikipedia huggingface dataset:
ヤムチャ
補足 > キャラクター

初期案での名前は「ヤム・チャ」。二枚目半の悪党という設定。『西遊記』における沙悟浄を意識して作られた。
盗賊時代に着ていた道着に書かれていた「楽」のマークは、楽が好きだからという意味。
鳥山は読者からの「ヤムチャは幸せになれましたか?」の質問に「ずーっとあんな感じですね（笑）」と答えている。また鳥山は、「女性が大好きなのに苦手というジレンマを抱えたヤムチャは、未だ緊張しない理想の相手を求めて迷走中である。ホストクラブに勤めたこともあるが、やはり緊張でうまくいかずクビになる。主にフリーの用心棒をプーアルと共に生業としているが、たまに天津飯のところに農業の手伝いに行ったりもする」と2013年3月24日に放送された『漫道コバヤシ』『映画「ドラゴンボールZ 神と神」公開記念!出でよ神龍!!SP』のアンケートで回答している。
アニメ版では、界王星でリクームを圧倒したり、大界王星での修行後はそれ以上の実力を持つオリブーを簡単にあしらうなど、原作にはなかった「強敵に勝利する」シーンがいくつか存在している。人造人間編では、セルがセルゲーム開幕を宣言する前にクリリンと模擬戦をしており、悪ふざけもあったが怒ったクリリンに蹴りを見舞う場面がある。
アニメでは、定期的にプロ野球の助っ人のアルバイトをしており、3打席連続ホームランを打っていた（この設定は鳥山がアニメオリジナルエピソードのために考案したものであり、後に上述の通り趣味と設定された）。一方で、界王の下で熱心に修行する姿も見られた（昔の血が滾るからと説明）。アニメ版『ドラゴンボール オッス!帰ってきた孫悟空と仲間たち!!』では亀仙流の道着を着て仲間のプーアル、ウーロン、ブルマたちの頭上に落下してくる建物の瓦礫を繰気弾で粉砕して助けている。
アニメにて人造人間19号がヤムチャのデータを調べた際前述の身長・体重などのプロフィールの他、「OPINION（意見） STRATOS NO PLAMODEL SAIHANSARETE URESHII（ストラトスのプラモデル再版されて嬉しい）」と書かれていた。
その人気から、ヤムチャを主人公としたドラゴン画廊・リーの漫画『DRAGON BALL外伝 転生したらヤムチャだった件』前編、中編、後編が、Webサイト「少年ジャンプ+」に読切作品として公開された。内容は『ドラゴンボール』が大好きな平凡な男子高校生の主人公が事故をきっかけに、悟空が少年の頃のヤムチャに生まれ変わるもので、その後の展開を知っている主人公は、ヤムチャが栽培マンの自爆で死ぬ未来を変えるため奮闘するというifストーリーが描かれる。閲覧数は普通の読切の倍以上と、連載陣と比べても圧倒的であり、公開された週で一番読まれた作品として大きな反響を呼び、総閲覧数700万超えを記録。他のキャラクターに比べて扱いの良くなかったヤムチャだと逆転劇としてギャップが生じて面白そうだと、集英社の編集者が企画を立ち上げ、企画段階で鳥山明に相談して快諾をもらう。『ドラゴンボール』のパロディ漫画をネットで公開して話題になっていたドラゴン画廊・リーを他の編集者に教えてもらい、2016年5月に執筆依頼のメッセージをTwitterで送る。企画概要を伝えて執筆が決まり、担当編集者と直接打ち合わせて前編の大まかな構成が決定。作者は原作コミックのシーンを小ネタで拾いながらネームを作成し、そのネームを担当者が鳥山に見せたところ、「主人公の死に方を面白くして欲しい」などの主人公の設定など、読者の入り込みやすさを意識した改善点の指摘やアイデアをもらい、いくつか没になりながらネームが完成。完成した原稿も、面白いと鳥山が評価した。アニメ『超』でヤムチャが活躍する第70話「シャンパからの挑戦状!今度は野球で勝負だ!!」が、2016年12月11日に放送されることが執筆中に分かり、そのタイミングに合わせ前編が公開され、2017年11月には描きおろしも加えて単行本化された。
中川素子

中川 素子（なかがわ もとこ、1942年 - ）は、日本の絵本研究者。専門は美術史。文教大学名誉教授。
人物・略歴

1942年、東京生まれ。旧姓小川。1961年、静岡県立静岡高等学校卒業。1966年、東京藝術大学美術学部芸術学科卒業（1965年に安宅賞（奨学金）受賞）。1969年、同大学院美術研究科保存修復技術専攻（修士課程）修了。修了制作では「興福寺五部浄像脱乾漆復元想定像」を制作、東京芸術大学芸術資料館の買い上げとなった。同年、立正女子大学教育学部初等教育課程美術専修助手、1971年、同専任講師、1978年7月、文教大学（校名変更）教育学部初等教育課程美術専修助教授、1993年、同教授。2009年から2012年まで絵本学会会長を務めた。2013年、定年退職、名誉教授。実に44年の長きに亘り立正大学で教鞭を執り、大学の発展に寄与した。他に日本女子大学、日本女子大学大学院、立教大学、千葉大学にて非常勤講師、京都造形芸術大学にて客員教授を務めた。
1992年、『絵本はアート』で日本児童文学学会賞奨励賞受賞。
著書 > 単著

『絵本はアート ひらかれた絵本論をめざして』教育出版センター 1991
『本の美術誌 聖書からマルチメディアまで』工作舎 1995
『絵本は小さな美術館 形と色を楽しむ絵本47』平凡社新書 2003
『モナ・リザは妊娠中? 出産の美術誌』平凡社新書 2007
著書 > 共著編

絵本の視覚表現 そのひろがりとはたらき 今井良朗,笹本純共著 日本エディタースクール出版部 2001
イラストレーション・絵本 今井良朗共編 武蔵野美術大学出版局 2002
写真を使って絵本を作ろう! / 和田直人共著 あすなろ書房 2003
絵本でひろがる楽しい授業 文教大学絵本と教育を考える会著・中川編 明治図書出版 2003
ブック・アートの世界 絵本からインスタレーションまで 坂本満共編 水声社 2006.6
女と絵本と男 翰林書房 2009
著書 > 翻訳

エイラトさんのへんしんどうぶつえん ロイス・エイラト 偕成社 1997.12
エイラトさんのへんしんのうじょう ロイス・エイラト 偕成社 1998.7
家族

父：高杉一郎（小説家）
姉：田中泰子（ロシア児童文学の翻訳家、大阪外国語大学名誉教授）
姉：佐野朝子（ロシア文学の翻訳家、元慶應義塾大学講師）
志成ボクシングジム

志成ボクシングジム（しせいボクシングジム）は、東京都目黒区下目黒にあるボクシングジムである。
ジム外観（2023年3月）
概要

2020年6月22日に、オザキジムの元会長であった第23代日本スーパーフライ級王者の木谷卓也（現役時代は金子ボクシングジム所属）によって『Ambition GYM（アンビション ジム）』として開設された。
オザキジムは1973年6月に設立され、長期にわたる休止を経て2005年2月26日のリニューアルとともに木谷がマネージャー兼トレーナーに就任。2015年より木谷が会長に就任したが、2017年9月にジムから出火し、そばを走る小田急小田原線車両に引火する火災が発生、ジムは焼失した。
ライセンスはオザキジムのものを使用。所属選手としてはDANGAN AOKIより井岡一翔、白井・具志堅スポーツより比嘉大吾の世界王座経験者2人が移籍しプロ活動を開始。
当面はEBISU K'S BOXジム内に間借りする形でジムを運営し、その間にジム開設の場所を探していた。
2021年7月15日に、ジムの名称を『志成ボクシングジム』に変更して、東京都目黒区下目黒に移転した 。
12月1日付でエディ・タウンゼント賞トレーナー藤原俊志とプロ専用トレーナーとして契約。プロ専用トレーナーには他に「チーム内山」の一員としてエディ・タウンゼント賞を受賞した佐々木修平もいる。
主催興行は「LIFETIME BOXING FIGHTS」「ガッツファイティング」の2ブランドで行っていた。前者は2018年12月31日に当時JBCライセンスがなかった井岡がマカオで行ったドニー・ニエテスとのWBO世界スーパーフライ級タイトルマッチ以来井岡の世界戦をメインとする興行で行われてきたブランドであり、当ジム創設後は井岡あるいは比嘉がメインを務める興行で使われていた。後者は1978年よりTBSテレビにて放送する中継番組としてプロモート先を変えつつ続けており、協栄プロモート時代には木谷会長の現役時代の試合も組まれていた（ただし世界戦が組まれていない場合、興行を問わず深夜の「ガッツファイティング」枠での放送となっていた）。2022年からは前者に一本化され、ABEMAにてライブ配信されることになった。世界戦をメインとする興行は引き続きTBS及びParaviで生中継されていたが、2023年よりこちらもABEMAにて配信されている。
選手 > ジム出身世界王者

井岡一翔（WBO世界スーパーフライ級。在位中の2020年6月25日付でDANGAN AOKIより移籍）
選手 > 主な現役選手

井岡一翔 (現WBA世界スーパーフライ級王者、元WBC・WBA世界ミニマム級王者、元WBA世界ライトフライ級王者、元WBA世界フライ級王者、元WBO世界スーパーフライ級王者)
木村吉光 (第2代日本スーパーフェザー級ユース王者。白井・具志堅Sより移籍)
比嘉大吾（元WBC世界フライ級王者。白井・具志堅Sより移籍）
大湾硫斗（白井・具志堅Sより移籍）
森武蔵（元WBOアジアパシフィックフェザー級王者。薬師寺より移籍）
白石聖（第3代日本フライ級ユース王者。井岡より移籍）
高橋拓磨（ワールドSより移籍）
伊藤沙月（第7回全日本女子アマチュア大会ライトフライ級B優勝）
堤駿斗（OPBF東洋太平洋フェザー級王者）
堤麗斗
鈴木稔弘（南京ユースオリンピックライトウェルター級銀メダリスト）
重里侃太朗（仲里より移籍）
君島光輝

君島 光輝（きみじま みつき、1994年〈平成6年〉8月10日 - ）は、日本のタレント、女優。女性アイドルグループ・paletの元メンバーである。東京都葛飾区出身。プラチナムプロダクション所属、フリーランスを経てヒラタオフィス所属。愛称は、みっきー。
略歴

高校1年の時、プラチナムプロダクションにスカウトされタレント活動を始める。
2012年1月14日、前年暮れに佐久間夏帆が脱退し、9人組となっていた「ぱすぽ☆」（後に「PASSPO☆」に改名）の候補生として渋谷O-WESTに登壇。しかし同年3月31日に発表されたファン投票の結果、候補生の正規メンバー昇格者なしとされ、ぱすぽ☆への加入はならなかった。同年6月9日、paletのメンバーとして活動開始。グループ内の担当カラーは赤だった。
2015年6月21日、東京・恵比寿ザ・ガーデンホールで行われた「palet 3rd Anniversary Live 〜Time to Change〜」を以てpaletを卒業。
以降は女優・タレントとしての活動が主となっている。「オーネット」をはじめ11企業のCMの契約を全てオーディションで勝ち取っており、「令和のCM女王」と呼ばれる。
2024年10月1日、プラチナムプロダクションを前日9月30日を以て退所したことを自身のSNSで報告した。2025年1月、ヒラタオフィスに所属した。
人物

家族は両親と兄1人。
札幌生まれだが、小学時代は鹿児島県、中学時代は三重県に住んでいた。中学時代は卓球部で副キャプテンを務めたことがある。
高校時代の同級生にフィッシャーズのシルクロードがおり、同じクラスで席も前後だった。
歴代のpaletメンバーとしては唯一、血液型がAB型である。
paletの活動開始と前後した頃には、「秋葉原化劇団」に参加し演技レッスンを受けたことがあった。
宅地建物取引士と賃貸不動産経営管理士の資格を所持している。
作品

→paletでの参加作品については「palet § 作品」を参照
作品 > CD

CRAZY『魔法なんかいらない』（2016年11月16日発売／スマイラルレコード）
ドラマ「CRAZY」主題歌。
出演

→paletとしての出演については「palet § 出演」を参照
出演 > テレビドラマ

猫とコワモテ（2016年1月2日、BSジャパン）
HOPE〜期待ゼロの新入社員〜 第6話（2016年8月28日、フジテレビ）
CRAZY（2016年10月5日 - 12月21日、TOKYO MX・サンテレビ） - 岩本美礼 役
人形佐七捕物帳 第一話「羽子板娘」（2016年10月4日、BSジャパン） - お蝶 役
ブラックスキャンダル 第5話（2018年11月2日、読売テレビ・日本テレビ）
竜の道 二つの顔の復讐者 第1話（2020年7月28日、関西テレビ・フジテレビ） - 竜二の同僚 役
刑事7人 SEASON 6 第4話（2020年8月26日、テレビ朝日）
ほぼ日の怪談。第4話（2020年9月16日、ひかりTV・dTVチャンネル / テレビ神奈川）- 坂本美々 役
セイレーンの懺悔 第2話（2020年10月25日、WOWOW）- 中田 役
オー!マイ・ボス!恋は別冊で 第5話（2021年2月9日、TBS)  - イベントスタッフ 役
スイートリベンジ 第3話・第4話（2021年4月6・13日/FOD、2021年9月14・21日/フジテレビ）- 里奈 役
婚姻届に判を捺しただけですが　第3話（2021年11月2日、TBS）
ムチャブリ! わたしが社長になるなんて 第1話（2022年1月12日、日本テレビ）
精神分析医 氷室想介の事件簿〜超高層ビル密室殺人の謎〜（2022年2月26日、BS-TBS）- 「パノン」社員 役
ソロ活女子のススメ2 第1話（2022年4月7日、テレビ東京） - ヘリクルーズ受付 役
汝の名 第3話（2022年4月20日、テレビ東京）
ユニコーンに乗って 第8話（2022年8月23日、TBS）- 「ゲームアカデミア」の受付嬢 役
ボーイフレンド降臨! 第4話（2022年11月5日、テレビ朝日）
Sister 第7話（2022年12月1日、読売テレビ・日本テレビ）- みーたん 役
リエゾン -こどものこころ診療所- 第1話（2023年1月20日、テレビ朝日）- 東田加奈 役
罠の戦争（2023年1月23日 - 3月27日、フジテレビ） - 鳥居陽 役
ワタシってサバサバしてるから 第10話（2023年1月24日、NHK総合）
大奥「5代・徳川綱吉×右衛門佐 編」第7回（2023年2月21日、NHK総合） - 徳川綱教 役
トリリオンゲーム 第3話（2023年7月28日、TBS） - 客 役
院内警察 第5話・最終話（2024年2月9日・3月22日、フジテレビ） - 看護師 役
D&D〜医者と刑事の捜査線〜 第5話（2024年11月15日、テレビ東京） - 洋菓子店スタッフ 役
出演 > 配信ドラマ

新聞記者 第2話（2022年1月13日配信、Netflix）
出演 > Webドラマ

サイコウさんは最高です！（2024年11月22日 - 、BUMP） - 鈴木彩 役
出演 > バラエティ番組

激レアさんを連れてきた。（2022年2月7日、テレビ朝日）
出演 > 舞台

屋上ワンダーランド（2013年5月8日 - 12日、あうるすぽっと）
abc★赤坂ボーイズキャバレー 裏FINAL! 最後の充電!～自分に喝を入れて勝つ!～（2013年9月4日 - 8日、博品館劇場） - 糸井リカ 役
グッバイ・ジョーカー（2014年4月4日 - 9日、あうるすぽっと）
アンドキュメント（2015年1月20日 - 25日、赤坂RED/THEATER）
あかい、くつ。（2015年7月17日 - 20日、ザムザ阿佐谷）
KAJITSU -過日-（2015年9月11日 - 15日、あうるすぽっと）
アイドル甲子園シアター旗揚げ公演「AKIRA」（2015年9月29日 - 10月4日、シアターモリエール）
西原理恵子演劇祭2016「女の子ものがたり」（2016年1月23日 - 24日、ABCホール / 2月3日 - 7日、東京芸術劇場ウエストホール）
遙かなる時空の中で5 風花記（2016年8月11日 - 21日、全労済ホール／スペース・ゼロ） - 主演・蓮水ゆき 役
放課後戦記（2016年10月5日 - 10日、新宿村LIVE）
エンブリオ（2017年5月17日 - 21日、シアターサンモール）
宮崎理奈プロデュース舞台「不思議の国のカンタータ 〜泣き声混じりの空想歌〜」（2017年11月22日 - 26日、新宿村LIVE） - ノーマ 役（初演・再演）
ミュージカル・リズムステージ「夢色キャスト」（2018年2月7日 - 11日、AiiA 2.5 Theater Tokyo） - ヒロイン・彩瀬まどか 役
劇団SUTTHINEE 第2回公演「カエデソウ」（2019年4月3日 - 7日、バルスタジオ） - 兎耳楓 役
萬腹企画 7杯目「封印壊除」（2019年7月10日 - 15日、萬劇場） - みぞれ 役
劇団SUTTHINEE 第3回公演「Value Live〜突然の無人島生活〜」（2019年8月7日 - 12日、バルスタジオ） - 阿久津麗子 役
Get Back!!（2019年9月22日 - 29日、俳優座劇場）
銀河英雄伝説 Die Neue These～第三章 嵐の前～（2019年10月 - 11月、Zepp DiverCity TOKYO / Zepp Namba） - ヒルデガルド・フォン・マリーンドルフ 役
冒険者たちのホテル〜ドラゴンクエストXに集いし仲間たち〜（2019年12月、俳優座劇場） - みーこ 役
出演 > 映画

デスフォレスト 恐怖の森3・4（2015年・2016年） - 秋村里香 役
それぞれの花（2022年11月4日）- ゆき 役
私が俺の人生!?（2024年7月19日） - 千田恭子 役
49日の真実（2025年春公開予定）
出演 > CM

イエローハット（2014年）
ファミリーレストラン「ココス」（2016年 - ）
トヨタ自動車「T-up」（2016年）
JR東日本「JRE POINT」（2017年）
ビジュピコ「ブライダルジュエリー」（2017年）
SEIKO「ルキア」（2020年）
かっぱ寿司（2020年）
楽天マガジン（2020年）
モスバーガー フォカッチャサンド「食べたら気分はアウトドア」篇（2021年）
『Honda Cars』新型ヴェゼル新CM「レポーターもアガる」篇
池田模範堂「アセムヒEX」
NTT西日本「ICTで、いつかを、いまに。WONDERFUL ICT LIFE 篇」
Kiri「自分にやさしく」
横浜銀行
「明治ザバスfor Woman MILK PROTEIN」
DJI JAPAN
オーネット
アサヒ飲料「カルピスウォーターとななチキレッド（旨辛唐辛子）の甘辛無限ループ」（2024年）
出演 > MV

松岡卓弥「タックル」（アルバム『My Past Collections T』所収、2016年）
出演 > ラジオ

まだまだゴチャ・まぜっ！〜集まれヤンヤン〜（2013年 - 2014年、MBSラジオ） - ヤンヤンガールズ
君島光輝の休息充電（2024年 - 、かつしかFM） - パーソナリティ
出演 > Webラジオ

田原俊彦 Double T Relax Time season16（2021年） - アシスタント
出演 > 雑誌

日本ツインテール協会
週刊ヤングマガジン
月刊ヤングマガジン
girls vol.46（双葉社）
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である。
概要

TLSは多くの場合、コネクション型のトランスポート層プロトコル（通常はTCP）とアプリケーション層の間で使われる。特にHTTPでの利用を意識して設計されているが、アプリケーション層の特定のプロトコルには依存せず、様々なアプリケーションにおいて使われている。TLS 1.1以降を元にしたプロトコルが、UDPやDCCPといったデータグラム型プロトコル上でも実装されており、こちらはDatagram Transport Layer Security (DTLS) として独立して標準化されている。
TLSはHTTPなどのアプリケーション層のプロトコルと組み合わせることで、HTTPSなどセキュアな通信プロトコルを実現している。そのようなプロトコルとして以下のものがある。
| SSLと組み合わせたプロトコル | ポート番号 | 元のプロトコル | ポート番号 |
| --- | --- | --- | --- |
| HTTPS | 443 | HTTP | 80 |
| SMTPS | 465 | SMTP | 25 |
| LDAPS | 636 | LDAP | 389 |
| FTPS (data) | 989 | FTP (data) | 20 |
| FTPS (control) | 990 | FTP (control) | 21 |
| IMAPS | 993 | IMAP | 143 |
| POP3S | 995 | POP3 | 110 |
概要 > アプリケーション層プロトコルへの適用

TLSは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。
既存のアプリケーション層プロトコルでTLSを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにTLSのネゴシエーションを開始し、TLS接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式である。切り替えコマンドとしてSTARTTLSが広まっているため、この方式自体をSTARTTLSと呼ぶこともある。
前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、平文で接続を開始する実装と共存できなくなるため、既存のポート番号とは別にTLS対応用のポート番号が必要となる。実態としては、SSL/TLSの最初の適用例であるHTTPSをはじめとして、前者の方式を使うことが多い。ただし、この方式はバーチャルホストを構成する際に問題となる可能性がある。詳細は#バーチャルホストの節を参照。
なお、ポート番号を分ける方式をSSL、同一ポート番号で切替える方式（STARTTLS方式）をTLSと呼んでいる実装もある。TLS/SSLという用語の区別がプロトコルのバージョンを指しているか、アプリケーション層プロトコルへの適用方式を指しているかは、文脈で判断する必要がある。
概要 > セキュリティ上の考察 > TLS適用の有無と使用アルゴリズムの強度

TLSを導入さえすればセキュリティが確保できるという認識は誤っている。TLS通信は、平文での通信に比べて（主に暗号化・復号時）余分な計算機能力を使用するため、本当に必要なとき以外は使用しないことが多い。システムはデータの重要性を判断することができないので、TLSが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。
World Wide Webでは、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信で TLS (HTTPS) が使用されているか把握することが重要になる。多くのウェブブラウザは、画面のどこかに南京錠のアイコンを表示したり、アドレスバーの色を変化させたりして、利用者に情報を提供していた。一方 Google は南京錠のアイコンが適切ではなくなったとして、Chrome での南京錠の表示を廃止した。背景として、HTTPS が普及したこと、南京錠アイコンの意味を正しく理解している人が少ないことを挙げている。さらに、Chrome では HTTPS を使っていない通信を行う前に警告画面を出すようにした。
また実際に使用するアルゴリズムは双方のネゴシエーションによって決まるため、TLSを使用していても、システムとして許容はするが推奨できないアルゴリズムが採用される可能性がある。このような場合もダイアログメッセージなどを使って利用者に警告すべきである。
概要 > セキュリティ上の考察 > 証明書の正当性

→詳細は「認証局」を参照
TLSは公開鍵証明書を用いて認証を行い、なりすましを極力排除しようとする。しかしシステムの自動的な対応には限界があり、すべてのなりすましを検出できるわけではない。
公開鍵証明書には認証局による電子署名が与えられる。その署名の正当性を評価するためには認証局の証明書が必要であり、最終的にはルート証明書と呼ばれる一群の証明書に行きつく。各システムは、認証局の証明書として信用できるルート証明書を、あらかじめ保持している。認証局は自身の秘密鍵を厳重に秘匿し、また証明書の発行にあたっては正当なサーバ管理者かどうか確認することが求められる。これらが保証されない認証局のルート証明書を組み込むことは、TLSにおける認証機能を破綻させることになる。仮に認証局自体は安全でも、入手したルート証明書が本当に意図する認証局のものかどうか判断することは難しいという点も注意すべきである。
TLSで認証を行うためには、認証局の署名に加えて、証明書の発行先を確認する必要がある。確認しない場合、サーバAの管理権限を持たない者がサーバBとして正当な証明書を取得し、その証明書を使ってサーバAを名乗ることができてしまう。TLS用のサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。
現実には「正当な」サーバであっても、これらの検証において「問題がある」と判断される証明書を使って運用されているサーバが少なからず存在する。セキュリティ研究者の高木浩光は、このような証明書のことを、オレオレ詐欺をもじって「オレオレ証明書」と呼んで批判している。
この検証は、システムに指示された接続先のホスト名と実際に接続した先のホスト名が一致することを検証しているのであり、利用者が意図する接続先とは必ずしも一致しないことに注意する必要がある。
例として、利用者が意図する接続先であるサーバ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) が公開している「安全なウェブサイトの作り方」という文書の「フィッシング詐欺を助長しないための対策」に対応する。
概要 > セキュリティ上の考察 > 乱数の品質

他の多くの近代暗号と同様に、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/CCの勧告等に従うべきである。
プロトコル概要

本説ではTLS 1.2の概要を説明する。
TLSには主なプロトコルとして暗号通信に必要な鍵 (master secret) を鍵共有してセッションを確立するTLSハンドシェイクプロトコルと、master secretを用いて暗号通信することで確立されたセッションにおけるコネクションをセキュアにするTLSレコードプロトコルがある。
その他に用いている暗号方式やハッシュ関数等のアルゴリズムを変更する Change Cipher Spec プロトコルと通信相手からの通信終了要求や何らかのエラーを通知する アラートプロトコルがある。
プロトコル概要 > TLSハンドシェイクプロトコル

TLSハンドシェイクプロトコルは4つのフェーズに大別できる。
プロトコル概要 > TLSハンドシェイクプロトコル > 第一フェーズ

第一のフェーズではサーバ・クライアント間で通信に必要情報の合意を図る。このフェーズでは、まずクライアントからサーバにClientHelloが送信され、次にサーバからクライアントにServerHelloが送信される。
ClientHelloはTLSのバージョン、乱数、セッションID、通信に用いる暗号方式やハッシュアルゴリズムのリスト (cipher_suites)、通信内容の圧縮方法、および拡張領域の6つからなる。乱数は鍵共有におけるリプレイ攻撃を防ぐためのものである。
ServerHelloもClientHelloと同様の6つからなっている（名称は一部異なる）。ServerHelloの主な目的は、ClientHelloで提示された選択肢の中でサーバにとって好ましいものを選択する事で、例えばClientHelloで提示されたcipher_suitesの中から、サーバが通信に使いたいcipher_suiteを一組選ぶ。乱数はClientHelloとは独立して選ぶ。これもリプレイ攻撃を回避するためである。セッションIDは特に問題がなければClientHelloと同一のものを返す。
プロトコル概要 > TLSハンドシェイクプロトコル > 第二フェーズ

第二フェーズではサーバからクライアントに対して鍵共有に必要な情報を送る。具体的にはサーバはCertificate、ServerKeyExchange、CertificateRequest、ServerHelloDoneを（第一フェーズServerHelloに引き続き）クライアントに送信する。
Certificateは鍵共有で用いる公開鍵とその証明書で別途取り決めがない限りX.509v3のフォーマットに従う。なお鍵共有方式としてDH_anonを用いている場合にはcertificateは必要ない。
ServerKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、gx mod pという形のデータを送る。ここでxはサーバの秘密の乱数である。鍵共有プロトコルがDHE_DSS、DHE_RSA、DH_anonでは何らかのserver_key_exchangeを送るが、RSA、DH_DSS、DH_RSAでは何も送らない。
CertificateRequestはクライアントの公開鍵とその証明書を送ることを要求するためのもので、サーバが許容できる証明書の種別、ハッシュと署名方式、および認証局のリストからなっている。
そして最後にサーバ側からのメッセージ送信が終わった事を示すServerHelloDoneをクライアントに送る。
プロトコル概要 > TLSハンドシェイクプロトコル > 第三フェーズ

第三フェーズではクライアントからサーバに対して鍵共有に必要な情報を送る。具体的にはクライアントはCertificate、ClientKeyExchange、CertificateVerifyをサーバに送る。
Certificateは鍵共有で用いるクライアントの公開鍵とその証明書である。証明書はサーバから送られてきたCertificateRequestの条件を満たさねばならない。
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 で署名したものである[要検証]。
プロトコル概要 > TLSハンドシェイクプロトコル > 第四フェーズ

クライアントは必要ならChange Cipher Spec プロトコルのメッセージをサーバに送り、終了を意味するFinishedをサーバに送る。同様にサーバも必要ならChange Cipher Spec プロトコルのメッセージをクライアントに送り、終了を意味するFinishedをクライアントに送る。
プロトコル概要 > TLSレコードプロトコル

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を用いる。
バージョン

コンピュータの計算能力の向上とともに、認証の突破、暗号の解読、改竄も以前よりは容易に行えるようになり、セキュリティ確保のための技術も厳しさを増している。
2017年現在では、TLS 1.2 以上のバージョンの実装が推奨され、TLS 1.1 以下のサポートを停止するサイトも出てきている。2021年3月にはRFC 8996により、TLS 1.0〜TLS 1.1の使用禁止が求められている。
| Defined> バージョン | Defined> 年 |
| --- | --- |
SSL 1.0: n/a
SSL 2.0: 1995
SSL 3.0: 1996
TLS 1.0: 1999
TLS 1.1: 2006
TLS 1.2: 2008
TLS 1.3: 2018
バージョン > SSL 1.0

ネットスケープコミュニケーションズ社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな脆弱性が発見され、破棄された。このため、2018年現在ではSSL 1.0を実装した製品はない。
バージョン > SSL 2.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以降へ対応する動きが広まっている。
SSL 2.0にはチェーン証明書がなく、ルートCAから発行したSSLサーバ証明書しか使うことができない。
2011年3月、RFC 6176 によってSSL 2.0の使用は禁止された。
バージョン > SSL 3.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については、使うべきではない。
バージョン > TLS 1.0

IETFのTLSワーキンググループはRFC 2246としてTLS 1.0を公表した。TLS 1.0の標準化作業は1996年に開始され、年内に完了する予定だったが、いくつかの問題に阻まれ、公表は1999年まで遅延した。
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となっている。
バージョン > TLS 1.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をサポートしない旨を発表した。
ネゴシエーションにおけるバージョン番号は3.2となっている。
バージョン > TLS 1.2

2008年8月にRFC 5246としてTLS 1.2が制定された。ハッシュのアルゴリズムにSHA-256が追加されたほか、ブロック暗号について、従来のCBCモードだけではなく、GCM、CCMといった認証付き暗号を用いたcipher suiteが利用可能となった。また、AESに関する記述がRFC 5246自体に含まれるようになった。
ネゴシエーションにおけるバージョン番号は3.3となっている。
バージョン > TLS 1.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に落ち着いた。
暗号スイート

TLSではハンドシェイクプロトコルのClientHello・ServerHelloで、以後の通信で用いる暗号スイート (ciphersuite) を決定する。TLS 1.2を策定しているRFC 5246では、暗号スイートを以下のフォーマットで表現している：
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
これは次の意味である。
鍵共有方式として以下のものを用いる：
EDH（Ephemeral Diffie-Hellman、後述）の通信に
DSS署名したもの
認証暗号として平文にMACをつけた後に共通鍵暗号化する（いわゆるMAC-then-Encrypt (MtE) 型）のもので
共通鍵暗号としてCBCモードの256ビット鍵AESを用い、
MACとしてはSHA256ハッシュ関数をベースとしたHMACを用いる
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は中間者攻撃に対して脆弱であることから安全とはみなされていない。
DH-ANON (Anonymous DH)、ECDH-ANON (Anonymous ECDH) はそれぞれ、送信データに署名する事なくDH鍵共有、ECDH鍵共有を行う方式である。
DHE-***はEphemeral DHと呼ばれるもので、鍵共有の際クライアント、サーバがx、yをランダムに選び、gx、gyを計算し、これらに署名文をつけた上で交換しあう方式である。gx、gyにつける署名文を作成する署名方式は「***」の部分に記載されたものを使う。ECDHE-***はDHEの楕円DH版である。
DH-***はFixed DHもしくはnon-interactive DHと呼ばれるもので、Diffie-Hellmanで用いるパラメータ（クライアントのgx、サーバのgy）がクライアントやサーバの公開鍵として認証局から公開鍵証明書を受け取っているケースのDiffie-Hellman鍵共有である。gx、gyに対する公開鍵証明書内の署名文を作成する署名方式は「***」の部分に記載されたものを使う。ECDH-*** (Fixed ECDH) はFixed DHの楕円DH版である。
RSA-***はランダムに選んだ共有鍵をサーバの公開鍵でRSA暗号化し、暗号文を「***」で指定された署名方式で署名したものをClientKeyExchangeにおいてクライアントがサーバに送る方式である。（ServerKeyExchangeでは何も送らない）。
いずれの鍵共有においても共有された鍵 (premaster secret) を用いた擬似ランダム関数にクライアントが選んだ乱数とサーバが選んだ乱数等を並べたものを入力する事で最終的なmaster secretを得る。これによりリプレイ攻撃を防いでいる。
これらの鍵共有方式の対応状況は以下のとおりである：
| アルゴリズム | SSL 2> 0 | SSL 3> 0 | TLS 1> 0 | TLS 1> 1 | TLS 1> 2 | TLS 1> 3 | 状況 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| RSA | 対応 | 対応 | 対応 | 対応 | 対応 | 非対応 | TLS 1.2向けにRFCで定義済み |
| DH-RSA | 非対応 | 対応 | 対応 | 対応 | 対応 | 非対応 | TLS 1.2向けにRFCで定義済み |
| DHE-RSA (forward secrecy) | 非対応 | 対応 | 対応 | 対応 | 対応 | 対応 | TLS 1.2向けにRFCで定義済み |
| ECDH-RSA | 非対応 | 非対応 | 対応 | 対応 | 対応 | 非対応 | TLS 1.2向けにRFCで定義済み |
| ECDHE-RSA (forward secrecy) | 非対応 | 非対応 | 対応 | 対応 | 対応 | 対応 | TLS 1.2向けにRFCで定義済み |
| DH-DSS | 非対応 | 対応 | 対応 | 対応 | 対応 | 非対応 | TLS 1.2向けにRFCで定義済み |
| DHE-DSS (forward secrecy) | 非対応 | 対応 | 対応 | 対応 | 対応 | 非対応 | TLS 1.2向けにRFCで定義済み |
| ECDH-ECDSA | 非対応 | 非対応 | 対応 | 対応 | 対応 | 非対応 | TLS 1.2向けにRFCで定義済み |
| ECDHE-ECDSA (forward secrecy) | 非対応 | 非対応 | 対応 | 対応 | 対応 | 対応 | TLS 1.2向けにRFCで定義済み |
| PSK（英語版） | 非対応 | 非対応 | 対応 | 対応 | 対応 |  | TLS 1.2向けにRFCで定義済み |
| PSK（英語版）-RSA | 非対応 | 非対応 | 対応 | 対応 | 対応 |  | TLS 1.2向けにRFCで定義済み |
| DHE-PSK（英語版） (forward secrecy) | 非対応 | 非対応 | 対応 | 対応 | 対応 | 対応 | TLS 1.2向けにRFCで定義済み |
| ECDHE-PSK（英語版） (forward secrecy) | 非対応 | 非対応 | 対応 | 対応 | 対応 | 対応 | TLS 1.2向けにRFCで定義済み |
| SRP（英語版） | 非対応 | 非対応 | 対応 | 対応 | 対応 |  | TLS 1.2向けにRFCで定義済み |
| SRP（英語版）-DSS | 非対応 | 非対応 | 対応 | 対応 | 対応 |  | TLS 1.2向けにRFCで定義済み |
| SRP（英語版）-RSA | 非対応 | 非対応 | 対応 | 対応 | 対応 |  | TLS 1.2向けにRFCで定義済み |
| KRB5 | 非対応 | 非対応 | 対応 | 対応 | 対応 |  | TLS 1.2向けにRFCで定義済み |
| DH-ANON（安全ではない） | 非対応 | 対応 | 対応 | 対応 | 対応 |  | TLS 1.2向けにRFCで定義済み |
| ECDH-ANON（安全ではない） | 非対応 | 非対応 | 対応 | 対応 | 対応 |  | TLS 1.2向けにRFCで定義済み |
| GOST R 34.10-94 / 34.10-2001 | 非対応 | 非対応 | 対応 | 対応 | 対応 |  | RFC草稿で提案中 |
事前共有鍵（英語版）を用いた TLS_PSK、Secure Remote Password protocol（英語版）を用いた TLS_SRP、ケルベロス認証を用いた KRB5 も存在する。
独立国家共同体のGOST規格によって規定された鍵共有アルゴリズムであるGOST R 34.10も提案されている（同じGOST規格による暗号化・改竄検出アリゴリズムとの組み合わせに限定）。
暗号スイート > 認証暗号 > MAC

TLS/SSLの各バージョンで使用できるMACの選択肢は以下のとおりである。下欄の「AEAD」（Authenticated Encryption with Associated Data、認証暗号）は、共通鍵暗号として認証暗号を選んでいるのでMACを用いない事を意味する。
| アルゴリズム | SSL 2> 0 | SSL 3> 0 | TLS 1> 0 | TLS 1> 1 | TLS 1> 2 | TLS 1> 3 | 状況 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| HMAC-MD5 | 対応 | 対応 | 対応 | 対応 | 対応 | 非対応 | TLS 1.2向けにRFCで定義済み |
| HMAC-SHA1 | 非対応 | 対応 | 対応 | 対応 | 対応 | 非対応 | TLS 1.2向けにRFCで定義済み |
| HMAC-SHA256/384 | 非対応 | 非対応 | 非対応 | 非対応 | 対応 | 非対応 | TLS 1.2向けにRFCで定義済み |
| AEAD | 非対応 | 非対応 | 非対応 | 非対応 | 対応 | 対応 | TLS 1.2向けにRFCで定義済み |
| GOST 28147-89 IMIT（英語版） | 非対応 | 非対応 | 対応 | 対応 | 対応 | 非対応 | RFC草稿で提案中 |
| GOST R 34.11-94（英語版） | 非対応 | 非対応 | 対応 | 対応 | 対応 | 非対応 | RFC草稿で提案中 |
独立国家共同体のGOST規格によって規定されたアルゴリズムであるGOST 28147-89に基づくMACおよび、GOST R 34.11も提案されている（同じGOST規格による鍵共有・暗号化アリゴリズムとの組み合わせに限定）。
実装 > ウェブサイト

| プロトコル | ウェブサイトにおけるサポート | セキュリティ |
| --- | --- | --- |
| SSL 2.0 | 0.2% | 安全ではない |
| SSL 3.0 | 1.7% | 安全ではない |
| TLS 1.0 | 29.5% | 暗号アルゴリズムおよび脆弱性への対処による |
| TLS 1.1 | 31.8% | 暗号アルゴリズムおよび脆弱性への対処による |
| TLS 1.2 | 99.9% | 暗号アルゴリズムおよび脆弱性への対処による |
| TLS 1.3 | 66.2% | 安全 |
1 2 3  #暗号スイートを参照のこと
1 2 3  #ウェブブラウザおよび#TLS/SSLの既知の脆弱性を参照のこと