sbintuitions/JSQuAD huggingface dataset:
茶道
他方でこのような遊芸化の傾向に対して、本来の茶道の目的である「人をもてなす際に現れる心の美しさ」が強調されるようになる。この際に大徳寺派の臨済宗寺院が大きな役割を果たし、利休流茶道の根本とされる「和敬清寂」という標語もこの過程で生み出された。各流派による点前の形態や茶会様式の体系化といった様式の整備に加えて、「人をもてなす事の本質とは」と言った茶道本来の精神を見直すことによって、現在「茶道」と呼んでいる茶の湯が完成したのである。

質問: 他方でこのような遊芸化の傾向に対するのは何か
回答: 茶道

質問: 本来の茶道の目的は
回答: 「人をもてなす際に現れる心の美しさ」

質問: 茶道の目的は？
回答: 人をもてなす際に現れる心の美しさ

質問: 利休流茶道の根本とされる標語は？
回答: 和敬清寂

質問: 利休流茶道の根本とされる標語は
回答: 和敬清寂
茶道
明治時代になると、封建制度が崩壊し、諸藩に庇護されていた各流派が財政的に困難に陥るようになった。そうした中、裏千家13代円能斎鉄中は一時東京に居を移して茶道再興に努めた。努力の甲斐あって有力財界人の関心を呼び、茶道が女子の教養科目として組み込まれた。このため茶道は、本来のわび茶とは別の「女子の教養」としての要素も獲得し、今では美しい着物姿での華やかな茶会が当たり前になっている。また明治の同時期に鳥尾得庵、田中仙樵（後に大日本茶道学会を創設）は、利休が千家三流派など各流派へ茶道を分けたのではなく元々一つの流であったと唱え、多くの流儀の茶人達の旧幕時代からの伝承を一堂に集めて研究し、その成果を一般人へ発表することで日本の茶道を再び創り出そうとした。

質問: 明治時代に崩壊した制度は？
回答: 封建制度

質問: 裏千家13代はだれ
回答: 円能斎鉄中

質問: 裏千家13代目はだれか。
回答: 円能斎鉄中

質問: 裏千家13代は
回答: 円能斎鉄中

質問: 明治時代になると、封建制度が崩壊し、諸藩に庇護されていた各流派が財政的に困難に陥るようになったのは何か
回答: 茶道
春秋左氏伝
儒学者を中心とする伝統的な説では、『左伝』の作者は、孔子と同時代の魯の太史であった左丘明であるとされたが、伝説とされている。また『史記』の中に『左氏春秋』という書物名が見えるが、これが現行の『春秋左氏伝』と同一のものであったかどうかも異論がある。

質問: 『史記』の中に何という書物名が見える？
回答: 左氏春秋

質問: 儒学者を中心とする伝統的な説で『左伝』の作者は
回答: 左丘明

質問: 『左伝』の作者
回答: 左丘明

質問: 『左伝』の作者は伝説にて誰となっているか？
回答: 孔子と同時代の魯の太史であった左丘明
春秋左氏伝
前漢末の劉歆は『左伝』を好み、学官に立てるように努力した。後漢に入ると今文と古文の対立によって批判されつつも、多くの学者が『左伝』を学ぶようになった。後にこれに対して、康有為らの清代後期の公羊学者は、『春秋左氏伝』を劉歆による偽作であり、自らが擁立していた王莽の漢王朝乗っ取りの根拠にしたのだと主張した。

質問: 前漢末の劉歆が好んだ
回答: 左伝

質問: 後漢に入ってから多くの学者が学ぶようになった書物は何か？
回答: 左伝

質問: 前漢末の劉歆が好んだのは
回答: 左伝

質問: 前漢末の劉歆が好んだのは
回答: 『左伝』

質問: 前漢末の劉歆は何の書物を好んだ？
回答: 左伝
春秋左氏伝
ベルンハルド・カールグレンは、『左伝』の言語が魯の方言と異なることを明らかにし、『左伝』は先秦の文献ではあるが、伝統的な説でいうように孔子やその門人による著作でもないと結論づけた。津田左右吉は前漢末に『史記』などを元にして『左伝』が作られたと考えたが。後に鎌田正は『左伝の成立と其の展開』（1963年 大修館書店）においてこれらの偽作説を否定し、戦国時代の魏で作られたと考えた。しかし、劉歆がどの程度『左伝』に手を入れたかについては結論が出ていない。

質問: 『左伝』の言語が魯の方言と異なることを明らかにしたのは誰？
回答: ベルンハルド・カールグレン

質問: 『左伝』の言語が魯の方言と異なることを明らかにした人物
回答: ベルンハルド・カールグレン

質問: 『左伝の成立と其の展開』の著者は
回答: 鎌田正

質問: 鎌田正が提唱した左伝の作られた時代と国は何か？
回答: 戦国時代の魏

質問: 『左伝』の言語が魯の方言と異なることを明らかにしたのは
回答: ベルンハルド・カールグレン
春秋左氏伝
『左伝』は『公羊伝』『穀梁伝』と異なり、かならずしも『春秋』経本文の注釈にはなっておらず、『春秋』とは無関係な記事も多いが、最も古い形を残しているとされる。そのため『春秋』の解釈書というよりは、春秋時代の歴史書とみなす説も多くある。また、『公羊伝』『穀梁伝』が哀公14年（紀元前481年）春の「西狩獲麟（せいしゅかくりん）」の記事で終わっているのに対し、『左伝』では経を哀公16年の孔子の死まで補い、伝を哀公27年まで記している。

質問: 左伝は春秋の解釈書以外に何とみなす説が多くあるか？
回答: 春秋時代の歴史書

質問: 『公羊伝』『穀梁伝』が哀公14年（紀元前481年）春の何の記事で終わっているか
回答: 西狩獲麟（せいしゅかくりん）

質問: 最も古い形を残しているとされる書物は？
回答: 左伝

質問: 孔子の死はいつか
回答: 哀公16年

