信用には堪えない、廃止済み RSA 形式の SSL 整理ノート〜 openssl とイラストをそっと添えて〜 #Security

概要

わからんわからんとにかく SSL の仕組みがわからん、いくつネットの記事をめぐってもわからん、書いてあることが違うし「デマ記事が多すぎ」という意見もありどれを信用すべきかわからんし記事を書いている今でもやはりわからん。色んな人たちに「そのへんはブラウザやインフラがよしなにやってくれるからそんなに気にしなくていいよ」と言われたけどやっぱり気になる、わからん。

そんな状態で記事を書いて本当にすみません。今からデマ記事をもうひとつ増やします。正確な記事をお求めの方は無視していただきたく。本記事は、ざっと SSL の情報をめぐった結果を私なりにまとめ、湧いた疑問も併記したものになります。それと、各要素が複数の名称で呼ばれていること(サーバ証明書、 SSL 証明書など)も自体を難解にしていると感じたので、そのあたりにも触れつつノートします。

読む前のご注意

きっと私以外にも SSL の通信フローに興味をもち、調べてみようとしている方がおられると思います。みなさんに向けて、この調査において大事だと思ったことを最初に並べておこうと思います。

一言に「SSL の流れ」といっても TLS1.2 や TLS1.3 といったバージョンで違います。調べるときはバージョンを絞ったほうがいいかもしれません。
もっとも参考にすべきなのは RFC(インターネット技術の標準的な仕様を記した文書)なのだと思います。 TLS1.2がこちらで、 TLS1.3がこちらですね。英語です。
本記事は「SSL」だけで日本語のネット記事を適当に調べてまわったものです。そのため以上の理由により、まったく信用できません。
ちなみにこのノートでまとめようと試みているのは RSA 形式の SSL フローです。 TLS1.3 ではすでに廃止されており、現行ではありません。どのバージョンで廃止されたのかは未調査です。

ゼロから始め、この記事の内容を調査しただけで正直へとへとなので、 TLS1.3 などの調査はまたいつか気が乗ったときにします。↑のことが分かったのが、今回の調査の一番の成果なのかな、と思っています。

整理ノート

クライアント: サーバに https リクエスト

「クライアント」「ブラウザ」は同じ。
実際にはこのリクエストが発生する前に、下に記述する鍵生成やサーバ証明書作成が行われるはず。リクエストを話の起点にしたほうが理解がしやすかったためこのような順序で書いています。

サーバ: 秘密鍵を作成

秘密鍵は暗号化のためのファイルです。対となる公開鍵で暗号化されたメッセージは、これを使って復号化できます。
具体的にはテキストっぽい PEM 形式、あるいはバイナリデータの DER 形式のファイルです。
今回は PEM 形式で統一します。

以下に秘密鍵の作成コマンドと、秘密鍵の具体的な内容の一例を示します。 SSL の仕組み、フローをなぞるのが目的ならばこういった細かいところは気にしないでいいと思いますが、具体的なモノが例示されていると私の場合はイメージがしやすく、理解しやすいので記述します。

# RSA 秘密鍵作成。
#   genrsa: RSA 形式の秘密鍵の作成。
#   -out: 出力ファイル名。
#   数字: 生成する秘密鍵のビット数。あんまり小さいと怒られます。2048にしているのをよく見ます。
openssl genrsa -out server-private-key.pem 512

# 完成したファイルの内容を見ます。
#   -in: 入力ファイル名。
openssl rsa -in server-private-key.pem

server-private-key.pem

RSA について: RSA は暗号方式の種類。最近では新しく DHE というもっと安全な(?)方式が使われることもあるらしい。しかし頭がそこまでついていかないので、今回は RSA 方式で作った鍵を使うことを前提に話を進めます。
拡張子 pem について: pem はファイルのエンコーディングを表します。
- pem: -----BEGIN から始まるテキストファイル。↑で作っているもの。他にもそれで始まるファイルはあるらしいが……まあ基本的にはそういう理解でいいのでは。
ファイル名について: ファイル名は自由につけることが出来、 private.key とかもありうる。ただそれだと pem なのか der なのか一見してわからないので、 .pem のほうがいい感じがします。個人的には。
疑問: RSA が DHE になったらこの SSL フローはどうなるのだろう……。
- (2019-12-23)コメントをいただき追記します。 DHE になったらフローがどうなるのかは未だに把握できていませんが、「DHE になったら」どころか RSA を使用した本記事のフローはとっくに廃止されているみたいです。

オマケ: 秘密鍵の中身

