TLS 証明書・TLS プロトコル入門

ネットワーク

対象者

  • TLS(Transport Layer Security)プロトコルを知りたい人
  • TLS 証明書の中身を知りたい人
  • 暗号方式の違いが知りたい人
  • 自己証明書を作成は解説しません
  • 下記の表の説明が欲しい方
共通鍵暗号公開鍵暗号一方向暗号
実現する機能機密性認証共通鍵の交換完全性
具体的な方法暗号化電子署名公開鍵で共通鍵を暗号化ハッシュ
暗号化アルゴリズム・DES
・AES
・RC4
・RSA
・ECDSA
・EdDSA
・ECC
・DH
・ECDH
・ECDSA
・ECDHE
・MD5
・SHA-1
・SHA-2
・SHA-3
メリット高速鍵共有が容易
デメリット鍵共有が困難低速

なお、TLS セットで出てくる SSL という用語は TLS の古いバージョンのことです。SSL は脆弱性が存在しているため [1]、新しいバージョンである TLS を学びましょう。

TLS とは

TLS は通信する2点間に安全な経路を提供するプロトコル(仕様・ルール)です [2] 。

安全な経路とは次の3つから成り立ちます。

  • 認証 (Authentication): 通信相手が正しいことを確認可能
  • 機密性 (Confidentiality): 送信されるデータを盗聴できない
  • 完全性・整合性 (Integrity): 送信されるデータの欠損や改ざんを検出可能

次に、安全な経路を実現するために利用される暗号方式の種類について記載します。

暗号方式

暗号方式は大きく分けて次の3つがあります。

  • 一方向暗号(ハッシュ関数)
  • 共通鍵暗号方式
  • 公開鍵暗号方式

一方向暗号(ハッシュ関数)

元のデータを適当な文字列に変換する関数です。

  • 同じデータを入れると、同じ文字列になります。
  • 変換後の文字列から元のデータを推測できません。

利用用途: 完全性の確認 Mac(message authentication code)

送受信したデータの完全性(欠損が無いか、改ざんが無いか)を確認するために利用します。

  1. 送信前のデータに対してハッシュ関数を使います
  2. 送信後のデータに対してハッシュ関数を使います
  3. 1. 2 が同じであれば、完全性を確認できます。

暗号化アルゴリズムの例

  • MD5
  • SHA-1
  • SHA-2
  • SHA-3

ハッシュ関数のサンプルコマンド

//ハッシュ値を求めるデータ
$ echo HelloWorld > data.txt

//ハッシュ関数SHA-256(SHA-2)を利用し、ハッシュ値を求める
$ openssl sha256 < data.txt 
(stdin)= 89c99d37500be2061f853db3a4da2fcce4c0fc0f2f2b71bc2238acca0967c3b7

//元のデータが改ざんされない限り、同じ値になる 
$ openssl sha256 < data.txt
(stdin)= 89c99d37500be2061f853db3a4da2fcce4c0fc0f2f2b71bc2238acca0967c3b7

//元のデータを改ざん 
$ echo GoobyeWorld > data.txt

//ハッシュ値が違うので改ざんを検知可能 
$ openssl sha256 < data.txt
(stdin)= 172666081ff2e826232b1a3ed3bbfcaa9b3056b2a79f8854b562cf17a1b46d13

共通鍵暗号方式

自分と相手だけが持つ鍵(共通鍵)を用意します。

共通鍵で暗号化されたデータは共通鍵で復号化できます。(つまり復号化できるのは、共通鍵を持つ相手と自分だけ)

利用用途: 機密性の確保 Enc(encryption)

送信するデータの暗号化することで機密性を確保します。
処理が軽いため、通信速度の低下を最小限に抑えます。

暗号化アルゴリズムの例

  • DES
  • AES
  • RC4

共通鍵暗号のサンプルコマンド

//暗号化するデータを作成
$echo HelloWorld > data.txt

//共通鍵を作成(今回はランダムな32文字を共通鍵とします)
$ openssl rand 32 -out common_key.txt -base64

//データ(data.txt)を共通鍵(common_key.txt)でAES128を使って暗号化
$ openssl enc -e -aes128 -kfile common_key.txt -in data.txt -out encrypt.txt -base64