質問: 哀公14年は西暦は
回答: 紀元前481年
春秋左氏伝
豊富な資料を元にし、詳細に『春秋』を補っており、現在の春秋時代を理解する重要な資料とされている。特に、当時の戦争に関する記載は詳細である。また、同時期を扱った歴史書『国語』は『左伝』と一対の作品とみなす説があり、『春秋外伝』とも呼ばれた。

質問: 『国語』は別名？
回答: 春秋外伝

質問: 『左伝』と一対の作品とみなす説がある同時期を扱った歴史書は何か
回答: 国語

質問: 豊富な資料を元にし、詳細に『春秋』を補っており、現在の春秋時代を理解する重要な資料とされているのは？
回答: 春秋左氏伝

質問: 歴史書『国語』は『左伝』と一対の作品とみなす説があり別名何と呼ばれていましたか。
回答: 春秋外伝
春秋左氏伝
『春秋』の注釈として前漢では公羊伝・穀梁伝が学官に立てられていたが、新では劉歆が『左伝』を学官に立てた。後漢では学官に立てられなかったが、服虔が訓詁学に基づいて注をつくるなどして、やがて公羊学を圧倒した。西晋では杜預が『春秋』経文と『左伝』とを一つにして注釈を施した『春秋経伝集解』を作り、以後、春秋学のスタンダードとなった。唐代には『春秋経伝集解』に対する疏の『春秋左伝正義（春秋正義）』（『五経正義』の一つ）が作られた。南宋の儒学者朱熹は「左伝は史学、公・穀は経学」と述べ、『左伝』を歴史書として考えている。

質問: 唐代には『春秋経伝集解』に対する疏の何が作られたか？
回答: 春秋左伝正義（春秋正義）

質問: 『春秋』経文と『左伝』とを一つにして注釈を施した書物は何ですか。
回答: 春秋経伝集解

質問: 春秋左伝正義が作られたのは？
回答: 唐代

質問: 西晋で作られた、杜預が『春秋』経文と『左伝』とを一つにして注釈を施したのは何か
回答: 春秋経伝集解
春秋左氏伝
日本でも古くから読まれており、「鼎の軽重を問う」「風馬牛」など、左伝を根拠とする故事成語は現在日本でもしばしば使われている。特に福澤諭吉は『福翁自伝』で「に私は左傳がでのは左傳十五の内三四卷でふのを私はそ十一度びしてい處はして居た」と述べている。

質問: 『福翁自伝』で「に私は左傳がでのは左傳十五の内三四卷でふのを私はそ十一度びしてい處はして居た」と述べているのはだれ？
回答: 福澤諭吉

質問: 日本でも古くから読まれており、「鼎の軽重を問う」「風馬牛」など、左伝を根拠とする故事成語は現在日本でもしばしば使われている書物は何ですか。
回答: 春秋左氏伝

質問: 福澤諭吉が「に私は左傳がでのは左傳十五の内三四卷でふのを私はそ十一度びしてい處はして居た」と述べているのは何か
回答: 福翁自伝

質問: 「鼎の軽重を問う」の根拠となる書物は？
回答: 左伝
Transport_Layer_Security
Transport Layer Security（トランスポート・レイヤー・セキュリティ、TLS）は、インターネットなどのコンピュータネットワークにおいてセキュリティを要求される通信を行うためのプロトコルである。主な機能として、通信相手の認証、通信内容の暗号化、改竄の検出を提供する。TLSはIETFによって策定された。

質問: インターネットなどのコンピュータネットワークにおいてセキュリティを要求される通信を行うためのなにか
回答: プロトコル

質問: Transport Layer Securityは、インターネットなどのコンピュータネットワークにおいてセキュリティを要求される通信を行うための何であるか？
回答: プロトコル
Transport_Layer_Security
当プロトコルは（特に区別する場合を除いて）SSL (Secure Sockets Layer) と呼ばれることも多い。これは、TLSの元になったプロトコルがSSLであり、そのSSLという名称が広く普及していることによる。

質問: Transport_Layer_Securityは何と呼ばれることも多いですか？
回答: SSL
Transport_Layer_Security
TLSは公開鍵証明書を用いて認証を行い、なりすましを極力排除しようとする。しかしシステムの自動的な対応には限界があり、すべてのなりすましを検出できるわけではない。

質問: Transport_Layer_Securityは何を用いて認証するか
回答: 公開鍵証明書

質問: TLSがなりすましを防ぐために行っている認証は？
回答: 公開鍵証明書

質問: TLSで行う理由は何なのか。
回答: なりすましを極力排除

質問: それを証しするものは
回答: 証明書

質問: TLSは何を用いて認証を行う？
回答: 公開鍵証明書
Transport_Layer_Security
TLSで認証を行うためには、認証局の署名に加えて、証明書の発行先を確認する必要がある。確認しない場合、サーバAの管理権限を持たない者がサーバBとして正当な証明書を取得し、その証明書を使ってサーバAを名乗ることができてしまう。TLS用のサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。

質問: 取引先のことを何というか。
回答: クライアント

質問: TLSで認証を行うために必要なものは?
回答: 認証局の署名

質問: 認証局の署名に加えて、証明書の発行先を確認する必要があるのは何で認証を行うため？
回答: TLS

質問: TLSの認証に必要なのは、認証局の署名の他に何があるか？
回答: 証明書の発行先を確認する
Transport_Layer_Security
現実には「正当な」サーバであっても、これらの検証において「問題がある」と判断される証明書を使って運用されているサーバが少なからず存在する。セキュリティ研究者の高木浩光は、このような証明書のことを、オレオレ詐欺をもじって「オレオレ証明書」と呼んで批判している。

質問: 「オレオレ証明書」と呼んで批判している研究者は？
回答: 高木浩光

質問: 近年問題となっている詐欺の手口は
回答: オレオレ詐欺

質問: オレオレ証明書の名付け親は
回答: 高木浩光

質問: 高木浩光氏はどんな人物なのか。
回答: セキュリティ研究者

