Help us understand the problem. What is going on with this article?

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

概要

16.png

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

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

読む前のご注意

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

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

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

整理ノート

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

1.png

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

サーバ: 秘密鍵を作成

2.png

  • 秘密鍵は暗号化のためのファイルです。対となる公開鍵で暗号化されたメッセージは、これを使って復号化できます。
  • 具体的にはテキストっぽい 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
-----BEGIN RSA PRIVATE KEY-----
MIIBPAIBAAJBAMuhEEiUkpb2sJORBI7GTmvZzEt41PofiZO/HdYB7ARsOhYrrytH
XwI51BIomSNC0g/f6Z70WehJb7/t9rQEAkcCAwEAAQJBAL2Cs4XpCBiJlEJyB5zd
AGUteQ2Qch4qtb6Ucq8WcNKXQXT1z3nFxLyxDicVdYlf2u1Wk5+ef6Pa3ZsPlnYu
CYECIQDvGhL7CNjDJGAQcQ9Gz1NzkzyDCz/9DCJ72ermjdJsQQIhANoFNAvt3G9X
Ov0kmmVEL3v61EtIH/+4+SjIlrkCAeyHAiBEMAltsg4vSLZkufmDVikUcs71CEZN
YiKLc5A8BAIYgQIhAMCRY/09ZTy60ZGSaQUVCtP5ItYzqH/Yw8pwEiDrUwO1AiEA
xto/sKBjUmtSo0ugQmX8v0A9qKPN7f31EmCxN3eUq0I=
-----END RSA PRIVATE KEY-----
  • 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 を作る

3.png

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
-----BEGIN CERTIFICATE REQUEST-----
MIIBNzCB4gIBADB9MQswCQYDVQQGEwJKUDEPMA0GA1UECAwGQW9tb3JpMREwDwYD
VQQHDAhIaXJvc2FraTENMAsGA1UECgwETWF0ZTEMMAoGA1UECwwDV2ViMREwDwYD
VQQDDAhtYXRlLm9yZzEaMBgGCSqGSIb3DQEJARYLbWVAbWF0ZS5vcmcwXDANBgkq
hkiG9w0BAQEFAANLADBIAkEAy6EQSJSSlvawk5EEjsZOa9nMS3jU+h+Jk78d1gHs
BGw6FiuvK0dfAjnUEiiZI0LSD9/pnvRZ6Elvv+32tAQCRwIDAQABoAAwDQYJKoZI
hvcNAQELBQADQQByf/hyAbeIZZWKn4FvOYxSpu+pHksSVhST99SsnAeNHweSt0Ti
LoxBA1XOSQanz6KU+9ggrWLhKcl4o8aksj7j
-----END CERTIFICATE REQUEST-----

オマケ: 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 を送付

4.png

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

CA 局: サーバの検証

5.png

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

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

6.png

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

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

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

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

7.png

# 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

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

8.png

# サーバ証明書発行。
#   -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
-----BEGIN CERTIFICATE-----
MIIB9DCCAZ4CFA3AOW3j5bXJGiFl5lJXir+/L0DKMA0GCSqGSIb3DQEBCwUAMHox
CzAJBgNVBAYTAkpQMQ4wDAYDVQQIDAVUb2t5bzEPMA0GA1UEBwwGVGFpdG91MQ0w
CwYDVQQKDARNeUNBMQwwCgYDVQQLDANXZWIxETAPBgNVBAMMCG15Y2EubmV0MRow
GAYJKoZIhvcNAQkBFgttZUBteWNhLm5ldDAeFw0xOTEyMjAwNzA1MjZaFw0yMDAx
MTkwNzA1MjZaMH0xCzAJBgNVBAYTAkpQMQ8wDQYDVQQIDAZBb21vcmkxETAPBgNV
BAcMCEhpcm9zYWtpMQ0wCwYDVQQKDARNYXRlMQwwCgYDVQQLDANXZWIxETAPBgNV
BAMMCG1hdGUub3JnMRowGAYJKoZIhvcNAQkBFgttZUBtYXRlLm9yZzBcMA0GCSqG
SIb3DQEBAQUAA0sAMEgCQQDLoRBIlJKW9rCTkQSOxk5r2cxLeNT6H4mTvx3WAewE
bDoWK68rR18COdQSKJkjQtIP3+me9FnoSW+/7fa0BAJHAgMBAAEwDQYJKoZIhvcN
AQELBQADQQCSbbSe2FPan6wgvUOdF48qr6U2TW78ExS7LJaQLGYMf5xiSPPd30R6
cFAvMMGC1nHbmWCxF2LhvqKvfBnukciO
-----END CERTIFICATE-----

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

# サーバ証明書の中身を確認。 
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 局: サーバ証明書をサーバへ送付

9.png

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

10.png

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

11.png

サーバから「サーバ情報と、サーバ公開鍵と、 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 局の公開鍵が含まれているのでした。それが「最初からインストールされている認証局証明書」と同じ扱いになっているそうです。

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

12.png

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

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

echo 'password' > common-key

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

13.png

# 共通鍵をサーバ公開鍵で暗号化。
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

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

14.png

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

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

15.png

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

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

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

# 送りたいメッセージ。
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 局の秘密鍵によって暗号化したもの」なのか?
  • サーバ証明書の検証は具体的には何をどう検証しているのか?

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

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

スペシャルサンクス?

  • ICOOON MONO
    • いつも大変お世話になっています。
yuu-eguci
水をあげなくても大丈夫な植物。
http://portfolio.hitoren.net/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした