HTTPS通信について

Thu, 30 Apr 2026 23:52:18 +0900

背景

HTTPSについて調べていたときのメモを発見したのでこっちにコピーする

基本

共通鍵暗号方式 (DES, AES)

一番ベーシックな暗号方式は共通鍵暗号方式。シーザー暗号もこの一種。

予め共通鍵を共有する
送信者は送るテキストを共通鍵で暗号化
受信者に送信
受信者は暗号化された文を共通鍵で復号

DESとAESとは？

第二次世界大戦で利用されたエニグマなど1976年以前の暗号は共通鍵暗号に分類される。この暗号方式は1977年にアメリカ政府が策定した56ビットの鍵を用いるDES(Data Encryption Standard)として広く用いられてきた。しかし、現在では総当たり攻撃で解読可能なほど安全性が低くなっており、2001年にNISTが公募し規格化したAES(Advanced Encryption Standard)が標準として利用されている。

公開鍵暗号方式とは？

共通鍵暗号方式では、ひとつの鍵（共通鍵）を使用するが、公開鍵暗号方式では対になっている 2つの暗号鍵を用いる。

この 2つの鍵は、それぞれ「公開鍵 (Public Key)」と「プライベート鍵(Private Key)もしくは秘密鍵」と呼び、対となる 2つの鍵の組み合わせを「鍵ペア」と呼ぶ。

メッセージの送信フロー

受信者は予め公開鍵を送信者に送る
送信者はメッセージを公開鍵で暗号化して送信する
受信者は秘密鍵で暗号文を復号する

なぜ公開鍵で暗号化して、秘密鍵で復号化するのか？

基本的には公開鍵で暗号化して、秘密鍵で複合する。なぜ逆はないかというと、秘密鍵で暗号化すると、みんな読めてしまう状態になるから。

ハイブリッド暗号 (公開鍵暗号方式と共通鍵暗号方式を組み合わせ)

実際のメッセージの中身の暗号化では、公開鍵暗号方式と共通鍵暗号化方式を組み合わせる。

なぜ公開鍵暗号方式と共通暗号方式を組み合わせるのか？

公開鍵暗号方式では実は処理が重いから。公開鍵暗号方式は複雑な演算処理を行うため、共通鍵暗号方式の数百倍もの計算が必要になる。そこで実際には、高速な処理を可能にするため、公開鍵暗号方式と共通鍵暗号方式を組み合わせて使用する。

公開鍵暗号方式と共通暗号方式を組み合わせによるメッセージの暗号化

共通鍵 (S) を生成する。（A さん）
生成した共通鍵 (S) を用いて、平文 (T) を暗号化する。（A さん）
各送信相手の公開鍵 (B, C, D) を用いて、共通鍵を暗号化 (SB, SC, SD) する。（A さん）
暗号文 (TS) と暗号化した共通鍵 (SB, SC, SD) を送信する。（A さん）
自分の公開鍵(B)で暗号化された共通鍵 (SB) を選択し、自分のプライベート鍵(B’)を用いて復号(S)する。（B さん、C さん、D さん）
復号した共通鍵 (S) で暗号文 (TS) を復号 (T) する。（B さん、C さん、D さん）

公開鍵暗号方式と共通暗号方式の組み合わせのポイント

共通鍵でメッセージを暗号化するが、共通鍵は公開鍵で暗号化して、秘密鍵で共通鍵を復号化してその復号化した共通鍵でメッセージを復号化するところ。つまり、共通鍵方式で問題だった、共通鍵の安全なやり取りの問題を公開鍵方式で解決しているところ。共通鍵方式では一旦共通鍵がバレルと暗号文は全部ダダ漏れだから。

非公開鍵による変換（デジタル署名）

デジタル署名とは？

メッセージに対するダイジェストを秘密鍵で暗号化することで、メッセージの改ざんを検出することができる。これをデジタル署名 (Digital Signature) と呼ぶ。

公開鍵は誰でも取得できるため、プライベート鍵で暗号化しても守秘性の確保にはならないが、プライベート鍵が特定の個人のみ所有しているので、電子文書の真正性と完全性の保証を実現することができる。

これがデジタル署名 (Digital Signature) と呼ばれる技術。

デジタル署名では、署名と検証の2つのことを行う。