質問: 問題がある証明書を使用して運用されるサーバの証明書は、何と呼ばれる事があるか？
回答: オレオレ証明書
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へ接続させることができれば、クライアントからは正当な証明書を持ったサーバとしか見えない。

質問: 仮に攻撃者がDNS偽装に成功して接続をサーバBに導くことができたとしても何を入手できない？
回答: サーバ証明書

質問: お客様へ提供されることをなんというか
回答: サービス

質問: 仮にDNS偽装に成功したらどうなるのか。
回答: サーバ証明書を入手できない
Transport_Layer_Security
他の多くの近代暗号と同様に、TLSもまた、暗号としての強度は乱数の品質に依存している。桁数（ビット長）の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている（これは、公開鍵暗号システムにも言える）。もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、総当たり攻撃で解読される可能性が上昇する。通常は、これは実装の問題に起因している。

質問: 他の多くの近代暗号と同様に何もまた、暗号としての強度は乱数の品質に依存している？
回答: TLS

質問: TLSが暗号としての強度が他の暗号と同様、解読される可能性が心配されているのはどんな理由？
回答: 乱数の品質に依存している

質問: 他の多くの近代暗号と同様に、何もまた、暗号としての強度は乱数の品質に依存している？
回答: TLS
Transport_Layer_Security
古い例では、Netscapeの初期の実装における乱数生成の脆弱性がある。プロセスIDや時刻から乱数を生成していることが判明し、これらの情報を取得できる場合には総当たり攻撃の所要時間が大幅に短くなるという問題があった。

質問: Netscapeでは何から乱数を生成していた？
回答: プロセスIDや時刻

質問: Transport_Layer_Securityにおいて、古い例では、Netscapeの初期の実装における何の脆弱性があった？
回答: 乱数生成
Transport_Layer_Security
第一のフェーズではサーバ・クライアント間で通信に必要情報の合意を図る。このフェーズでは、まずクライアントからサーバにClientHelloが送信され、次にサーバからクライアントにServerHelloが送信される。

質問: 第一のフェーズでサーバ・クライアント間で図るのは何か
回答: 通信に必要情報の合意

質問: Transport_Layer_Securityで、クライアントとサーバ通信が交わされるのは第何のフェーズ？
回答: 第一のフェーズ

質問: Transport_Layer_Securityにおいて、第一のフェーズでは何間で通信に必要情報の合意を図る？
回答: サーバ・クライアント

質問: まずクライアントからサーバに何が送信される？
回答: ClientHello
Transport_Layer_Security
ClientHelloはTLSのバージョン、乱数、セッションID、通信に用いる暗号方式やハッシュアルゴリズムのリスト (cipher_suites)、通信内容の圧縮方法、および拡張領域の6つからなる。乱数は鍵共有におけるリプレイ攻撃を防ぐためのものである。

質問: 乱数は鍵共有における何を防ぐためのものですか
回答: リプレイ攻撃

質問: Transport_Layer_Securityで乱数は何を防ぐためにある？
回答: リプレイ攻撃

質問: 何は、TLSのバージョン、乱数、セッションID、通信に用いる暗号方式やハッシュアルゴリズムのリスト (cipher_suites)、通信内容の圧縮方法、および拡張領域の6つからなる？
回答: ClientHello

質問: 乱数は鍵共有における何を防ぐためのもの？
回答: リプレイ攻撃
Transport_Layer_Security
ServerHelloもClientHelloと同様の6つからなっている（名称は一部異なる）。ServerHelloの主な目的は、ClientHelloで提示された選択肢の中でサーバにとって好ましいものを選択する事で、例えばClientHelloで提示されたcipher_suitesの中から、サーバが通信に使いたいcipher_suiteを一組選ぶ。乱数はClientHelloとは独立して選ぶ。これもリプレイ攻撃を回避するためである。セッションIDは特に問題がなければClientHelloと同一のものを返す。

質問: セッションIDは特に問題がなければ何と同一のものを返しますか
回答: ClientHello

質問: ServerHelloとClientHelloいくつからなる？
回答: 6つ

質問: ServerHelloは何をClientHelloとは独立して選ぶ？
回答: 乱数

質問: セッションIDは特に問題がなければ何を返す？
回答: ClientHelloと同一のもの
Transport_Layer_Security
第二フェーズではサーバからクライアントに対して鍵共有に必要な情報を送る。具体的にはサーバはCertificate、ServerKeyExchange、CertificateRequest、ServerHelloDoneを（第一フェーズServerHelloに引き続き）クライアントに送信する。

質問: 何に必要な情報か？
回答: 鍵共有

質問: 第二フェーズではどんなことをしているのか。
回答: 鍵共有に必要な情報を送る
Transport_Layer_Security
TLSは多くの場合、コネクション型のトランスポート層プロトコル（通常はTCP）とアプリケーション層の間で使われる。特にHTTPでの利用を意識して設計されているが、アプリケーション層の特定のプロトコルには依存せず、様々なアプリケーションにおいて使われている。TLS 1.1以降を元にしたプロトコルが、UDPやDCCPといったデータグラム型プロトコル上でも実装されており、こちらはDatagram Transport Layer Security (DTLS) として独立して標準化されている。

質問: UDPやDCCPは何型プロコトルと言われる
回答: データグラム型

質問: TLSは多くの場合、コネクション型のトランスポート層プロトコルと何の間で使われるか？
回答: アプリケーション層

質問: TLSは多くの場合、コネクション型のトランスポート層プロトコル（通常はTCP）と何の間で使われるか
回答: アプリケーション層
Transport_Layer_Security
Certificateは鍵共有で用いる公開鍵とその証明書で別途取り決めがない限りX.509v3のフォーマットに従う。なお鍵共有方式としてDH_anonを用いている場合にはcertificateは必要ない。

質問: 鍵共有で用いる公開鍵とその証明書で別途取り決めがない限りX.509v3のフォーマットに従うのは何
回答: Certificate