//元のデータ
$less data.txt
HelloWorld

//暗号化後のデータ
$less encrypt.txt
U2FsdGVkX18w4ce8ZuMsgmqBsLtYeHuvipXOSqrNHes=

//共通鍵を使用して復号化
openssl enc -d -aes128 -kfile common_key.txt -in encrypt.txt -out decrypt.txt -base64

//復号化後のデータ
$less decrypt.txt
HelloWorld

補足

共通鍵暗号方式は暗号化する方式のことを指し、共通鍵自体の生成は鍵交換アルゴリズム(後述)を利用することが多いです。

公開鍵暗号方式

全世界に公開する鍵(公開鍵)と、自分だけが持つ鍵(秘密鍵)を用意します。

公開鍵で暗号化されたデータは、秘密鍵でのみ復号化できます。
(つまり復号化できるのは自分だけ!共通鍵の交換に使います。)
秘密鍵で暗号化されたデータは、公開鍵でのみ復号化できます。
(つまり公開鍵で復号化可能な暗号文を作成できるのは自分だけ!電子署名に使います。)

利用用途1: 鍵交換アルゴリズム: Kx(key exchange)

鍵交換アルゴリズムは公開鍵暗号方式を利用して、共通鍵暗号方式で利用する共通鍵を安全に送信、作成するものです。

共通鍵暗号方式では以下のような問題があります。

  1. データを暗号化、復号化するためには、共通鍵 X を相手に送信する必要があります
  2. 共通鍵 X (データ)を安全に送信するためには暗号化が必要です。(1へ戻る)

この時、共通鍵 X 自体はどうやって相手に安全に送るのでしょうか?答えは鍵交換アルゴリズムを利用して共通鍵 X を相手に送信します。

鍵交換アルゴリズムをざっくり説明すると次のとおりです。

  1. お互いの公開鍵を送り合います
  2. Aさんは 相手の公開鍵Bと自分の秘密鍵Aから共通鍵 X1 を生成します
  3. Bさんは 相手の公開鍵Aと自分の秘密鍵Bから共通鍵 X2 を生成します
  4. この共通鍵 X1 と X2 が同じになるアルゴリズムが鍵交換アルゴリズムです

公開鍵は盗聴されてもOKなので送信してOK。共通鍵を生成できるのは秘密鍵を持ったAさんとBさんだけです。

鍵交換アルゴリズムの例

  • DH
  • ECDH
  • ECDSA
  • ECDHE

公開鍵暗号で暗号化するサンプルコマンド

//秘密鍵の作成
$ openssl genrsa > private.key

//公開鍵の作成
$ openssl rsa -in private.key -pubout -out public.key

//暗号化するデータ
$ echo HelloWorld > data.txt

//公開鍵でデータを暗号化
$ openssl rsautl -encrypt -pubin -inkey public.key -in data.txt -out data.encrypt

//暗号化したデータはバイナリ
$ hexdump data.encrypt
0000000 8a 61 e4 d4 5b fd 3f fd 74 bc 66 46 34 03 1e b9
0000010 76 11 a4 49 e0 64 37 37 bc 71 df 9f 80 d7 e7 e8
0000020 5d 74 a4 29 f5 48 1c 1f f2 f6 59 4c 14 9b ac 2d
0000030 bc 5c f4 76 23 c9 4e 03 bd b8 da 7c f9 6e 3e ff
0000040 c9 ba e7 69 01 96 11 0a 06 36 ae f4 d8 14 aa 22
0000050 46 a4 7f be 58 3f 59 bf 17 e1 ad 3b 94 a2 a3 b7
0000060 dd 25 69 38 d1 13 d4 12 d4 03 e9 f1 32 5b 09 04
0000070 ef b3 7e 69 f6 9e f3 1c 1b 83 f0 5d 9b f0 31 e8
0000080 3e 46 b0 0e 67 f3 1b ee c8 6e ec a9 07 99 f1 70
0000090 12 64 cb b6 66 3d 5d c9 a0 14 52 3f 19 5a 0b ad
00000a0 12 3e 58 75 a6 e0 73 84 75 f2 0c 0c 80 13 6c 9a
00000b0 4b 50 84 90 3e bb b8 96 9e 29 28 8e c5 53 85 13
00000c0 d6 25 56 0c a0 e6 2c 02 e7 64 1a ce c2 98 44 94
00000d0 0d a0 71 63 dd 23 16 b2 df 4f a4 1c e7 e2 81 a5
00000e0 94 f5 ed ff 81 5a 2c da d0 7c 5e f2 d4 63 a7 b5
00000f0 65 74 11 ca e7 6a 2a fa 8a d5 7e f6 64 09 99 3f
0000100