デジタル署名の検証の目的

メッセージが改ざんされていないこと
メッセージは、検証に使用した公開鍵と対になる秘密鍵(鍵ペア)によって署名されたこと

なぜ非公開鍵で暗号化するのか？

基本的に公開鍵方式では、公開鍵で暗号化して、非公開鍵で復号化する。
(なぜなら、その逆だと、公開されている公開鍵でだれても暗号文を解読できてしまうから)
ただし、RSA暗号方式の場合、これとは逆に、プライベート鍵で暗号化(署名)して公開鍵で復号(検証)することもできる。
この仕組みによって、署名を検証することで、改ざんされていないことや鍵ペアが正しいことを検証する。
NOTE: メッセージの中身自体は暗号化されていないので注意。

用途による鍵ペアの名称

メッセージの中身自体を暗号化したい場合は、公開鍵を使って暗号化して、秘密鍵で復号化する。他方、署名(デジタル署名)をしたい場合は、非公開鍵で暗号化して、秘密鍵で検証する。

用途による意味の違い

意味的には、暗号鍵と復号鍵と検証鍵がある。

用途	プライベート鍵 (Private Key)	公開鍵 (Public Key)
守秘	復号鍵	暗号鍵
ディジタル署名(RSA暗号)	署名鍵	検証鍵

RSA暗号について

基本、公開鍵暗号方式では、公開鍵は公開されているので、暗号化用で、非公開鍵は復号化ように使われる。ただし、RSAはちょっと違う。双方向で暗号と復号が可能。その構造上、デジタル署名のアルゴリズムとして使われている。順を追って説明する。

RSA暗号の仕組み

RSAでは公開鍵と秘密鍵の２つの鍵を 素数の掛け算と素因数分解の計算コストの差を利用して実現する。

A: 素数 B: 素数 C = A x B

その計算には次の特徴がある。

掛け算は簡単
- AとBが数百桁あったとしても、かなり短時間で計算できる。
- 23451532523 x 53523532532235 = ??? みたいな
- 単に計算すればOK = ローコスト
素因数分解は難しい
- ??? x ??? = 5057230593780528023
- これは5057230593780528023を素因数分解する必要がある。
- ただし、因数は素数なので大きな素数の掛け算になる。
- 虱潰しに計算しないといけない = ハイコスト

RSA暗号の具体的な例

RSAの公開鍵 (素因数分解)
- この鍵で暗号化したものを平文化するためには、秘密鍵が必要
- A × B = C のうちの C だけが書かれている
- 計算によって、Cから AとB を特定するのは困難(=公開鍵から秘密鍵は作れない)
- 公開鍵から秘密鍵を作ることができないため、「閉めることしかできない鍵」となる
RSAの秘密鍵 (掛け算)
- 公開鍵で暗号化したものを平文化することができる鍵
- A × B = C のうちの AとB が書かれている
- 計算によって、AとB から Cを求めるのは簡単(=秘密鍵から公開鍵を作れる)
- 秘密鍵から公開鍵を作ることができるので、間接的には閉めることもできる

重要なのは、RSAでは、秘密鍵だけ大事に保管しておけば、無くしてしまった公開鍵をあとから生成しなおすことができる

RSAの公開鍵と非公開鍵はどちらでも暗号化と復号化が可能

実は RSAの公開鍵と秘密鍵は同じ構造をしているので、どちらの鍵をつかっても暗号化することができる

あなた		相手
秘密鍵で平文化	<=暗号化=	公開鍵で暗号化
秘密鍵で暗号化	=暗号化=>	公開鍵で平文化

つまり、双方向でできてしまう。ただし、秘密鍵から公開鍵は作成できないので、公開鍵を渡すようにする。