質問: Certificateは鍵共有で用いる公開鍵とその証明書で別途取り決めがない限りどうなる
回答: X.509v3のフォーマットに従う

質問: certificateは必要ない場合は何なのか。
回答: DH_anonを用いている場合

質問: 何が必要でないか。
回答: certificate
Transport_Layer_Security
ServerKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、という形のデータを送る。ここではサーバの秘密の乱数である。鍵共有プロトコルがDHE_DSS、DHE_RSA、DH_anonでは何らかのserver_key_exchangeを送るが、RSA、DH_DSS、DH_RSAでは何も送らない。

質問: 鍵共有プロトコルを送らないものは何なのか。
回答: RSA、DH_DSS、DH_RSA

質問: 鍵共有プロトコルに依存して送るデータはなにか。
回答: サーバの秘密の乱数

質問: DH_anonであれば、という形のデータを送るのは何
回答: サーバの秘密の乱数
Transport_Layer_Security
第三フェーズではクライアントからサーバに対して鍵共有に必要な情報を送る。具体的にはクライアントはCertificate、ClientKeyExchange、CertificateVerifyをサーバに送る。

質問: 第三フェーズでは何をしているのか。
回答: 鍵共有に必要な情報を送る

質問: 第何フェーズか。
回答: 第三フェーズ
Transport_Layer_Security
Certificateは鍵共有で用いるクライアントの公開鍵とその証明書である。証明書はサーバから送られてきたCertificateRequestの条件を満たさねばならない。

質問: 鍵共有で用いるクライアントの公開鍵とその証明書は何
回答: Certificate

質問: クライアントの公開鍵とその証明書と言われているものは何なのか。
回答: Certificate

質問: なんの条件を満たさなければならないか。
回答: CertificateRequest
Transport_Layer_Security
ClientKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、という形のデータを送る。ここではクライアントの秘密の乱数である。

質問: クライアントの秘密の何か。
回答: 乱数

質問: ClientKeyExchangeはどんなプロトコルに依存するデータとは異なりますか？
回答: 鍵共有プロトコル

質問: ClientKeyExchangeは鍵共有プロトコルに依存して送るデータが異なる又は同一のどちらか？
回答: 異なる

質問: ClientKeyExchangeはなにに依存して送るデータがことなるか
回答: 鍵共有プロトコル
Transport_Layer_Security
ここまでのプロトコルにより、サーバとクライアントの間でpremaster secretが共有された事になる。DH_anonであればpremaster secretはである。premaster secretを鍵にした擬似ランダム関数にServerHelloとClientHelloの乱数などを並べたものを入力した結果得られたものがmaster secretである。

質問: premaster secretを鍵にした擬似ランダム関数にServerHelloとClientHelloの乱数などを並べたものを入力した結果得られたものは何ですか？
回答: master secret

質問: サーバとクライアントの間で共有されたものとは。
回答: premaster secret

質問: Transport_Layer_Securityにおいては、サーバとクライアントの間で何が共有される？
回答: premaster secret

質問: premaster secretを鍵にした擬似ランダム関数にServerHelloとClientHelloの乱数などを並べたものを入力すると得られるものはなにか
回答: master secret
Transport_Layer_Security
クライアントは必要ならChange Cipher Spec プロトコルのメッセージをサーバに送り、終了を意味するFinishedをサーバに送る。同様にサーバも必要ならChange Cipher Spec プロトコルのメッセージをクライアントに送り、終了を意味するFinishedをクライアントに送る。

質問: サーバも必要ならChange Cipher Spec プロトコルのメッセージをクライアントに送り、終了を意味する何をクライアントに送りますか？
回答: Finished

質問: クライアントに送る終了を意味する単語はなにか
回答: Finished

質問: 終了を意味するものとは。
回答: Finished
Transport_Layer_Security
認証暗号は、TLS 1.1まではMACをつけた後で共通鍵暗号化するMAC-then-Encrypt (MtE) のみが利用可能であった。TLS 1.2からは、AES-GCMのようなAEADに分類される認証暗号専用の暗号利用モードも利用可能になり、TLS 1.3ではAEADのみが利用可能となっている。

質問: TLS 1.3で唯一利用可能なのはなにか
回答: AEAD

質問: TLS 1.3で利用可能なものは。
回答: AEAD

質問: TLS 1.3では、何のみが利用可能ですか？
回答: AEAD
Transport_Layer_Security
認証暗号にブロック暗号（AEAD以外）を選択した場合、TLS 1.1以降においてIVはTLSレコードプロトコルの送信者がランダムに選ぶ。ランダムなIVは、BEAST攻撃への対策として有効である。一方、認証暗号で用いる共通鍵はTLSハンドシェイクプロトコルで共有されたmaster secretを用いる。

質問: ランダムなIVは、BEAST攻撃への対策として無効又は有効のいずれか？
回答: 有効

質問: ランダムなⅣは何に有効であるか
回答: BEAST攻撃への対策

質問: 認証暗号で用いる共通鍵は何を用いるか。
回答: master secret

質問: ランダムなIVは、どんな攻撃への対策として有効ですか？
回答: BEAST攻撃
Transport_Layer_Security
2017年現在では、TLS 1.2 以上のバージョンの実装が推奨され、TLS 1.1 以下のサポートを停止するサイトも出てきている。2021年3月にはRFC 8996により、TLS 1.0～TLS 1.1の使用禁止が求められている。

質問: 2017年現在推奨されているTLSのバージョンは何以上？
回答: 1.2

質問: RFC8996はいつ公開された？
回答: 2021年3月

質問: RFC 8996により、TLS 1.0～TLS 1.1の使用禁止が求められたのはいつ
回答: 2021年3月

質問: Transport_Layer_Securityのサポートの終了はいつ？
回答: 2017年

質問: 2017年現在、推奨されているバージョンは？
回答: TLS 1.2 以上のバージョン
Transport_Layer_Security
TLSはHTTPなどのアプリケーション層のプロトコルと組み合わせることで、HTTPSなどセキュアな通信プロトコルを実現している。そのようなプロトコルとして以下のものがある。

質問: TLSはHTTPなどの何のプロトコルと組み合わせることで、HTTPSなどセキュアな通信プロトコルを実現しているか？
回答: アプリケーション層

質問: アプリケーション層のプロトコルと組み合わせることで、どんな通信を実現している
回答: セキュア

質問: TLSはどんなアプリケーション層のプロトコルと組み合わせることで、HTTPSなどセキュアな通信プロトコルを実現している？
回答: HTTP

質問: TLSはHTTPなどのアプリケーション層の何と組み合わせることで、HTTPSなどセキュアな通信プロトコルを実現しているか
回答: プロトコル
Transport_Layer_Security
ネットスケープコミュニケーションズ社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな脆弱性が発見され、破棄された。このため、2018年現在ではSSL 1.0を実装した製品はない。

質問: SSL 1.0を実装した製品たあるか
回答: 実装した製品はない。

質問: SSLの最初のバージョンを設計した会社は
回答: ネットスケープコミュニケーションズ社

質問: SSLの最初のバージョンを設計していた会社の名前は？
回答: ネットスケープコミュニケーションズ社

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

質問: SSL 1.0の問題を修正して再設計した会社は
回答: ネットスケープコミュニケーションズ社

質問: SSL 2.0として発表したのはいつか
回答: 1994年

質問: ネットスケープコミュニケーションズ社はSSL 1.0の問題を修正して再設計し、SSL 2.0として発表したのはいつか？
回答: 1994年

質問: 1994年にSSL 2.0を発表した会社の名前は？
回答: ネットスケープコミュニケーションズ社

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

質問: 脆弱性を利用し最弱のアルゴリズムを使わせること何という？
回答: ダウングレード攻撃

質問: SSL 2.0にもいくつかの脆弱性が発見されたが、何において修正されたか
回答: SSL 3.0

質問: ネゴシエーションの情報を改竄すると、提示する選択肢のうち最弱のアルゴリズムを使わせることを、何と呼ぶ？
回答: ダウングレード攻撃

質問: SSL 2.0の脆弱性が修正されたバージョンは？
回答: SSL 3.0
Transport_Layer_Security
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

質問: 初期状態でSSL 2.0を無効にしたInternet Explorerのメジャーバージョンは？
回答: 7

質問: Internet Explorer 7やMozilla Firefox 2、Opera 9などは、初期状態で、SSLのどのバージョンを無効にしている？
回答: SSL 2.0
Transport_Layer_Security
ネットスケープコミュニケーションズ社はSSL 2.0の問題を修正するとともに機能追加を行い、1995年にSSL 3.0を発表した。また、Netscape Navigator 2.0においてSSL 3.0を実装した。SSL 3.0の仕様書については、2011年にIETFから歴史的文書という扱いでRFC 6101として公開された。

質問: ネットスケープコミュニケーションズ社がSSL 3.0を発表した年は？
回答: 1995年

質問: ネットスケープコミュニケーションズ社がSLL3.0を発表した年は？
回答: 1995年

質問: ネットスケープコミュニケーションズ社はSSL 3.0をいつ発表したか
回答: 1995年

質問: SSL 3.0の仕様書がIETFから歴史的文書という扱いでRFC 6101として公開されたのはいつか
回答: 2011年
Transport_Layer_Security
2014年10月にSSL 3.0の仕様上の脆弱性（POODLE攻撃）が発見されたため、SSL 3.0への対応を打ち切り、TLS 1.0以降のみ対応への移行が望まれている。2015年6月、RFC 7568によってSSL 3.0の使用は禁止された。

質問: SSL 3.0の仕様上の脆弱性（POODLE攻撃）が発見されたのはいつか
回答: 2014年10月

質問: 2015年6月、RFC 7568によって何の使用が禁止されたか
回答: SSL 3.0

質問: SSL 3.0の使用が禁止された年月は？
回答: 2015年6月

質問: 2015年6月、SSL 3.0の使用は何によって禁止された？
回答: RFC 7568
Transport_Layer_Security
IETFのTLSワーキンググループはRFC 2246としてTLS 1.0を公表した。TLS 1.0の標準化作業は1996年に開始され、年内に完了する予定だったが、いくつかの問題に阻まれ、公表は1999年まで遅延した。

質問: 1996年に標準化作業が開始されたTLS 1.0の公表はいつか
回答: 1999年

質問: TLS 1.0の標準化作業が完了したのは？
回答: 1999年

質問: TLS 1.0の標準化作業が公表された年は？
回答: 1999年

質問: IETFのTLSワーキンググループはRFC 2246として何を公表したか
回答: TLS 1.0
Transport_Layer_Security
TLS 1.0が提供する機能はSSL 3.0とあまり変わらないが、アルゴリズムやルートCAの自己署名証明書の取扱いなどの仕様の詳細が変更されたことに加え、これまであまり実装されていなかった選択肢のいくつかが必須と定められた。このため、TLS 1.0を実装した製品が普及するまでには、さらに数年を要した。

質問: TLS 1.0が提供する機能は何ややルートCAの自己署名証明書の取扱いなどの仕様の詳細が変更されたか
回答: アルゴリズム

質問: TLS 1.0を実装した製品はすぐ普及しましたか
回答: さらに数年を要した
Transport_Layer_Security
2006年にRFC 4346としてTLS 1.1が制定された。TLS 1.0からの変更点は、新しく発見された攻撃手法に対する耐性の強化が中心である。特にCBC攻撃に対する耐性を上げるため、初期化ベクトルを明示的に指定することにし、さらにパディングの処理も改善された。また、予期せぬ回線クローズ後に、セッションを再開できるようになった。共通鍵暗号アルゴリズムとしてAESが選択肢に加わった。

質問: 共通鍵暗号アルゴリズムとして選択肢に加わったのは？
回答: AES

質問: RFC 4346としてTLS 1.1が制定されたのはいつか
回答: 2006年

質問: RFC 4346としてTLS 1.1が制定された年は？
回答: 2006年