//秘密鍵で復号化
$ openssl rsautl -decrypt -inkey private.key -in data.encrypt
HelloWorld

//全く関係の無い秘密鍵で復号化するとどうなるか?
//秘密鍵の作成
$ openssl genrsa > private2.key

//関係ない秘密鍵で復号化するとエラーで復号化できない。
$openssl rsautl -decrypt -inkey private2.key -in data.encrypt
RSA operation error

-->鍵交換アルゴリズムでは上記を利用して公開鍵で共通鍵を暗号化します。

利用用途2: 認証 Au(authentication)

共通鍵で復号できるデータを、秘密鍵を持つ自分だけ作成できることから、自分を証明する電子署名鍵認証)として利用できます [3]。(正確にはハッシュ関数+公開鍵暗号を使用します。)

暗号化アルゴリズムの例

  • RSA
  • ECDSA
  • EdDSA
  • ECC

公開鍵暗号で電子署名をするサンプルコマンド

//RSAアルゴリズムで秘密鍵を作成
$ openssl genrsa > private.key 

//RSAアルゴリズムで公開鍵の作成 
$ openssl rsa -in private.key -pubout -out public.key

//暗号化するデータ
$ echo HelloWorld > data.txt

//SHA256 ハッシュ関数、秘密鍵を使用して document.txtの電子署名を作成します。 $ openssl dgst -sha256 -sign private.key data.txt > sign.sig

// 電子署名の中身
$ hexdump sign.sig
0000000 9b 1e 19 eb 53 80 d9 8d d7 bf d7 fb 4a ca 89 da
0000010 9a 20 8e 46 13 98 c9 9f 72 28 0b d6 06 24 27 88
0000020 a8 d2 49 b6 15 23 f7 4f ac 71 ca 82 cc 0d 89 b8
0000030 35 fc 86 8f d3 fa 9d 5d 8a 14 cb d7 4e 5b 7f 5c
0000040 a3 f8 74 b9 57 ec 68 17 1d 20 44 b2 fe 67 23 13
0000050 df 1b 65 46 b8 d7 ac 27 c3 5e e5 e1 4a 42 35 c5
0000060 73 31 54 99 92 db ff 02 c3 43 78 f5 21 73 66 ac
0000070 55 3f c5 6d 66 31 5d 23 51 4e d8 ca 67 ac 2b 74
0000080 a4 68 a2 34 60 ec a8 72 17 e2 cd 74 dd 76 5a 0b
0000090 3f 2f a8 8a d7 5a f1 4f 76 42 ef 1f 16 ad 73 9d
00000a0 ab 2c 6e 99 fa 04 bf 72 ce 34 d9 2d 5d 1e d3 50
00000b0 88 15 e8 6f 1c 73 5c 6a ba ba 44 9c fd 91 17 d6
00000c0 d1 b1 f5 fc 16 2c b9 0c 45 09 a8 7a ad b6 46 dd
00000d0 be d3 8e f8 74 3e 21 21 78 fe 44 a5 a6 3f e7 ee
00000e0 bc 86 ce 08 a6 dd b6 94 09 42 b9 5c 17 9b c6 91
00000f0 62 2f 79 1b 1b 15 1c 85 d0 26 b5 e9 36 e1 93 f3
0000100

//電子署名を検証する。
$ openssl dgst -sha256 -verify public.key -signature sign.sig data.txt Verified OK

//以下の2つが一致することを確認
//公開鍵を使用して電子署名 sign.sig を復号化
//document.txt にハッシュ関数 sha256を使用してハッシュ値を求める

補足