また、公開鍵で暗号化してもあまり意味がない。なぜなら、公開鍵は公開されているので、誰でも暗号化できるため。 Githubみたいに(https://github.com/mgoldchild.keys)、公開鍵として公開されている。

非公開鍵で暗号化できるメリット

それは暗号文を自分で暗号化したことを証明できる。

明日送金します。by Mike

というメッセージが平文で(暗号化されずに)送られてきた時に、そのままではこのメッセージを書いたのが本当にMikeなのか、それとも第三者が捏造したものなのかを区別することができない。

それを区別できるようにするのが電子署名。

RSAの電子署名は、秘密鍵による暗号文を作り出すことで実現する。上記文章をMikeの秘密鍵で暗号化すると、受け取った人はMikeの公開鍵を使って平文化できる。

Mikeさんの公開鍵は公開されているので誰でも読めるが公開鍵で平文化できる暗号文を作れたということは、 Aさんの秘密鍵を持っているということ、

つまり本人が書いた文章だということがわかる。これが電子署名。

つまり、メッセージを暗号化する共通鍵方式や普通の公開鍵暗号方式とは違い、 RSA暗号ではメッセージではなく、送信者を保証することを目的とする。

コマンドの具体例

コマンドでは一旦メッセージを計算コストの低くなるdigitにsha1などで変換してから、非公開鍵で暗号化する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


echo -n "明日送金します。by Mike" | openssl dgst -sha1 -sign private-key.pem | hexdump
0000000 c2 1f 73 6d 4f b5 fa 5a 9d 9d 02 e0 a3 fe 70 0c
0000010 93 ef f5 f1 3c 34 ec 5f e0 8d 21 58 6a 27 3a e1
0000020 b0 49 81 a8 15 d2 92 39 cc fe ce 2d 3f 9f 91 3d
0000030 68 cf 99 ce 91 04 2e 72 e7 e5 c5 71 55 29 87 7d
0000040 f5 e9 f0 c3 f5 6b af f4 be 8f f9 c4 34 bb 52 1c
0000050 51 8d cf c7 64 e0 84 d2 33 ed bb 80 4f 9a 3f 42
0000060 84 2e ef 41 e4 fc b4 04 51 5e 55 11 86 63 31 fc
0000070 a1 b7 6b 93 f7 e0 67 31 04 69 e4 2e 97 e6 5f a2
0000080

まとめ

インターネットで身元を確認して挨拶するのは大変という話。

Mike> Hi John. John> Good morning Mike.

顔が見えないインターネットでは次のような疑問が浮かぶ。

人
- 本当にMikeなのか？
- 本当にJohnなのか？
メッセージ
- 途中で誰かにメッセージを盗聴されていないか？
- 途中で誰かにメッセージを改ざんされていないか

そういう背景があって暗号化が必要になる。

比較

アルゴ	目的	処理	メリット	問題
共通鍵暗号方式	メッセージをの暗号化	共通の鍵でメッセージを暗号化	メッセージを双方向に暗号化可能	共通鍵を渡すときに、共通鍵が流出すると問題
公開鍵暗号方式	メッセージをの暗号化	公開鍵を渡して暗号化してもらう	公開鍵を持っている人から他人が盗聴できないメッセージを非公開鍵を持っている人に送れる	計算コストが高い。また、双方向ではメッセージを暗号化できない。
ハイブリッド暗号方式	共通鍵を安全に送信する	公開鍵で共通鍵を暗号化して非公開鍵でそれを復号化してもらう	計算コストが低い。また、双方向でメッセージを暗号化可能。	公開鍵を渡しても、公開鍵自体が改ざんされている可能性がある。
DH鍵交換	共通鍵を安全に送信する	通信内容がバレても問題ない数字を双方向にパラメータとして決めて、秘密な共通鍵（秘密鍵でもある）を生成する	共通鍵自体をハイブリッド方式のように送信しないので共有鍵交換中に	中間者攻撃を受ける可能性がある
デジタル署名（サーバー証明書）	公開鍵を安全に送信する	公開鍵をメッセージとして、非公開鍵でそれに署名をつけて、公開鍵でそれを検証する	公開鍵を非公開鍵を持っている人が送信したことを確認できる	公開鍵を渡してきた人が本当にその人本人なのかが分からない。例えばMikeから送られた。では本当にMikeなのか？
デジタル署名（中間証明書）	サーバー証明書を証明する	信頼できる第三者機関（Trusted Third Party）に送信者の公開鍵をメッセージとして、第三者機関の非公開鍵でそれに署名をつけて、第三者機関の公開鍵でそれを検証する	公開鍵を渡してきた人の信憑性が権威のある信頼できる第三者機関によって保証される。中間者攻撃を防ぐ。	ただし、その信頼できる第三者機関自体が改ざんされていたら
デジタル署名（ルート証明書）	中間証明書を証明する	さらに信頼できる第三者機関からその元々の第三者機関を証明してもらう(ルート証明書)。	さらに信頼のある第三者から中間証明者を保証してもらう。中間者攻撃を防ぐ。	最終的には自己署名の問題に回帰するが、多段に検証している分安全なので、問題なし
MAC(メッセージ認証コード)	メッセージの改竄を防ぐ	通信データに改ざん検知用の確認データ(メッセージ認証コード)を付与する機能	メッセージにDigitをつけてメッセージ自体が改ざんされていないかを保証する	なし

公開鍵暗号方式の種類

種別	目的
DH(Diffie-Hellman)	鍵交換	W. Diffie と M. Hellman が 1976年に発表した、共通鍵を安全に交換するための鍵配送アルゴリズムである。
RSA(Rivest-Shamir-Adleman)	暗号化署名鍵交換	Rivest, Shamir, Adleman の 3名が 1978年に発明したアルゴリズムである。同じ鍵ペアを暗号化と署名の両方に利用できることが特徴である。大きな整数の素因数分解が困難であるという仮定に基づいている。
DSA(Digital Signature Algorithm)	署名	NIST が 1991年に提唱した、デジタル署名のためのアルゴリズムである。離散対数問題を解くことが難しいという仮定に基づいている。デジタル署名専用のアルゴリズムであり、暗号化の機能はない。
楕円曲線暗号(ECC: Elliptic Curve cryptosystem)	暗号化署名鍵交換	Neal Koblitz と Miller が 1985年に別々に考案した方式である。特定のアルゴリズムを指すのではなく、離散対数問題に楕円曲線を適用させて、強度を保ちつつ鍵長を小さくするために用いられる [15]。主な適用例として、DSA に適用したECDSA が有名である。

DH鍵共有

DH 離散対数問題とフェルマーの小定理

素数と離散対数問題 (Discrete Logarithm Problem)

2^x mod n = xを次の表で示す。例えば、2の2(x)乗=4を3(n)でmodすると、答えは1。つまり、あまりは1。すると、nが素数のとき (7, 17, 23, 31 を除いて)、計算結果に 1 から n-1 までの全ての整数が登場する。

例えば n=37 のとき、1 から 36 が 1 回ずつ登場する。

また、そのようにならなかった n=7, 17, 31 についても、3^x mod n を計算すると同様に 1 から n-1 までの全ての整数が登場する。

このように、n が素数で、基数 g (前述の 2 とか 3 の部分) を適切な値に選ぶと、g^x mod n (1 ≦ x ≦ n-1) は 1 から n-1 までの整数が 1 回ずつ登場する。

このようなとき、g^x mod n = K の計算で、K 以外の 3 つのパラメータが与えられていて K を計算するのは比較的簡単であるのに対し、x 以外の 3 つのパラメータが与えられて x を計算するのは難しい、という性質がある。

この x を求める難しい問題のことをDiscrete Logarithm Problem (DLP: 離散対数問題) と呼ぶ。

以降、mod n の n (法の n) が素数のとき、mod p と記述する。素数を英語で prime と呼ぶからである。

DH 鍵共有アルゴリズムでは、g (基数) と n 改め p (適切な大きな素数) を公開パラメータ、x (1 ≦ x ≦ p-1) を各個人の秘密鍵、K (g^x mod p) を各個人の公開鍵として使う。

鍵のタイプ	数字
秘密鍵	g(基数)
秘密鍵	p(素数)
公開鍵	K(あまり)

フェルマーの小定理

先程の表で、n が素数のとき、n-1 の計算結果が必ず 1 になっていることに着目する。これはフェルマーの小定理と呼ばれるものである。

DH法の問題点は中間者攻撃

中間者攻撃とは、通信を行う２者の間に第三者が介入し、２者に気づかれないように情報を盗み見る方法。

下地図のように中間攻撃者がいると、共通鍵がバレてしまうので、メッセージの内容を復号化して中身を読めてしまう。

DH鍵共有とは

共通鍵暗号方式のために使われる共通暗号を共有する仕組み。具体的には、$a$, $b$を非公開鍵、$g$, $p$をパラメータとし、$g^a \mod p$や$g^b \mod p$を公開鍵とし、認識を合わせた上で、共有鍵を作る方式。

DH鍵共有の具体的な計算

DH鍵共有を使うプロトコル

IP ネットワーク通信において、暗号化による機密性と認証による通信相手の正当性を担保する技術として「IPsec」や「SSL/TLS」、「SSH」等がある。この 3 つのプロトコルは用途によって使い分けられるが、いずれも共通鍵暗号方式での通信暗号化のための「共通鍵の共有」を、【Diffie-Hellman 鍵共有 (DH 鍵共有)】というアルゴリズムによって実現している。

dh鍵交換の簡単な計算例

50 / 7 = 4あまり1を次のように表現する。

$$ \begin{align} 50 \mod 7 = 1 \\ 324 \mod 7 = 2 \end{align} $$

この剰余演算は普通の計算と同じような、以下の性質がある。

$$ \begin{align} (a \mod n) + (b \mod n) = (a+b) \mod n \\ (a \mod n) - (b \mod n) = (a-b) \mod n \\ (a \mod n) × (b \mod n) = ab \mod n \\ (a \mod n)^b = a^b \mod n \\ \end{align} $$

割り算も条件付きで定義可能だが、ここでは省略する。

$$ \begin{align} (50 \mod 7) + (324 \mod 7) = 374 \mod 7 = 3 \\ (50 \mod 7) - (324 \mod 7) = -274 \mod 7 = 6 \\ (50 \mod 7) × (324 \mod 7) = 16200 \mod 7 = 2 \\ \end{align} $$

SSL証明書

SSL証明書とは

HTTP通信を暗号化するには次のファイルが必要となる。

サーバーの公開鍵(CSR)と秘密鍵(Key)
認証局(CA)が電子署名したSSL証明書(CRT)と中間CA証明書 SSL証明書はサーバについての情報と、サーバの公開鍵、証明書を発行した認証局の情報が署名されているファイルである。

サーバの公開鍵はクライアントとの通信を「暗号化」する際に使用し、署名は「なりすまし」を防ぐために使う。

署名は、証明書を発行するCAと呼ばれる第三者機関が、CSRの情報を元に行う。

中間CA証明書は、SSL証明書を発行する認証局またはその配下にある別の認証局によって署名されたファイルである。必須ではありませんが、セキュリティレベルの向上を理由に、中間CAを1つい上用いる階層構造とる認証が現在は主流となっている。

SSLの用語と設定の違い

事前に用意するモノ

KEY:
- SSLの為のサーバー用の秘密鍵のこと。
CSR (Certificate Signing Request):
- SSLの為のサーバー用の公開鍵のこと。
- CSR には「公開鍵」とその所有者情報、及び申請者が対応する秘密鍵を持っていることを示すために申請者の署名が記載されている
- サーバの公開鍵はクライアントとの通信を「暗号化」する際に使用するリクエスト用

CSRの例

CA(認証局)によって発行されるSSL証明書

CRT:
- サーバー証明書
INCRT
- 中間CA証明書
ROOTCRT
- ルート証明書

CRTの例

SSL証明書の中身

SSL証明書 or SSLサーバー証明書 or サーバー証明書
- CRTとINCRTとROOTCRTの中身
- サーバについての情報と、サーバの公開鍵、証明書を発行した認証局の情報が電子署名されているファイル
- 階層構造になっている
- トラストチェーンでサーバー証明書を証明する中間CA証明書を証明するルート証明書という感じになっている
- ルート証明書はPCに直接保存されている

1
2
3


Example CA Root X1
 └Example CA intermediate G2
 └example.jp

SSL証明書発行と設定の流れ

SSL証明書の発行には、次のような手順が踏む。

自分のサーバーでCSRとKEYを作成
CSRをCAへ送信して証明書の発行を申請
CAから電子署名されたCRTと中間CA証明書を受け取る
受け取った証明書類をWebサーバーへ設置する

ディスティングイッシュネームとは？

ディスティングイッシュネームとは、CSRを作成する際に登録をする、ウェブサイトの所有者情報のことである。

項目名	項目の内容	入力例
Common Name	ウェブサイトのFQDN(Fully Qualified Domain Name)を登録する。サイトURLが「https://www.securecore.co.jp/」の場合だと、 Common Nameは「www.securecore.co.jp」と指定する必要がある。※CoreSSLワイルドカードの場合はサブドメインにも対応しているので、「*(アスタリスク).ドメイン名」で登録する。※FQDNとはドメイン名・サブドメイン名・ホスト名を省略せず記載した形式のことを指す。	www.securecore.co.jp
Organizational Name(※1)	ウェブサイト運営組織の法律上の正式英文名称を登録する。法人格(Co Ltd Inc K.K.等)は入力必須である。	SecureCore,Inc.
Organizational Unit(※1)	ウェブサイト運営組織の部署名を登録する。	Sales
City or Locality(※1)	ウェブサイト運営組織の市区町村名を登録する。	Osaka-Shi
State or Province(※1)	ウェブサイト運営組織の都道府県名を登録する。	Osaka
Country	国を示す２文字のISO略語である。大文字で登録する。	JP

電子証明書

CSR (証明書発行要求) とは

CSR とは証明書発行要求 (Certificate Signing Request) と呼ばれるもので、これを生成する際に、秘密鍵と公開鍵も作られる。

CSR には公開鍵が含まれており、この CSR を中間認証局に送り、中間認証局の秘密鍵で生成した電子署名 (CSR をハッシュ化したものを秘密鍵で暗号化) を CSR の末尾に付け加えることでデジタル証明書が出来上がる。

CSR = 公開鍵を含む情報
電子証明 = 認証局の秘密鍵で生成
デジタル証明書 = 電子証明 + CSR

デジタル署名とは？

電子文章をハッシュ化して非公開鍵を使って電子署名を作成。それに対して、公開鍵で検証する仕組み。

RSA署名の作成

RSA署名の検証

電子証明書が正しいかどうかは、認証局の公開鍵を用いて署名検証鍵（署名の対象となる電子文章）を復号化して、それをハッシュ関数に渡してハッシュ値が一致するかを確認する。

大前提として、非公開鍵で暗号化された文章は複合が可能。

電子証明書は印鑑登録書と同じ仕組み

SSL（電子証明書）の仕組みは、単純に言えば、印鑑登録証(印鑑証明)と同じ仕組み。

デジタル証明書を発行する中間認証局が、その中間認証局の秘密鍵でデジタル証明書にデジタル署名する。これにより、デジタル証明書に書かれたホスト名の機器は、中間認証局がお墨付きをくれた状態になる。(印鑑証明で言う地方役所)

じゃあ中間認証局の身元は誰が保証するの？というと、更に上位の認証局。

このプロセスを最上位であるルート認証局まで繰り返すが、ルート認証局の身元は誰が保証するの？というと、自分自身でサインする。これは自己署名証明書と呼ばれる (俗に言うオレオレ証明書)。(印鑑証明で言う日本国)

=> なのでルート証明書は必ず自己署名証明書 (オレオレ証明書) になる。

その他

実際のフロー

Webサーバーの事前準備

Webサーバーは予めCSRと秘密鍵を発行する
そのCSRを認証局に送る
認証局はCSRを認証局が持つ秘密鍵で暗号化する=デジタル証明書の作成
認証局はその暗号化したCSR(デジタル証明書)をWebサーバーに返す
Webサーバーはデジタル証明書と秘密鍵を設置する

Userからのアクセス

Userはデジタル証明書をWebサーバーに要求する
Userはデジタル証明書を認証局の公開鍵を使って検証
- 相手が認証局に証明されているデジタル証明書を使っているかを確認
- この時点で認証局に証明されたWebサーバーの公開鍵が入っているがまだ使わない
WebサーバーはDH公開鍵(SV)を作成
Webサーバーは秘密鍵でDH公開鍵(SV)を署名する = デジタル証明書(2)
Webサーバーはその新たなデジタル証明書(2)をUserに送る
Userはデジタル証明書の公開鍵でデジタル証明書(2)を検証
- 送られたデジタル証明書(2)は間違いなく認証局に認証されたWebサーバーから署名されたモノ
- つまり、中間攻撃者がいないことを認証局を使って確認した
Userは自分のDH公開鍵(CL)を送る
DH公開鍵(CL/SV)により、UserとWebサーバーは共通鍵を生成
それを利用してメッセージを暗号化する

NOTE:

CL = Client
SV = Server

TSL SNIとは？

つのサーバーで1つしか使えなかったSSLサーバー証明書が、ドメイン名（URL）単位で利用できるようになる技術。

仕組みとしてはSSL通信時にドメイン名を通知することで、サーバー側がどのSSLサーバー証明書を利用すべきか判別する。

これによって、1台のサーバーでもドメイン名の数だけSSLサーバー証明書の利用が可能になり、URLが途中で変わってしまう心配や、SSLサーバー証明書ごとに別々のサーバーを用意するといった手間やコストの負担が軽減された。

暗号スイートとは

SSLは4種類の機能を組み合わせたハイブリット暗号技術。英語で Cipher Suites と言い、TLSの暗号通信のためのプロトコルで複数の暗号化アルゴリズムの組み合わせのことを指す。

	目的	アルゴ
Kx(鍵交換方式)	鍵交換に使われる暗号化アルゴリズム	DHE (ディフィー・ヘルマン鍵共有)
Au(鍵認証方式)	鍵が正しいかの認証に使われる暗号化アルゴリズム	RSA認証
Enc(メッセージ暗号方式)	暗号化したい通信データ自体の暗号化。アプリケーション層の暗号化に使われるアルゴリズム	AES
Mac(メッセージ署名方式)	暗号化した通信データの改ざんチェック。メッセージの検証に使われるアルゴリズム	SHA1

例

opensslで使われる暗号化スイートの一覧。

1
2
3
4
5
6
7


$ openssl ciphers -v
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD

一番上を抜粋すると、

1
2


1 2 3 4 5 6
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD

番号で読み解くと次の意味

1
2
3
4
5
6
7
8


1.暗号化スイートの名前
 - ECDHE-RSA-AES256-GCM-SHA384 の箇所
1. SSLのバージョン
3. ECDHE : 鍵交換方式(Kx)を意味する
4. RSA : 鍵認証方式(Au)を意味する
5. AES256 : メッセージ暗号方式(Enc)を意味する
5. GCM : ブロック処理を意味する
5.6. SHA384 : メッセージ署名方式(Mac)を意味する

TSL on M1KE BL0G

HTTPS通信について

背景

基本

共通鍵暗号方式 (DES, AES)

DESとAESとは？

公開鍵暗号方式とは？

メッセージの送信フロー

なぜ公開鍵で暗号化して、秘密鍵で復号化するのか？

ハイブリッド暗号 (公開鍵暗号方式と共通鍵暗号方式を組み合わせ)

なぜ公開鍵暗号方式と共通暗号方式を組み合わせるのか？

公開鍵暗号方式と共通暗号方式を組み合わせによるメッセージの暗号化

公開鍵暗号方式と共通暗号方式の組み合わせのポイント

非公開鍵による変換（デジタル署名）

デジタル署名の検証の目的

なぜ非公開鍵で暗号化するのか？

用途による鍵ペアの名称

用途による意味の違い

RSA暗号について

RSA暗号の仕組み

RSA暗号の具体的な例

RSAの公開鍵と非公開鍵はどちらでも暗号化と復号化が可能

非公開鍵で暗号化できるメリット

コマンドの具体例

まとめ

比較

公開鍵暗号方式の種類

DH鍵共有

DH 離散対数問題とフェルマーの小定理

素数と離散対数問題 (Discrete Logarithm Problem)

フェルマーの小定理

DH法の問題点は中間者攻撃

DH鍵共有とは

DH鍵共有の具体的な計算

DH鍵共有を使うプロトコル

dh鍵交換の簡単な計算例

SSL証明書

SSL証明書とは

SSLの用語と設定の違い

事前に用意するモノ

CA(認証局)によって発行されるSSL証明書

SSL証明書の中身

SSL証明書発行と設定の流れ

ディスティングイッシュネームとは？

電子証明書

CSR (証明書発行要求) とは

デジタル署名とは？

RSA署名の作成

RSA署名の検証

電子証明書は印鑑登録書と同じ仕組み

その他

実際のフロー

Webサーバーの事前準備

Userからのアクセス

TSL SNIとは？

暗号スイートとは

例

参考文献