以下は、某メルマガに書いた記事です。
オリジナルはこちら
httpsについての番外編です。
ここまで触れてこなかった、httpsの最新動向などについて解説しています。
前回まででhttpsのプロトコル（通信手順）についての解説は終わ りました。 ここまでは、httpsの中のTLSハンドシェイクという手順を中心に 解説をしてきました。 ここまでのhttpsの内容も十分にマニアックでしたが、今回は いきがけの駄賃といいますか、いくつかここまでに触れることが できなかった内容について解説します。 1. TLS1.3 －－－－－ 以前も書いたように、https＝http＋SSL/TLSです。 そのTLSの最新バージョンであるTLS1.3が2018年8月に発表され ました。 この連載の最初にも書きましたが、SSL/TLSは今までにいくつ ものバージョンが発表されています。 SSLには３つのバージョンがあり、いずれも使命を終えています。 内容は下記の通りです。 1.0：これはすぐにバグが見つかったので実際には未使用 2.0：初期にはよく使われたが、脆弱性（文末参照）が見つかり 3.0に移行。2011年に使用禁止となった。 3.0：2.0の後に長く使われたが、脆弱性が見つかりTLS1.0に移行 2015年に使用禁止となった。 このSSLの後継ぎがTLSです。 このTLSのバージョンは次の通りです。 1.0：SSL3.0のバグ修正版。それ以外はほぼSSL3.0と同等 2018年6月末時点で非推奨となった。（使用禁止ではない） 1.1：新たな攻撃方法に対する対策などを包含したバージョン これも1.0と同様の脆弱性が見つかっている 1.2：使用できる暗号化方法の追加などが行われた 1.3：2019年現在の最新版。古い暗号化方法の廃止、通信手順の 変更などが行われた 上ではサラリと書いていますが、TLS1.3にて通信手順が大巾に改訂 されました。 これまでの解説でもわかるように、https(TLS)では実際の通信を 行う前にいろんなことを決めます。 使う暗号の種類を決める、鍵の交換を行う、などのTLSハンドシェ イクと呼ばれる手順が必要です。 このTLSハンドシェイクに時間が取られることがTLSの大きな課題 でした。にも関わらずSSL2.0の時代からTLS1.2に至るまでここには 大きな変更はされず、手つかずでした。 TLSの課題はそのままhttpsの課題です。 TLS1.3は、TLSハンドシェイクの課題解消に取り組むことで、https の課題解消まで目指した意欲的な新バージョンなのです。 具体的には、初回のTLSハンドシェイクで決めたことを次回以降も 再利用できるようになりました。 httpsは、一度サーバに接続しても１つのデータ（ファイル）を 送受信すると「さよなら」（クローズ）するルールになっています。 一般的に１つのWebページを表示するには数十のファイルが必要 ですから、何十回ものTLSハンドシェイクが必要です。 通信相手が同じ限り、何回TLSハンドシェイクしても同じ結果に なりますから、何度もやるのは無駄でしかありません。 TLS1.3では、２回目以降は「いつもの」と言うだけでTLSハンド シェイクを行わずに済むようになりました。 なじみのお店で「いつもの通りで」と言えば通じるのと似た感じ ですね。 こうすれば、同じTLSハンドシェイクを毎回毎回毎回毎回繰り返す のを省略できるわけで、トータルでは時間をグッと縮めるられる というワケです。 詳細は省略しますが、ハンドシェイク手順をより安全にするための 改訂も行われていて、ずいぶんと盛り沢山なバージョンになって います。 なお、TLS1.3の実装（実際に動くプログラム）はすでにあちこちで 提供されていて、主要なブラウザは対応済ですし、多くのサーバ プログラムも既に提供されています。 とはいえ、通信には相手がいます。 相手がTLS1.3に対応できていなければ、今まで通りの手順を使う 他ありません。 その意味で、TLS1.3が普通に使われるまでには、まだまだ時間が かかりそうです。 2. HTTP/2 －－－－－ 現在多くのサイトで使われているHTTPはバージョン1.1です。 これは1999年に定められた意外に古いプロトコルです。 その16年ぶりの改訂版がこのHTTP/2という規格です。 名前はHTTP/2 ですが、HTTPとHTTPSの２つのプロトコルの定義が 含まれています。 HTTP1.1では、一度サーバに接続すると１つのデータ（ファイル） だけをやりとりして、「さよなら」（クローズ）するルールでした。 これが決められた1990年代はそれでも良かったんです。 １つのWebページの構成要素は今よりもずっとシンプルでしたから。 ですが、現代では上で書いたように１つのページを表示するにも 何十ものファイルが必要になっていますから、明らかに当時とは 想定がズレてきています。 これを防ぐため、上述のTLS1.3は「いつもの」と伝えれば前回と 同じ方式とするルールを追加しました。 HTTP/2はそれとは違ったアプローチをとりました。 １つのデータ（ファイル）のやりとりが終わっても、すぐにサー バと「さよなら」（クローズ）せず、そのまま次のデータのやり とりを続けられるルールを追加したのです。 TLS1.3にしてもHTTP/2にしても、毎回TLSハンドシェイクを繰り 返すムダを避けるのは同じなのですね。 なお、HTTP/2はGoogleが自主的に開発していたSPDY（スピーディ） という実験用プロトコルを標準化したものです。 ちなみに、HTTPと大文字で書く場合とhttpと小文字で書く場合が あります。 プロトコルとしてはHTTPと大文字で書くことが多く、URLに書く時は httpと小文字で書くことが一般的ですが、どちらも意味は同じです。 さらに余談ですが、メールアドレスも大文字と小文字は区別され ないルールになっています。 ですから、メールアドレスの大文字小文字を間違ってもちゃんと 相手には届きます。 3. HTTP/3 －－－－－ 上のHTTP/2は2015年に定められた規格で、まだまだ一般化している と言えない状態ですが、さらにその次世代のHTTP/3の標準化が 進んでいます。 HTTP/2からさらなる高速化を目指して、内部構造を大きく見直して います。 ただ、HTTP/2にしても、HTTP/3にしても、一般利用者からは今まで のHTTP1.1と違いを意識しなくても良いように設計されています。 利用者にとっては、ブラウザを使うときにキビキビと素早く動けば いいわけで、内部構造がどうであろうと関係ないですからね。 なお、このHTTP/3もHTTP/2の時と同様、Googleの実験用プロトコル であるQUIC（クイック）を標準化したものです。 4. httpsが複数の方式から選択させる理由 －－－－－－－－－－－－－－－－－－－－ 前回までに述べたように、httpsでは複数の手法からどれかを選ぶ という場面がよく出てきます。 例えば、次のようなものがあります。 ・TLSバージョンの選択 ・暗号方式の選択 ・鍵交換の方法の選択 どうせなら、最強の方式を一つだけにすれば、TLSハンドシェイク もシンプルにできますし、よさそうなものです。 そうしていないのには理由があります。 規格を定めた時点で最強の方式を選んだとしましょう。 でも、１種類に固定すると、いつか最強じゃなくなります。 数年もすればさらに強力な方式が登場するのは明らかですから。 強力な方式が登場するたびに、規格を改訂するようではむしろ 混乱を招くだけです。 ですが、それよりもはるかに深刻な問題があります。 それは、その最強の方式に欠陥が見つかると、https自体が使えなく なるというものです。 最初から複数の方式を選べるようにすれば、一つの方式に欠陷が 見つかってもその方式を避けることで、httpsは使い続けることが できますよね。 httpsの目的は「安全な通信」です。絶対に欠陥のないものは人類 には作れません。だから、欠陥が見つかっても使い続けられる という前提で設計がされているのです。 この点からも、httpsは非常に丁寧に考えられた仕組みといえます。 今回は以上です。 次回もお楽しみに。