Q: 機密性の確保に公開鍵暗号方式を使えば、鍵交換する必要無くないですか?

A: 公開鍵暗号方式の復号化には計算時間がかかります。通信する度に復号に時間を掛けていては、通信速度が低下しますので、計算時間が少ない共通鍵を使用します。

補足: Cipher Suite(暗号スイート)

下記の4つのアルゴリズムの組を Cipher Suite と呼び、TLS プロトコルを用いて通信する際に指定します。

  • 共通鍵暗号アルゴリズム
  • 公開鍵暗号アルゴリズム
    • 鍵認証アルゴリズム
    • 鍵交換アルゴリズム
  • 一方向暗号(ハッシュ関数)アルゴリズム

以下のコマンドを利用することで、Linux で利用可能な Cipher Suite を確認することができます。

$ openssl ciphers -v 'ALL'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
(中略)

例えば1行目の “ECDHE-RSA-AES256-GCM-SHA384” は以下の意味を表します。

  • TLS のバージョン = TLSv1.2
  • 鍵交換アルゴリズム(Kx)= ECDH
  • 鍵認証アルゴリズム(Au)= RSA
  • 共通鍵暗号アルゴリズム(Enc)= AESGCM(256)
  • 一方向暗号(ハッシュ関数)アルゴリズム(Mac)= AEAD

TLS を実現する技術

2点間に安全な通信経路を提供するために、TLS は次の2つのプロトコルにより認証・機密性・完全性を実現します。

  1. TLS ハンドシェイクプロトコル(相手を認証して共通鍵を交換する)
    1. TLS 証明書を交換する
    2. 電子署名(ハッシュ関数)を利用して、TLS 証明書の完全性を保証する
    3. 電子署名(公開鍵暗号)を利用して、通信相手を認証する。
    4. 認証した通信相手と鍵交換アルゴリズムを利用して共通鍵を交換する
  2. TLS レコードプロトコル(共通鍵で通信を暗号化する)
    1. 送信するデータにハッシュ関数を利用して、完全性を保証する
    2. 送信するデータに共通鍵暗号を利用して、送信するデータの機密性を確保する

以降では初めて登場した用語「TLS 証明書」について説明をしていきます。

なお、TLS プロトコルは様々なアプリケーションプロトコルで利用できますが、今回は HTTPS プロトコルで TLS プロトコルを利用する例を見ていきます。

TLS 証明書の詳細

TLS 証明書は通信相手を認証するために使用します。証明書が本物であることは、信頼できる第三者が認証します。この信頼できる第三者を認証局(CA、Certificate Authority)と呼びます。

認証局が必要な理由

もし認証局がいない場合、証明書を送って来た Web ページは必ず以下のように「この証明書は本物なんですよ」と言います。

  • 正規のWebページ「この証明書は本物なんですよ」
  • 悪意のあるWebページ「この証明書は本物なんですよ」

そのため、信頼できる第三者が証明書を本物であることを保証する必要があります。

TLS 証明書を使用して通信相手を認証する手順

通信相手を認証する手順は次のとおりです。

  1. 信頼できる認証局を設定する(/etc/pki/tls/certs/ca-bundle.crt)
  2. 通信相手の提供する証明書を受け取る
  3. 証明書の電子署名のハッシュを利用して完全性を確認する
  4. 証明書の電子署名の公開鍵暗号を利用して認証する(1で設定した信頼できる認証局が認証していることを確認)

信頼できる認証局を設定

主要な信頼可能な認証局は PC やスマホ出荷時に許可されてます。そのため、通常は特に必要ない操作です。

//信頼する認証局の証明書
$ less /etc/pki/tls/certs/ca-bundle.crt

//追加で信頼する認証局の証明書を配置
$ sudo cp <追加で信頼する認証局の証明書> /usr/share/pki/ca-trust-source/anchors

// "/etc/pki/tls/certs/ca-bundle.crt" の内容を更新する
$ sudo update-ca-trust extract

通信相手(サーバー)が提供する証明書を確認

サーバーが提供する TLS 証明書の中身は openssl コマンドの -showcerts オプションにて確認できます。google.com を例に TLS サーバー証明書の中身を見ていきます。