RSA にとって大切な、素数の組み合わせや、素数の積が表示されます。

# RSA 秘密鍵の中身を確認。 
#   -text: 上述したような pem 形式ではなくテキスト形式で表示。
#   -noout: これをつけないと、 pem もついでに表示されます。
openssl rsa -in server-private-key.pem -text -noout

server-private-key.pem

RSA Private-Key: (512 bit, 2 primes)
modulus:
    00:cb:a1:10:48:94:92:96:f6:b0:93:91:04:8e:c6:
    4e:6b:d9:cc:4b:78:d4:fa:1f:89:93:bf:1d:d6:01:
    ec:04:6c:3a:16:2b:af:2b:47:5f:02:39:d4:12:28:
    99:23:42:d2:0f:df:e9:9e:f4:59:e8:49:6f:bf:ed:
    f6:b4:04:02:47
publicExponent: 65537 (0x10001)
privateExponent:
    00:bd:82:b3:85:e9:08:18:89:94:42:72:07:9c:dd:
    00:65:2d:79:0d:90:72:1e:2a:b5:be:94:72:af:16:
    70:d2:97:41:74:f5:cf:79:c5:c4:bc:b1:0e:27:15:
    75:89:5f:da:ed:56:93:9f:9e:7f:a3:da:dd:9b:0f:
    96:76:2e:09:81
prime1:
    00:ef:1a:12:fb:08:d8:c3:24:60:10:71:0f:46:cf:
    53:73:93:3c:83:0b:3f:fd:0c:22:7b:d9:ea:e6:8d:
    d2:6c:41
prime2:
    00:da:05:34:0b:ed:dc:6f:57:3a:fd:24:9a:65:44:
    2f:7b:fa:d4:4b:48:1f:ff:b8:f9:28:c8:96:b9:02:
    01:ec:87
exponent1:
    44:30:09:6d:b2:0e:2f:48:b6:64:b9:f9:83:56:29:
    14:72:ce:f5:08:46:4d:62:22:8b:73:90:3c:04:02:
    18:81
exponent2:
    00:c0:91:63:fd:3d:65:3c:ba:d1:91:92:69:05:15:
    0a:d3:f9:22:d6:33:a8:7f:d8:c3:ca:70:12:20:eb:
    53:03:b5
coefficient:
    00:c6:da:3f:b0:a0:63:52:6b:52:a3:4b:a0:42:65:
    fc:bf:40:3d:a8:a3:cd:ed:fd:f5:12:60:b1:37:77:
    94:ab:42

サーバ: 公開鍵を作成(不要)

この後の CSR 作成時に同時に作成されるので不要です。順序だてて理解しやすいよう一応書くだけです。

# 秘密鍵をもとにして RSA 公開鍵作成。
openssl rsa -in server-private-key.pem -pubout -out server-public-key.pem

# 完成したファイルの内容を見ます。
openssl rsa -pubin -in server-public-key.pem

server-public-key.pem

-----BEGIN PUBLIC KEY-----
MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMuhEEiUkpb2sJORBI7GTmvZzEt41Pof
iZO/HdYB7ARsOhYrrytHXwI51BIomSNC0g/f6Z70WehJb7/t9rQEAkcCAwEAAQ==
-----END PUBLIC KEY-----

オマケ: 公開鍵の中身

# RSA 公開鍵の中身を確認。 
openssl rsa -pubin -in server-public-key.pem -text -noout

server-public-key.pem

RSA Public-Key: (512 bit)
Modulus:
    00:cb:a1:10:48:94:92:96:f6:b0:93:91:04:8e:c6:
    4e:6b:d9:cc:4b:78:d4:fa:1f:89:93:bf:1d:d6:01:
    ec:04:6c:3a:16:2b:af:2b:47:5f:02:39:d4:12:28:
    99:23:42:d2:0f:df:e9:9e:f4:59:e8:49:6f:bf:ed:
    f6:b4:04:02:47
Exponent: 65537 (0x10001)

オマケ: 秘密鍵と公開鍵で暗号通信

鍵ペアが出来たので、暗号通信ができます。今回は RSA なので、公開鍵と秘密鍵を逆にしてもできます。

# 公開鍵で暗号化。
echo 'FOO' | openssl rsautl -encrypt -pubin -inkey server-public-key.pem > message
# □□□'wG□^□mS□□`@□□f]@□□5□□□'□□U□□Q!□□?L7□□□<□)E□\=□□□□B□

# 秘密鍵で復号化。
cat message | openssl rsautl -decrypt -inkey server-private-key.pem
# FOO

サーバ: CSR を作る

CA 局にサーバ証明書を発行してもらうため、申請書である CSR を作成します。作成には秘密鍵とサーバ情報を使用します。サーバ情報というのは下記コマンドで -subj オプションで指定しているやつですね。

CA 局: 「CA 局」「認証局」「Certification Authority」が同じ。
サーバ証明書: 「サーバ証明書」「SSL サーバ証明書」「SSL 証明書」「TLS 証明書」「証明書」が同じ。
CSR: 「CSR」「Certificate signing request」「証明書署名要求」が同じ。
サーバ情報: 「サーバ情報」「被証明者に関する情報」「署名」「ディスティングイッシュネーム」が同じ。
SANs: (2019-12-23)コメントをいただき追記します。 -subj には色々指定していますが、 CSR(および証明書)においていっとう大事なのは SANs(Subject Alt Names)、つまり「その証明書がどのドメインのものなのか」ということです。しかし見ての通り今回の -subj にはそんな項目ないですね、そういうときは慣習的に CN が SANs として扱われるそうです。

# CSR 作成。
#   req: CSR を作ります。
#   -key: 秘密鍵。
#   -subj: サーバ情報。 Windows だとこのオプションが動きませんでした。つけなくても可。対話式になるだけなので。
#       C: Country Name
#       ST: State or Province Name
#       L: Locality Name
#       O: Organization Name
#       OU: Organizational Unit Name
#       CN: Common Name 
openssl req -new -key server-private-key.pem -out server-csr.pem -subj '/C=JP/ST=Hokkaidou/L=Hakodate/O=Mate/OU=Web/CN=mate.org'

# 完成したファイルの内容を見ます。
openssl req -in server-csr.pem

server-csr.pem

オマケ: CSR の中身

# CSR の中身を確認。 
openssl req -in server-csr.pem -text -noout

server-csr.pem

Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: C = JP, ST = Aomori, L = Hirosaki, O = Mate, OU = Web, CN = mate.org, emailAddress = me@mate.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (512 bit)
                Modulus:
                    00:cb:a1:10:48:94:92:96:f6:b0:93:91:04:8e:c6:
                    4e:6b:d9:cc:4b:78:d4:fa:1f:89:93:bf:1d:d6:01:
                    ec:04:6c:3a:16:2b:af:2b:47:5f:02:39:d4:12:28:
                    99:23:42:d2:0f:df:e9:9e:f4:59:e8:49:6f:bf:ed:
                    f6:b4:04:02:47
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         72:7f:f8:72:01:b7:88:65:95:8a:9f:81:6f:39:8c:52:a6:ef:
         a9:1e:4b:12:56:14:93:f7:d4:ac:9c:07:8d:1f:07:92:b7:44:
         e2:2e:8c:41:03:55:ce:49:06:a7:cf:a2:94:fb:d8:20:ad:62:
         e1:29:c9:78:a3:c6:a4:b2:3e:e3

オマケ: CSR には公開鍵が含まれる

# CSR の中身を確認。
openssl req -in server-csr.pem -pubkey -noout

-----BEGIN PUBLIC KEY-----
MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMuhEEiUkpb2sJORBI7GTmvZzEt41Pof
iZO/HdYB7ARsOhYrrytHXwI51BIomSNC0g/f6Z70WehJb7/t9rQEAkcCAwEAAQ==
-----END PUBLIC KEY-----

さっき手ずから作った公開鍵の内容と同じです。

サーバ: CA 局へ CSR を送付

CSR を送付……サーバ証明書の発行依頼をします。

CA 局: サーバの検証

~~サーバが信用できるものかどうか確認をする。~~
(2019-12-23)コメントをいただき訂正します。ここで CA 局が行うのは、「サーバが信用できるものかどうか」というか、送り主がそのサーバ(そのサイト、ドメイン)の正式な運用者であるかどうかの確認です。

CA 局: サーバ証明書を発行

サーバ証明書は、「サーバ情報と、サーバ公開鍵と、 CA 局自身の証明書と、電子署名のセット」です(多分)。このサーバは信用できること、この公開鍵はこのサーバの公開鍵であること、それを証明している自分(CA 局)自身も信用できること、を証明しています。

電子署名: 「電子署名」「デジタル署名」が同じ。
疑問: 私は今のところ、電子署名のことを「サーバ情報とサーバ公開鍵をくっつけて(?)ハッシュ化し、 CA 局の秘密鍵によって暗号化したもの」と思っているが正しいのか。

オマケ: 証明書発行を再現してみる

サーバ証明書を発行するためには、まず CA 局自身の証明書がないといけない。それを作成します。