質問: RFC 4346としてTLS 1.1が制定されたのは何年か
回答: 2006年

質問: 2006年にRFC 4346として制定されたのは？
回答: TLS 1.1
Transport_Layer_Security
2008年8月にRFC 5246としてTLS 1.2が制定された。ハッシュのアルゴリズムにSHA-256が追加されたほか、ブロック暗号について、従来のCBCモードだけではなく、GCM、CCMといった認証付き暗号を用いたcipher suiteが利用可能となった。また、AESに関する記述がRFC 5246自体に含まれるようになった。

質問: RFC 5246としてTLS 1.2が制定されたのはいつか。
回答: 2008年8月

質問: RFC 5246としてTLS 1.2が制定されたのはいつか
回答: 2008年8月

質問: ハッシュのアルゴリズムについかされたものは？
回答: SHA-256

質問: RFC 5246としてTLS 1.2が制定されたのは2008年の何月か
回答: 8月
Transport_Layer_Security
既存のアプリケーション層プロトコルでTLSを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにTLSのネゴシエーションを開始し、TLS接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式である。切り替えコマンドとしてcodice_1が広まっているため、この方式自体をSTARTTLSと呼ぶこともある。

質問: 既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式の呼び名は？
回答: STARTTLS

質問: 既存のアプリケーション層プロトコルでTLSを利用する場合、大きく何種類の適用方式が考えられるか
回答: 2つ
Transport_Layer_Security
TLS 1.2からの変更点としては、[[データ圧縮]]の非サポート、[[forward secrecy]]ではないcipher suite（RSAのみを用いたもの）および[[認証付き暗号]]ではないcipher suite（[[暗号利用モード#CBC|CBCモード]]の[[ブロック暗号]]や[[RC4]]を用いたもの）の廃止が挙げられる。なお名称をTLS 2.0やTLS 4等に変更することが検討されたが、最終的にTLS 1.3に落ち着いた。

質問: TLS 1.2からの変更されたTransport_Layer_Securityの最終的な名称は何か
回答: TLS 1.3

質問: Transport_Layer_Securityの名称は最終的になんとなったか
回答: TLS 1.3
Transport_Layer_Security
TLSではハンドシェイクプロトコルのClientHello・ServerHelloで、以後の通信で用いる暗号スイート (ciphersuite) を決定する。TLS 1.2を策定しているRFC 5246では、暗号スイートを以下のフォーマットで表現している：

質問: TLSではハンドシェイクプロトコルのClientHello・ServerHelloで、以後の通信で用いるなにを決定しているか
回答: 暗号スイート
Transport_Layer_Security
TLS1.2では認証暗号としてMtE型のもののみならず、AES-GCMのような認証暗号専用に作られた暗号利用モードも用いる事ができるようになった。この場合MACはそもそも必要ない。

質問: TLS1.2で用いることが可能になったモードとは
回答: 暗号利用モード

質問: TLS1.2では認証暗号としてMtE型のもののみならず、AES-GCMのような認証暗号専用に作られた何モードを用いることでができるようになったか。
回答: 暗号利用モード

質問: TLS1.2では認証暗号としてMtE型のもののみならず、認証暗号専用に作られた暗号利用モードも用いる事ができるようになったものは何か
回答: AES-GCM
Transport_Layer_Security
SSL/TLS（の1つ以上のバージョンで）使用できる鍵共有方式は以下のとおりである。ここでDHは[[ディフィー・ヘルマン鍵共有|Diffie-Hellman]]の事である。なおDH-ANON、ECDH-ANONは[[中間者攻撃]]に対して脆弱であることから安全とはみなされていない。

質問: DH-ANON、ECDH-ANONは何に対して脆弱であるか。
回答: 中間者攻撃

質問: SSL/TLS（の1つ以上のバージョンで）使用できる鍵共有方式で脆弱であるものを一つあげよ
回答: ECDH-ANON
Transport_Layer_Security
いずれの鍵共有においても共有された鍵 (premaster secret) を用いた擬似ランダム関数にクライアントが選んだ乱数とサーバが選んだ乱数等を並べたものを入力する事で最終的なmaster secretを得る。これによりリプレイ攻撃を防いでいる。

質問: Transport_Layer_Securityではどんな攻撃を防いでいますか？
回答: リプレイ攻撃

質問: 最終的なmaster secretを得ることにより何攻撃を防いでいるか？
回答: リプレイ攻撃

質問: Transport_Layer_Securityにおいて共有された鍵を何と呼ぶか？
回答: premaster secret

質問: 共有された鍵 (premaster secret) を用いた擬似ランダム関数にクライアントが選んだ乱数とサーバが選んだ乱数等を並べたものを入力する事で最終的な何を得る
回答: master secret

質問: master secretを得る事で何の攻撃を防ぎますか？
回答: リプレイ攻撃
Transport_Layer_Security
[[Advanced Encryption Standard|AES]] CBCはTLS 1.0を定義する RFC 2246 には含まれていないが、RFC 3268 で追加された。TLS 1.1を定義する RFC 4346 からは RFC 3268 が参照されており、さらにTLS 1.2では定義である RFC 5246 にAES CBCに関する記述が取り込まれた。また、[[認証付き暗号]]による[[Advanced Encryption Standard|AES]] [[Galois/Counter Mode|GCM]] (RFC 5288, RFC 5289)、[[Advanced Encryption Standard|AES]] [[Counter with CBC-MAC|CCM]] (RFC 6655, RFC 7251) が追加されている。[[International Data Encryption Algorithm|IDEA]] CBC、[[Data Encryption Standard|DES]] CBCはTLS 1.2で廃止された（RFC 5469 に解説がある）。

質問: Transport_Layer_Securityにおいて、CBCはTLS 1.0を定義する RFC 2246 には含まれていないが、何で追加されたか？
回答: RFC 3268

質問: TLS 1.1を定義する RFC 4346 からは、何が参照されている
回答: RFC 3268

質問: CBCは何で追加されましたか？
回答: RFC 3268
Transport_Layer_Security
[[ブロック暗号]]の[[暗号利用モード#CBC|CBCモード]]での利用については、TLS 1.0以前において[[#BEAST攻撃|BEAST攻撃]]と呼ばれる攻撃が可能であることが明らかとなっており、クライアント側、サーバ側での対応が必要とされている。TLS 1.1以降ではこの攻撃への根本的な対処として[[初期化ベクトル]]を明示的に指定し、パディングの処理が改善された。ブロック暗号であっても[[Galois/Counter Mode|GCM]]、[[Counter with CBC-MAC|CCM]]などの[[認証付き暗号]]を用いる場合にはこれらの攻撃を受けない。

質問: [[初期化ベクトル]]を明示的に指定し、パディングの処理が改善されたのは何以降ですか？
回答: TLS 1.1

質問: TLS 1.0以前においてどんな攻撃が可能であるか
回答: BEAST攻撃

質問: TLS 1.1以降では根本的な対処として[[初期化ベクトル]]を明示的に指定したことにより、何の処理が改善されたか？
回答: パディング

質問: BEAST攻撃への対処として何が明示されていますか？
回答: 初期化ベクトル
Transport_Layer_Security
[[ストリーム暗号]]である[[RC4]]は前述のBEAST攻撃を受けることはないが、RC4には仕様上の脆弱性が存在する（[[#RC4攻撃|RC4攻撃]]）。2015年2月、TLSのすべてのバージョンにおいてRC4の利用を禁止する RFC 7465 が公開された。ストリーム暗号である[[ChaCha20]]と認証のための[[Poly1305]]を組み合わせたChaCha20+Poly1305が RFC 7905 として標準化されている。

質問: Transport_Layer_Securityにおいて、TLSのすべてのバージョンにおいてRC4の利用を禁止する RFC 7465 が公開されたのはいつか？
回答: 2015年2月

質問: [[ストリーム暗号]]である[[RC4]]は何の攻撃を受けることは無いですか？
回答: BEAST攻撃

質問: RC4には仕様上の何が存在する
回答: 脆弱性

質問: RC4やChaCha20は何暗号とよばれますか？
回答: ストリーム暗号

質問: RFC 7465 が公開された年月は？
回答: 2015年2月
Transport_Layer_Security
いくつかの国家標準に基づく暗号化アルゴリズムもTLSで利用可能であり、[[日本]]の[[CRYPTREC]]による推奨暗号である[[Camellia]]（CBCモード：RFC 4132、RFC 5932、RFC 6367、GCM：RFC 6367）、[[大韓民国|韓国]]の情報通信標準規格に採用されている[[SEED (暗号)|SEED]]（CBCモード：RFC 4162）、[[ARIA (暗号)|ARIA]]（CBCモードおよびGCM：RFC 6209）が追加されている。また、[[独立国家共同体]]の[[GOST規格]]によって規定された暗号化アルゴリズムであるGOST 28147-89も提案されている。

質問: いくつかの国家標準に基づく暗号化アルゴリズムは何で利用可能ですか？
回答: TLS

質問: いくつかの国家標準に基づく何がTLSで利用可能か
回答: 暗号化アルゴリズム

質問: Transport_Layer_Securityにおいて、いくつかの国家標準に基づく何がTLSで利用可能であるか？
回答: 暗号化アルゴリズム

質問: 日本のCRYPTRECによる推奨暗号は？
回答: Camellia

質問: 日本のCRYPTRECによる推奨暗号はなんですか？
回答: Camellia
Transport_Layer_Security
SSLが設計された当時は、[[アメリカ合衆国]]によって[[アメリカ合衆国からの暗号の輸出規制|高強度暗号アルゴリズムの輸出が規制されていた]]。そのため、全世界で共通して利用できるアルゴリズムとして、DES・[[RC2]]・RC4に関して暗号強度を40ビットに制限したものが導入されていた。これらはTLS 1.1以降では利用が禁止されている。

質問: 全世界で利用できたアルゴリズムは何か
回答: DES・[[RC2]]・RC4

質問: 高強度暗号何の輸出が規制されてた
回答: アルゴリズム

質問: 全世界で利用できるアルゴリズムとして、DES・[[RC2]]・RC4に関して暗号強度は何ビットに制限されたものだったか？
回答: 40ビット
Transport_Layer_Security
前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、平文で接続を開始する実装と共存できなくなるため、既存のポート番号とは別にTLS対応用のポート番号が必要となる。実態としては、SSL/TLSの最初の適用例であるHTTPSをはじめとして、前者の方式を使うことが多い。ただし、この方式はバーチャルホストを構成する際に問題となる可能性がある。詳細は#バーチャルホストの節を参照。

質問: SSL/TLSの最初の適用例である技術の名は？
回答: HTTPS

質問: SSL/TLSの最初の適用例は何か
回答: HTTPS
Transport_Layer_Security
TLS/SSLの各バージョンで使用できるMACの選択肢は以下のとおりである。下欄の「AEAD」（Authenticated Encryption with Associated Data、認証暗号）は、共通鍵暗号として認証暗号を選んでいるのでMACを用いない事を意味する。

質問: AEADはMACを用いるか？
回答: 用いない

質問: TLS/SSLの各バージョンで使用できるMACの選択肢
回答: AEAD

質問: 共通鍵暗号として認証暗号を選んでいるので何を用いない事意味してる
回答: MAC

質問: 共通鍵暗号でMACを用いてないのは何を選んでいるか
回答: 認証暗号

質問: 「AEAD」（Authenticated Encryption with Associated Data、認証暗号）は、共通鍵暗号として何をを選んでいるのでMACを用いない事を意味するか？
回答: 認証暗号
Transport_Layer_Security
TLSは、TCP/IPネットワークでホスト名ベースの[[バーチャルホスト]]を構成する際に問題となる。TCP/IPでは通信を開始する前にホスト名を[[名前解決|解決]]し、実際には[[IPアドレス]]とポート番号で接続先を識別している。このためTLSのネゴシエーションの時点では、バーチャルホストのうちどのホスト名を期待しているのか判断できず、ホスト名ごとに異なるサーバー証明書を使い分けることができない。

質問: TCP/IPはIPアドレスとなにで接続先を識別しているか？
回答: ポート番号

質問: TLSは、TCP/IPネットワークでホスト名ベースの[[バーチャルホスト]]を構成する際に問題となるため実際はどのように接続先を判断しているか
回答: [[IPアドレス]]とポート番号

質問: ホスト名ごとに異なる何を使い分けることができない。
回答: サーバー証明書
Transport_Layer_Security
TLSの拡張機能を定義するRFC 6066では、ネゴシエーション時にホスト名を伝える手段として[[Server Name Indication]] (SNI) を規定している。用例としては、[[HTTP]]の最新バージョンである[[HTTP/2]]においてTLSを利用する際はSNIの利用が必須とされている。

質問: HTTP/2においてTLSを利用する際に何が必須とされているか？
回答: SNI

質問: ネゴシエーション時にホスト名を伝える手段とは
回答: SNI

質問: 最新バージョンにおいてTLSを利用する際は何が利用必須
回答: SNI
Transport_Layer_Security
一方、証明書を使い分けず、1つの証明書を複数のバーチャルホストで使い回す方式も広く利用されている。[[X.509]]証明書のフォーマットについて記述した[[RFC5280]]では、発行先ホスト名を保持するsubjectAltNameはひとつの証明書に複数のエントリを作成できると規定している。これを利用して、ホストに収容されたすべてのバーチャルホストに対応したsubjectAltNameを保持する証明書をクライアントに提示すれば良い。

質問: 1つの証明書を複数のバーチャルホストで使い回す方式で、[[X.509]]証明書のフォーマットについて記述した規格名は？
回答: RFC5280

質問: ホストに収容されたすべてのバーチャルホストに対応した何を保持する証明書をクライアントに提示すれば良い
回答: subjectAltName
Transport_Layer_Security
また、発行先ホスト名に[[ワイルドカード (情報処理)|ワイルドカード]]を使う方法も考えられる。HTTP over SSL/TLS (HTTPS) を定義するRFC 2818は、ワイルドカードの適用について記述している。バーチャルホストの対象が、ひとつのドメイン名の中のホストであれば、この方法で対応できる場合もある。

質問: どんな対象文字、ないし文字列にもマッチするもののことを何という？
回答: ワイルドカード

質問: HTTP over SSL/TLS (HTTPS) を定義するのは？
回答: RFC 2818

質問: ワイルドカードの適用について記述しているのはなに？
回答: RFC 2818
Transport_Layer_Security
どの方法も実装によって対応状況にバラつきがあり、環境によっては使えない可能性がある。なおIPアドレスベースのバーチャルホストであれば、ネゴシエーションの時点で確実にどのバーチャルホストを期待しているか判断できるので、問題なく証明書を使い分けることができる。

質問: 証明書を使い分けることができるホストは？
回答: IPアドレスベースのバーチャルホスト

質問: 「安全」を英語でいうと？
回答: Security

質問: IPアドレスベースのバーチャルホストで、どのバーチャルホストを期待しているか判断できるのはどの時点？
回答: ネゴシエーションの時点
Transport_Layer_Security
TLS/SSLに対する攻撃のうち主なものを以下に挙げる。2015年2月に、TLS/SSLに対する既知の攻撃についての情報をまとめたRFC 7457がIETFから公開されている。

質問: IETFで公開されているのはなんの情報？
回答: TLS/SSLに対する既知の攻撃

質問: TLS/SSLに対する既知の攻撃についての情報をまとめたRFC 7457がIETFから公開されたのはいつか？
回答: 2015年2月

質問: TLS/SSLに対する攻撃のうち主なものを以下に挙げる。2015年2月に、TLS/SSLに対する既知の攻撃についての情報をまとめたRFC 7457が公開されているのは？
回答: IETFから

質問: 2015年2月、TLS/SSLに対する既知の攻撃についてまとめたRFC 7457を公開したのは、
回答: IETF

質問: TLS/SSLに対する攻撃は？
回答: RFC 7457
Transport_Layer_Security
RC4もTLSのすべてのバージョンにおいて利用を禁止するRFC 7465が公開された。[[Mozilla]]および[[マイクロソフト]]ではRC4を無効化することを推奨している。

質問: RC4もTLSのすべてのバージョンにおいて利用を禁止する何が公開された？
回答: RFC 7465

質問: [[Mozilla]]および[[マイクロソフト]]で無効化することを推奨しているのは？
回答: RC4

質問: Mozillaおよびマイクロソフトで無効化することを推奨しているのは？？
回答: RC4

質問: 。[[Mozilla]]および[[マイクロソフト]]では何を無効化することを推奨しているか？
回答: RC4を無効化することを推奨している。
Transport_Layer_Security
かつて[[アメリカ合衆国からの暗号の輸出規制]]が厳しかった時期に、規制を回避するために一時的に512ビットのRSA鍵を生成して、そちらで通信を行うというような手法が存在した。この手法については、一時的な公開鍵を[[素因数分解]]することが可能であれば[[中間者攻撃]]が成立することが1998年時点で指摘されていたが、コンピュータの性能向上、[[クラウドコンピューティング]]の普及により素因数分解が個人レベルですら現実的となったこと、さらに[[2015年]]には、[[OpenSSL]]、[[Safari]]、[[Android (オペレーティングシステム)|Android]]などでは輸出用でない暗号スイートでも512ビットの一時鍵を受け入れてしまう実装となっていたことが判明し、FREAK (Factoring RSA Export Keys)として問題が再浮上している。

質問: FREAKとして問題が再浮上してしまった手法はななに？
回答: 512ビットの一時鍵

質問: アメリカ合衆国からの暗号の輸出規制が厳しかった時、規制を回避するため一時的に生成されていたのは？
回答: 512ビットのRSA鍵