$ openssl s_client -connect google.com:443 -showcerts 0> /dev/null

depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com
(中略)

証明書の各要素は以下の意味を表します。

要素説明
depth証明書チェインの深さ(後述します)
C
ST州(都道府県)
L都市(市区町村)
O組織名(企業名)
OU部門名
CN一般名(ドメイン)

例えば、一番最後の行は次の意味を表します。

depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com

C = US --> アメリカ
ST = California --> カリフォルニア州
L = Mountain Vie --> マウンテンビュー
O = Google LLC --> Google LLC という企業
CN = *.google.com --> *.google.com の証明書

証明書チェイン

*.google.com の証明書を認証する認証局の証明書Aが正しいかどうかを判断するにはどうすればよいでしょうか。答えは認証局Bが認証局Aの証明書を認証します。

このように認証が連鎖することを証明書チェインと呼びます。

証明書チェインの具体例

先程の *.google.com の証明書を例を見てみましょう。

$ openssl s_client -connect google.com:443 -showcerts 0> /dev/null
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com

こちらは以下の意味を表します。

  • Google LLC「CN = *.google.com は本物ですよ。CN = GTS CA 1O1 が証明してるからね」
  • Google Trust Services「CN = GTS CA 1O1 は本物ですよ。GlobalSign が証明してるからね」
  • GlobalSign「CN = GlobalSign は本物ですよ。俺が言うんだから間違いない」

最後に「俺が言うんだから間違い無い」と言う認証局はルート認証局と呼ばれます。

今回の証明書チェインのルート認証局である GlobalSign は GMO 系列の会社ですね。

グローバルサイン - Wikipedia

なお、GlobalSign Root CA – R2 は以下のようにデフォルトで信頼されている認証局となります。

$ less /etc/pki/tls/certs/ca-bundle.crt

GlobalSign Root CA - R2
-----BEGIN CERTIFICATE-----
MIIDujC(中略)
-----END CERTIFICATE-----

TLS 証明書の種類

TLS 証明書には、認証局が認証した方法により次の3種類に分かれます。

  • ドメイン認証(DV)
    • ドメイン(google.comなど)を所有しているかどうかを確認します
  • 組織認証(OV)
    • 組織の住所や会社名を確認します
  • 実在認証(EV)
    • 組織が本当に存在するのかきっちり確認する
      • 帝国データバンクなどで組織の情報を確認
      • 代表者に電話かける

電子署名(認証・完全性)

ルート認証局(ここでは GlobalSign)が google.com の証明書を認証したことを確認するには電子署名を確認します。電子署名が無いと先程と同じように以下のとおりとなります。

  • google「この証明書は GlobalSign に本物と証明されています」
  • 悪意のあるWebページ「この証明書は GlobalSign に本物と証明されています」

電子署名の作成手順

電子署名は以下の手順で作成します。

  1. TLS サーバー証明書にハッシュ関数を使用してハッシュを作成する(完全性の保証)
  2. ハッシュに対して、秘密鍵を用いて暗号化する

openssl コマンドを利用して電子署名を作成する方法は以下のとおりです。

//RSAアルゴリズムで秘密鍵を作成します
$ openssl genrsa > private.key

//SHA256 ハッシュ関数、秘密鍵を使用して document.txtの電子署名を作成します。
$ openssl dgst -sha256 -sign private.key document.txt > sign.sig

電子署名の実体

$ hexdump sign.sig
0000000 f663 4396 ea2f 6ab1 e870 8424 897a cacf
0000010 d7a3 3cf0 8855 86e7 a5d4 2045 10e7 ab60
0000020 676e 147c e16e ff48 0679 9774 1405 0132
0000030 881f d88e 4345 be47 a19d 29ba 18aa c9c5
0000040 1022 8858 712b 0ea7 8875 ecf1 2c19 168b
0000050 6829 efca f152 9e0a e011 8872 a914 6d55
0000060 bae8 4cab 13ef 7fd8 237b b4cb b720 4b4a
0000070 6b41 59ee ac96 050a 9330 2446 bb1d c0d7
0000080 738f 9b41 12e7 3c8d 1b49 c5db d898 706f
0000090 819e 4470 c742 700e 7d14 0bc3 b697 9db4
00000a0 1cf1 0c68 72f8 0c1d 1bb8 4543 a44e 4d02
00000b0 e722 0c5c 7202 914d 0034 61bf 292f 48c9
00000c0 90bf 536a b481 1a87 a6a0 d535 2957 4a05
00000d0 f2bf 1c08 16af a535 2866 408f 6b62 2a92
00000e0 02f7 f1fd 3638 3b7a 7409 a32e 869f e843
00000f0 e7c2 008b b27f 3c47 3e62 5917 bcb8 0400
0000100