# CA 局の秘密鍵作成。
openssl genrsa -out ca-private-key.pem 512

# CA 局の CSR 作成。より上位の CA 局に申請してもらうためのもの。
openssl req -new -key server-private-key.pem -out ca-csr.pem -subj '/C=JP/ST=Tokyo/L=Taitou/O=MyCA/OU=Web/CN=myca.net'

# ただし今回はこの CA 局が最上位であるとして、自分で自分の証明書を作成。
#   x509: 証明書のサブコマンド。
#   -in: 元になる CSR。
#   -signkey: CA 局の秘密鍵。
#   -days: 有効期限。
openssl x509 -req -in ca-csr.pem -signkey ca-private-key.pem -days 30 -out ca-crt.pem

サーバ証明書を発行します。

# サーバ証明書発行。
#   -CA: CA 局の証明書。
#   -CAkey: CA 局の秘密鍵。
#   -CAcreateserial: この CA 局において一意な文字列。自分で決めたい場合は -set_serial xxx とする。
openssl x509 -req -in server-csr.pem -CA ca-crt.pem -CAkey ca-private-key.pem -CAcreateserial -days 30 -out server-crt.pem

# 完成したファイルの内容を見ます。
openssl x509 -in server-crt.pem

server-crt.pem

オマケ: サーバ証明書の中身

# サーバ証明書の中身を確認。 
openssl x509 -in server-crt.pem -text -noout

server-crt.pem

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            0d:c0:39:6d:e3:e5:b5:c9:1a:21:65:e6:52:57:8a:bf:bf:2f:40:ca
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = JP, ST = Tokyo, L = Taitou, O = MyCA, OU = Web, CN = myca.net, emailAddress = me@myca.net
        Validity
            Not Before: Dec 20 07:05:26 2019 GMT
            Not After : Jan 19 07:05:26 2020 GMT
        Subject: C = JP, ST = Aomori, L = Hirosaki, O = Mate, OU = Web, CN = mate.org, emailAddress = me@mate.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (512 bit)
                Modulus:
                    00:cb:a1:10:48:94:92:96:f6:b0:93:91:04:8e:c6:
                    4e:6b:d9:cc:4b:78:d4:fa:1f:89:93:bf:1d:d6:01:
                    ec:04:6c:3a:16:2b:af:2b:47:5f:02:39:d4:12:28:
                    99:23:42:d2:0f:df:e9:9e:f4:59:e8:49:6f:bf:ed:
                    f6:b4:04:02:47
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         92:6d:b4:9e:d8:53:da:9f:ac:20:bd:43:9d:17:8f:2a:af:a5:
         36:4d:6e:fc:13:14:bb:2c:96:90:2c:66:0c:7f:9c:62:48:f3:
         dd:df:44:7a:70:50:2f:30:c1:82:d6:71:db:99:60:b1:17:62:
         e1:be:a2:af:7c:19:ee:91:c8:8e

疑問: 最後の Signature Algorithm の部分が電子署名だと思っているが正しいのか。

オマケ: サーバ証明書には公開鍵が含まれる

# サーバ証明書の中身を確認。
openssl x509 -in server-crt.pem -pubkey -noout

-----BEGIN PUBLIC KEY-----
MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMuhEEiUkpb2sJORBI7GTmvZzEt41Pof
iZO/HdYB7ARsOhYrrytHXwI51BIomSNC0g/f6Z70WehJb7/t9rQEAkcCAwEAAQ==
-----END PUBLIC KEY-----

サーバの公開鍵と同じです。

CA 局: サーバ証明書をサーバへ送付

サーバ: クライアントへサーバ証明書を送付

クライアント: サーバ証明書を検証

サーバから「サーバ情報と、サーバ公開鍵と、 CA 局自身の証明書と、電子署名のセット」が届きました。これらの情報が正しいものなのか検証します。

# サーバ証明書の検証。
#   -CAfile: 送られてきたすべての証明書。
openssl verify -CAfile ca-crt.pem server-crt.pem

server-crt.pem: OK

サーバ証明書について OK が出ました。

疑問: ここで具体的には何を行っているのかわからない。 PC にあからじめインストールされている CA 局の公開鍵によって電子署名の部分を復号化している? しかし今回の電子署名は私が適当に作ったものであり、対応する公開鍵がインストールされているわけがない。なぜ OK が出ているのだろう。
- (2019-12-23)コメントをいただき「今回の電子署名は私が適当に作ったものであり、対応する公開鍵がインストールされているわけがない。なぜ OK が」という点について追記します。なぜかといえば、 -CAfile オプションのおかげでした。「対応する公開鍵がインストールされているわけではない」と言ったものの、ここで指定している ca-crt.pem に CA 局の公開鍵が含まれているのでした。それが「最初からインストールされている認証局証明書」と同じ扱いになっているそうです。