電子署名の検証手順

電子署名は以下の手順で正しいことを検証します。

  1. サーバーから受け取った TLS サーバー証明書にハッシュ関数を使用してハッシュを作成する
  2. 電子署名に対して公開鍵を用いて復号化する
  3. 1と2が同じであれば本物(本物の秘密鍵以外で暗号化されている場合、復号化した結果が一致しない。)

秘密鍵を持っているのは、本物の認証局だけなので、電子署名によりルート認証局がたしかに認証した証明書であることが検証できます。

openssl コマンドを利用して電子署名を検証する方法は以下のとおりです。

//公開鍵の作成
$ openssl rsa -in private.key -pubout -out public.key

//電子署名を検証する。以下の2つが一致することを確認
//公開鍵を使用して電子署名 sign.sig を復号化
//document.txt にハッシュ関数 sha256を使用してハッシュ値を求める
$ openssl dgst -sha256 -verify public.key -signature sign.sig document.txt
Verified OK

ルート認証局の公開鍵で復号できる暗号を作成を作成できるのは、本物の認証局が持つ秘密鍵だけです。なので通信相手は本物と認証できます。

証明書にハッシュ関数を適用して同じ値となるのは、同じ証明書の場合だけです。なので証明書の完全性を保証できます。

電子署名を具体例(google.com)で確認

下記のコマンドで TLS サーバー証明書の詳細を確認し、電子署名に関連する情報を確認します。

$ openssl s_client -connect google.com:443 -showcerts < /dev/null | openssl x509 -text

depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com
verify return:1

Public Key Algorithm: rsaEncryption
 Public-Key: (2048 bit)
  Modulus:
   00:ba:b5:b9:2a:79:2b:52:74:6d:85:bc:b5:ff:ad:


Signature Algorithm: sha256WithRSAEncryption
 c5:1b:7d:32:be:2c:1d:1f:7e:15:d0:9a:19:29:f2:f4:2e:8e:

上記のコマンドにより、 TLS 証明書には電子署名、および検証に必要な項目が全て含まれていることがわかります。

  • Signature (電子署名)
  • Algorithm: sha256WithRSAEncryption(電子署名で使用するハッシュ関数と公開鍵暗号)
  • depth(証明チェイン)
  • Public Key(公開鍵)

証明チェインに従って順番に検証を行い、ルート認証局まで検証が完了すれば認証完了です。なお、ルート認証局である 「GlobalSign Root CA – R2」は /etc/pki/tls/certs/ca-bundle.crt で信頼している必要があります。

参考ページ

[1] 更新:SSL 3.0 の脆弱性対策について(CVE-2014-3566)
https://www.ipa.go.jp/security/announce/20141017-ssl.html

[2] The primary goal of TLS is to provide a secure channel between two communicating peers; the only requirement from the underlying transport is a reliable, in-order data stream. Specifically, the secure channel should provide the following properties:

https://tools.ietf.org/html/rfc8446

[3] – Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via asymmetric cryptography (e.g., RSA [RSA], the Elliptic Curve Digital Signature Algorithm (ECDSA) [ECDSA], or the Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032]) or a symmetric pre-shared key (PSK).

https://tools.ietf.org/html/rfc8446
httpsだからというだけで安全?調べたら怖くなってきたSSLの話!? - Qiita
課題 サイトをを立ち上げるときに当然のごとくSSL証明書をベンダーから購入して設置していたが、いざセキュリティ診断等でチェックしてもらうとSSLについての指摘を何件か受けてみた。なんでだろうと思いながらも、さらに最適なSSL設定...
0

コメント

タイトルとURLをコピーしました