クライアント: 共通鍵を作成

サーバ情報とサーバ公開鍵が正しいことがわかり、自分が通信を行おうとしている相手が、意図したとおりのサーバであることがわかりました。このまま公開鍵と秘密鍵の暗号化復号化でやりとりを行いたいところですが、 RSA の計算はどうやら重いようで、以降は共通鍵を使ったより計算の容易なメッセージをやりとりすることにします。こういった、共通鍵の受け渡しにだけ公開鍵方式を使い、以降のやりとりを共通鍵方式で行うものをハイブリッド方式と呼ぶようです。

実際にどんな共通鍵が作られるのかわからないので、今回は openssl aes-256-cbc コマンドで再現を試みます。今回のパスワードは password としてみます。

echo 'password' > common-key

クライアント: 共通鍵をサーバ公開鍵で暗号化してサーバへ送付

# 共通鍵をサーバ公開鍵で暗号化。
cat common-key | openssl rsautl -encrypt -pubin -inkey server-public-key.pem > encrypted-common-key
# NY`B□□'□v~)c□f˸~□□L□^C/Ï□&A□□□2□□□y□□□□□M□G□a□□□□w^□u

サーバ: 共通鍵をサーバ秘密鍵で復号化。

# 共通鍵をサーバ秘密鍵で復号化。
cat encrypted-common-key | openssl rsautl -decrypt -inkey server-private-key.pem
# password

クライアント、サーバ: 共通鍵を使ってやりとり

両方に共通鍵が行き渡ったので、あとは

片方が共通鍵で暗号化
もう片方が復号化

というかたちでメッセージのやり取りが可能です。

# 送りたいメッセージ。
echo 'HELLO' > message

# 送りたいメッセージを共通鍵で暗号化。
openssl aes-256-cbc -e -pass file:common-key -in message -out encrypted-message
# Salted__1□□q□□:q□ہ□/□□܊□ꀐ□

# 送られてきたメッセージを共通鍵で復号化。
openssl aes-256-cbc -d -pass file:common-key -in encrypted-message -out decrypted-message
# HELLO

疑問まとめ

RSA が DHE に変わったら、このフローはごっそり変わるのか?
ディスティングイッシュネームとは?
電子署名は「サーバ情報とサーバ公開鍵をくっつけて(?)ハッシュ化し、 CA 局の秘密鍵によって暗号化したもの」なのか?
サーバ証明書の検証は具体的には何をどう検証しているのか?

本当にもう正当性のあやしいしょうもないノートですが、今の所の理解をサマリしたくて書いてみました。

特に参考になったページさま方

ちゃんと理解するSSL/TLS 前編
- 全体的に理解の助けになりました。
ゼロからわかる SSL/TLS の解説を試みる
- ここが私には一番わかりやすかったです。
SSHの公開鍵認証における良くある誤解の話
- SSL ではないのですが、「SSHの公開鍵認証の説明がデマばかりなので、少しはちゃんとした説明もあった方が良いかもな」という言葉で、すべての情報を鵜呑みにしないよう気をつけるようになりました。
公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと
- 公開鍵と暗号鍵は両方向に暗号化と復号化を為せる、というのは誤解であるというお話。
SSLを改めて理解してから AWS Client VPN に挑む
- これまでの記事でよくわからなかった部分の理解の助けになりました。
エンジニアなら知っておきたい、絵で見てわかるセキュア通信の基本
- これまでの調査と、 TLS1.2 や DHE というワードとがつながりました。
RSA鍵、証明書のファイルフォーマットについて
- pem 形式などの解説がとてもわかりやすいです。 openssl コマンドをまじえた SSL 解説の全体的な理解に役立ちました。
opensslでRSA暗号と遊ぶ
- openssl rsa -text の内容について解説してくれています。
秘密鍵、公開鍵、証明書、CSR生成のOpenSSLコマンドまとめ
- openssl コマンドのいろいろなパターンを記述されいます。今回の調査でよくわからなかった電子署名にも触れられているので、今後参考にさせていただきます。

スペシャルサンクス?

ICOOON MONO
- いつも大変お世話になっています。

信用には堪えない、廃止済み RSA 形式の SSL 整理ノート 〜 openssl とイラストをそっと添えて〜

概要