インフラエンジニア勉強雑記

インフラ技術に関して勉強したメモを残したものです。誤っている内容があればコメントもしくはメッセージでお知らせいただけると助かります。

SSL/TLSについて⑤ SSLの終端機器

 1.SSL/TLSの負荷に関して

SSLをサーバ側で有効化すると、負荷が増大します。CPUの処理能力が下がってしまって、当初の想定よりもスループットが出ない可能性が出てきます。

今後実測で行う機会があればSSLを有効化しなかった場合、有効化した場合(鍵長の差異など)も比較できればと思っております。

2.サーバの処理増加対策

サーバ側でSSLの処理を行う場合、クライアントとサーバ間でSSLを終端しています。

別の手法としてサーバの手前で別機器によってSSLを復号化し、サーバの負荷を下げることが多くの企業によって行われております。

f:id:light-spoqz:20190207224303j:plain

SSL復号化機器にサーバ証明書秘密鍵をもたせておき、クライアントとSSL復号化機器間はHTTPS通信を行います。SSL復号化機器とWebサーバ間ではHTTP通信を行います。

世の中にはSSL復号化に特価した製品や適した製品が多くあります。

  • F5社 BIG-IP
  • A10社 Thunder
  • Citrix社 NetScaler

上記に記載した機器は公開サーバ向け製品です。インターネットから特定のサーバに対してSSL通信を行う場合に使用されます。

また、上記機器は負荷分散装置としてWebサーバの手前に設置されることが多く、SSLの復号化と負荷分散を1台で行えるため、使用されることが多いです。

3.クライアントの通信可視化

企業の対策は外部からのアクセスのみではありません。クライアント端末がインターネット上の不正なサーバにアクセスしていたことが判明したとき、企業はその原因を究明する必要があります。仮にフォレンジック装置などを導入していても、HTTPS通信が行われていた場合、企業としては通信内容を確認することができません。

そのためにSSL復号化機器を導入します。BIG-IPやA10と異なる点はSSL復号化機器にもたせるものは秘密鍵のみという点です。BIG-IPやA10の方式で本内容を行おうとすると、インターネット上のサーバ証明書を作成し、BIG-IPに持たせなければなりません。それを防ぐために秘密鍵でWebサーバから取得したサーバ証明書の中身を盗み見て、自身の秘密鍵で署名のみ行います。クライアントに秘密鍵に対応したルート証明書をインポートする必要があります。

クライアントからみたサーバ証明書はすべて同じルート認証局で署名されているはずです。復号化したパケットはUTMやフォレンジックに流れることで、セキュリティの監査やパケットの保存が行なえます。

f:id:light-spoqz:20190207225101j:plain

以下のような製品があります。

  • Symantec社 BlueCoat(2016年にBlue Coat社がSymantec社に買収されました)
  • アルチザ社 AISVA(調べたら出てきました、、、多分上記のようなことができるはず)

特にBlueCoatは昔からSSL復号化に特価した製品があることで定評があります。

以下の用途で製品は分かれています。

  • SSL VA(インラインで復号化する機器、UTMなどを復号化区間に挟み込んで使用します。)
  • Proxy SG(プロキシサーバで、HTTPS通信は復号化して対象機器に投げる)

 

4.まとめ

  • SSLを使用するとサーバが重くなるので設計には気をつける。
  • 設計で考慮したくないのであればSSL復号化装置を導入するのも良い。
  • クライアントからWebに対する通信を復号化すればセキュリティインシデント発生時に原因分析が楽になるが、専用の装置が必要。

 

SSL/TLSについて① SSL/TLS通信の概要 - インフラエンジニア勉強雑記

SSL/TLSについて② SSLの通信フロー - インフラエンジニア勉強雑記

SSL/TLSについて③ 証明書とは - インフラエンジニア勉強雑記

SSL/TLSについて④ 証明書の発行方法、ルート証明書のインポート方法 - インフラエンジニア勉強雑記

SSL/TLSについて⑤ SSLの終端機器 - インフラエンジニア勉強雑記

SSL/TLSについて⑥ SSLハンドシェイク - インフラエンジニア勉強雑記

SSL/TLSについて③ 証明書とは

 

1.用語説明

用語の説明を行います。

  • ルート認証局:自分自身で自身が正しい証明機関だと証明できる認証局です。通常は中間認証局のように上位の証明機関(ルート証明機関など)から正しい認証局だと証明してもらう必要がありますが、ルート認証局は不要となります。例としてVerisignやEntrustなどがあります。
  • 中間認証局:上位の認証局に信頼できる認証局と証明された認証局です。外部公開用のサーバはこの中間認証局から証明書を発行してもらうことになります。
  • CSR(Certificate Signing Request):証明書の発行を依頼するために依頼元の組織で発行するための証明書です。

2.証明書とは

2.1.証明書の概要

正しくは電子証明書といいます。証明書は信頼できる機関(認証局)が発行することで、サイトやクライアントが安全であることを証明します。

以下のような証明書があります。

  • サーバ証明書:アクセス先のサーバが信頼できるサイトであることを証明するための証明書。HTTPSなどで公開しているWebサーバで使用されることが多いかもしれません。
  • ユーザ証明書:対象のユーザもしくはデバイスが信頼できるものであることを伝えるための証明書。無線や有線でNWに接続する際の802.1X認証や銀行での認証で使用されることが多いかと思います。

ではどのように証明書が発行されるのかを説明します。サーバ証明書を例として説明します。

f:id:light-spoqz:20190203153144j:plain

①証明書発行依頼組織がサーバ(OpenSSLがインストールされているLinux,アプライアンス製品など)でCSRの発行を行います。秘密鍵CSRが生成されます。

②発行したCSRを中間認証局に送信します。

③中間認証局秘密鍵で本内容から証明書を生成します。

④中間認証局は生成した証明書を依頼組織に対して返送します。

上記が簡単ですが、流れとなります。ルート認証局から証明書送信とありますが、ルート認証局が中間認証局が信頼できると事前に証明しているため、このフローは不要です。

本手順はインターネット上に公開する場合のサービスとなっております。インターネット上に公開する場合は不特定多数の人が閲覧するため、ルート証明書保有しているクライアントでないとエラー画面が表示されてしまいます。自己証明書であれば先程の手順のように外部認証機関から証明書の発行は不要となります。

2.2.署名とは

上記でCSRに署名を行うことで証明書が作成されると記載しましたが、具体的な動きを説明します。まず以下はCSRの内容です。

Certificate Request:
   Data:
      Version: 0 (0x0)
      Subject: C=JP, ST=Tokyo, L=Default City, O=test inc, OU=IT test, CN=test.com
      Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
         Public-Key: (2048 bit)
         Modulus:
            00:d3:cf:af:cf:32:7f:3c:29:c4:cf:45:be:c8:1e:
            16:e4:66:98:6c:02:9f:75:c9:07:d4:01:95:61:af:
            6c:c9:d1:2d:ea:94:b4:5e:e3:0c:6a:3c:a9:27:25:
            5d:7e:90:e6:dd:69:3c:fe:d3:21:55:b4:b9:bd:34:
            3f:25:9f:d5:b9:5c:b6:d9:6e:94:90:a2:9e:46:01:
            64:86:59:0d:9c:90:ab:02:e9:b1:cb:26:58:4b:19:
            db:ef:6c:52:5d:a6:f4:dc:2d:b9:39:7e:97:53:f6:
            97:71:b6:26:b8:9f:d4:f9:94:13:ab:6d:ac:42:2e:
            9c:03:d5:94:70:0a:ae:2d:a4:44:56:75:80:ea:c3:
            5a:df:42:d6:b9:2e:a5:45:e2:cf:3f:2b:c8:f3:2d:
            e3:ed:9c:58:fe:74:dc:a5:0b:7a:b3:40:8b:8b:65:
            f9:39:3f:6f:6b:b3:4b:41:d0:a7:ce:89:8c:56:52:
            f0:b9:67:0d:39:b3:76:65:ba:f4:9a:35:e3:6d:23:
            dd:78:52:22:17:f6:86:00:b6:58:a8:da:1c:b4:84:
            f6:02:b8:de:ac:01:11:8a:f1:86:23:7b:50:1a:95:
            da:15:53:ce:98:4c:fd:41:0d:dd:e4:e8:79:ed:30:
            11:7f:bd:0b:1b:b9:c5:83:70:56:8a:9a:01:df:73:
            89:59
         Exponent: 65537 (0x10001)
      Attributes:
      Requested Extensions:
         X509v3 Basic Constraints:
            CA:FALSE
         X509v3 Key Usage:
            Digital Signature, Non Repudiation, Key Encipherment
         X509v3 Subject Alternative Name:
            DNS:test.com, DNS:*.test.com
   Signature Algorithm: sha256WithRSAEncryption
      10:cf:11:1b:a7:d2:f6:a9:e8:76:2c:73:4e:13:4c:1b:a1:e1:
      b9:d7:16:19:2a:93:c6:fa:fa:ad:d9:6f:1d:8e:e8:50:64:13:
      5d:c9:c7:17:0f:fc:5d:16:4f:90:27:bc:9f:d7:13:e6:5f:d3:
      c5:48:1b:ca:c0:b2:d0:e4:ea:e4:23:aa:84:36:50:b6:2a:24:
      7e:c9:4d:58:9c:e8:2b:98:72:de:e5:3a:7b:67:e7:8b:85:fc:
      9e:8d:74:e4:36:79:ee:c8:56:37:ad:9c:1f:0f:aa:7a:88:26:
      d0:8c:67:ea:27:19:fa:e7:dc:42:f9:12:e0:24:ef:bf:27:60:
      54:0e:b3:37:68:c5:54:c4:45:9d:30:63:3b:d0:14:05:a4:4f:
      da:e2:20:8f:8a:94:97:6d:4e:c3:07:c4:03:0d:28:96:d2:69:
      39:a5:18:6d:12:dc:5f:2d:b0:fd:a0:17:81:71:f3:94:8b:46:
      db:6d:68:20:94:e0:14:99:92:01:3f:ab:1d:98:8c:b2:a5:fa:
      a1:21:4e:be:28:a2:68:62:eb:fe:37:49:ad:d9:c9:c5:b0:22:
      05:88:fb:3f:6e:b5:c0:57:3c:39:15:61:42:ec:52:a7:18:81:
      84:29:2f:46:19:52:f3:42:0c:ce:19:de:55:fb:a5:b5:79:0f:
      41:f1:c7:2f
 

 以下は証明書の内容です。赤文字部分が署名です。

Certificate:
   Data:
      Version: 3 (0x2)
      Serial Number: 2 (0x2)
   Signature Algorithm: sha256WithRSAEncryption
      Issuer: C=JP, ST=Tokyo, L=Default City, O=test inc, CN=test.co.jp
      Validity
         Not Before: Feb 6 15:03:05 2019 GMT
         Not After : Feb 3 15:03:05 2029 GMT
      Subject: C=JP, ST=Tokyo, O=test inc, OU=IT test, CN=test.com
      Subject Public Key Info:
          Public Key Algorithm: rsaEncryption
             Public-Key: (2048 bit)
             Modulus:
                 00:d3:cf:af:cf:32:7f:3c:29:c4:cf:45:be:c8:1e:
                 16:e4:66:98:6c:02:9f:75:c9:07:d4:01:95:61:af:
                 6c:c9:d1:2d:ea:94:b4:5e:e3:0c:6a:3c:a9:27:25:
                 5d:7e:90:e6:dd:69:3c:fe:d3:21:55:b4:b9:bd:34:
                 3f:25:9f:d5:b9:5c:b6:d9:6e:94:90:a2:9e:46:01:
                 64:86:59:0d:9c:90:ab:02:e9:b1:cb:26:58:4b:19:
                 db:ef:6c:52:5d:a6:f4:dc:2d:b9:39:7e:97:53:f6:
                 97:71:b6:26:b8:9f:d4:f9:94:13:ab:6d:ac:42:2e:
                 9c:03:d5:94:70:0a:ae:2d:a4:44:56:75:80:ea:c3:
                 5a:df:42:d6:b9:2e:a5:45:e2:cf:3f:2b:c8:f3:2d:
                 e3:ed:9c:58:fe:74:dc:a5:0b:7a:b3:40:8b:8b:65:
                 f9:39:3f:6f:6b:b3:4b:41:d0:a7:ce:89:8c:56:52:
                 f0:b9:67:0d:39:b3:76:65:ba:f4:9a:35:e3:6d:23:
                 dd:78:52:22:17:f6:86:00:b6:58:a8:da:1c:b4:84:
                 f6:02:b8:de:ac:01:11:8a:f1:86:23:7b:50:1a:95:
                 da:15:53:ce:98:4c:fd:41:0d:dd:e4:e8:79:ed:30:
                 11:7f:bd:0b:1b:b9:c5:83:70:56:8a:9a:01:df:73:
                 89:59
            Exponent: 65537 (0x10001)
      X509v3 extensions:
         X509v3 Subject Alternative Name:
            DNS:test.com, DNS:*.test.com
   Signature Algorithm: sha256WithRSAEncryption
      30:e9:69:10:01:46:c9:be:0a:97:2d:1d:6c:48:28:29:f9:55:
      54:75:80:ce:60:b2:bc:63:b1:97:ff:08:91:7a:e5:f7:98:97:
      13:01:db:14:61:f2:58:c4:0c:c4:63:ec:94:26:49:9b:07:c7:
      36:1e:df:99:ab:cd:df:91:e7:10:a0:c9:fa:e0:57:3d:c9:c4:
      50:e7:4d:36:4c:22:9c:e4:88:a8:03:ee:fb:ae:3a:cb:f1:55:
      96:62:12:37:3e:90:33:75:22:bb:c4:85:9d:b8:c4:4c:c2:6b:
      f2:4d:33:13:9a:4b:86:f6:d6:ab:49:4a:c8:d4:fc:19:f4:23:
      a1:ec:e9:85:3f:3d:20:23:4d:8f:55:23:24:ad:b4:4d:8d:44:
      66:8e:e6:46:b7:ca:94:55:e0:99:a5:6e:59:30:17:e9:4c:f4:
      74:4d:9f:b7:8b:83:0b:91:72:b3:13:6b:58:bb:1a:eb:a4:c8:
      69:4d:93:d1:04:2a:12:dc:2e:86:fb:4e:f0:38:fe:00:aa:6a:
      e6:cb:a7:61:57:a5:28:4e:f1:f0:53:c9:ce:96:58:35:f1:b1:
      75:2c:3d:e9:a7:b9:1f:ba:1a:42:16:cb:10:a5:3a:6a:06:24:
      44:f0:4e:db:c4:39:90:db:8d:61:cb:2c:9b:0b:40:17:ac:2f:
      78:02:e2:62
-----BEGIN CERTIFICATE-----
MIIDTzCCAjegAwIBAgIBAjANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJKUDEO
MAwGA1UECAwFVG9reW8xFTATBgNVBAcMDERlZmF1bHQgQ2l0eTERMA8GA1UECgwI
dGVzdCBpbmMxEzARBgNVBAMMCnRlc3QuY28uanAwHhcNMTkwMjA2MTUwMzA1WhcN
MjkwMjAzMTUwMzA1WjBVMQswCQYDVQQGEwJKUDEOMAwGA1UECAwFVG9reW8xETAP
BgNVBAoMCHRlc3QgaW5jMRAwDgYDVQQLDAdJVCB0ZXN0MREwDwYDVQQDDAh0ZXN0
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANPPr88yfzwpxM9F
vsgeFuRmmGwCn3XJB9QBlWGvbMnRLeqUtF7jDGo8qSclXX6Q5t1pPP7TIVW0ub00
PyWf1blcttlulJCinkYBZIZZDZyQqwLpscsmWEsZ2+9sUl2m9NwtuTl+l1P2l3G2
Jrif1PmUE6ttrEIunAPVlHAKri2kRFZ1gOrDWt9C1rkupUXizz8ryPMt4+2cWP50
3KULerNAi4tl+Tk/b2uzS0HQp86JjFZS8LlnDTmzdmW69Jo1420j3XhSIhf2hgC2
WKjaHLSE9gK43qwBEYrxhiN7UBqV2hVTzphM/UEN3eToee0wEX+9Cxu5xYNwVoqa
Ad9ziVkCAwEAAaMjMCEwHwYDVR0RBBgwFoIIdGVzdC5jb22CCioudGVzdC5jb20w
DQYJKoZIhvcNAQELBQADggEBADDpaRABRsm+CpctHWxIKCn5VVR1gM5gsrxjsZf/
CJF65feYlxMB2xRh8ljEDMRj7JQmSZsHxzYe35mrzd+R5xCgyfrgVz3JxFDnTTZM
IpzkiKgD7vuuOsvxVZZiEjc+kDN1IrvEhZ24xEzCa/JNMxOaS4b21qtJSsjU/Bn0
I6Hs6YU/PSAjTY9VIySttE2NRGaO5ka3ypRV4JmlblkwF+lM9HRNn7eLgwuRcrMT
a1i7GuukyGlNk9EEKhLcLob7TvA4/gCqaubLp2FXpShO8fBTyc6WWDXxsXUsPemn
uR+6GkIWyxClOmoGJETwTtvEOZDbjWHLLJsLQBesL3gC4mI=
-----END CERTIFICATE-----

CSRを受け取った認証局はオクテット文字列を生成して、自身の秘密鍵で暗号化して証明書に付与します。(赤文字の部分です。)

この署名がどのように検証されるかを説明します。

①クライアントは証明書をもらって署名部分を既に所有している公開鍵(ルート証明書内に保有)で復号化します。

②署名部分のハッシュ値を計算します。

③2つの値を比較して同じだったら正当な証明書であるとクライアントは判断します。

CSRにも署名があります。本内容はCSRを受け取った認証局秘密鍵がちゃんとあるCSRであるかを確認しています。この内容はDERエンコードされたcertificationRequestInfoコンポーネントの値(オクテット文字列)をCSRと対になる秘密鍵で暗号化した値です。認証局ハッシュ値と公開鍵で復号化した内容を比較し、同一であった場合正しいと判断されます。証明書作成時には破棄されます。

2.3.証明書の情報

以下は本ブログをブラウザで開いたときにGoogle Chrome上のURL部分となります。鍵マークをクリックすると証明書によって暗号化されていることがわかります。

f:id:light-spoqz:20190207201829j:plain

「証明書(有効)」をクリックすると詳細を確認が可能です。以下の画面を見ると「COMODO RSA DOmain Validation Secure Server CA」という中間認証局がhatenablog.comに対して証明書を発行していることがわかります。

f:id:light-spoqz:20190207202213j:plain

「証明のパス」タブをクリックすると中間認証局の他に「COMODO SECURE™」というルート証明書も確認できます。

f:id:light-spoqz:20190207202419j:plain

「詳細」タブをクリックすると詳細な情報を確認することが可能です。証明書を発行したあとに確認することは以下が主になります。

①有効期間の終了

短すぎると運用に支障をきたします。認証局が発行する際に指定する期限となるため、自己認証局で発行する際に注意する点となります。

f:id:light-spoqz:20190207204230j:plain

サブジェクト

CSRを作成する際に記載した内容が記載されてます。自身の申請内容があっていることを確認します。

f:id:light-spoqz:20190207204226j:plain

サブジェクト代替名

SAN(Subject Alternative Name)とは証明書の拡張領域を指します。SSLサーバ証明書内の「SAN」領域にFQDNを設定できるようになり、1枚の証明書で複数のウェブサイトの暗号化通信を実現することが可能になります。

この領域は元々重要ではなかったのですが、Google Chrome はバージョン58からSSLの検証を行う際にCN(Common Name)ではなくSANを使用することになった頃から、この領域がほぼ必須となりました。

f:id:light-spoqz:20190207204233j:plain

 

 

3.自己認証局とは

自己認証局とは外部の証明機関を使用しないで、自組織内に認証局を作成して証明書を発行した場合を指します。この場合、イントラネット内でのクライアントがイントラネット内サーバに対してHTTPS通信やFTPSなどの通信を行う場合に行います。

メリットとしては証明書を購入するためのコストが浮くことです。デメリットとしてはクライアント端末側にルート証明書のインポートが必要となってしまうことかと思います。

f:id:light-spoqz:20190203155054j:plain

①対象のサーバでCSRの発行を行います。

②発行したCSRを中間認証局に送信します。

③中間認証局で本内容から証明書を生成します。

④中間認証局は生成した証明書を依頼組織に対して返送します。

 

 基本的なフローは同一です。ただし、ルート認証局が存在しないという点が大きいです。

4.ルート認証局と自己認証局の違い

しなぜ組織は自己証明書にて認証をわないのでしょうか。コストもあまりかからないで発行できる証明書がベストでは無いのでしょうか。

その説明のためにはルート証明書を理解する必要があります。クライアント端末(WindowsMac)にはルート証明書というものがインストールされています。

クライアントはルート証明書を元にアクセス先のサーバ証明書を検証し、自身の持っているルート証明書と比較することで信頼できると判断してます。

その場合、自己認証局が署名したサーバ証明書は正しいとクライアントは判断するのでしょうか。その場合、信頼できないサイトとして表示されます。

もし、全世界のクライアントにエラーなくページを表示させたい場合はルート証明書を全世界に配布する必要があります。逆に言えば世界中のクライアントが信頼している認証局がルート認証局となります。インターネット公開向けの証明書はきちんと外部の認証局に発行を依頼しましょう。

ルート証明書Windows OSだとWindows Updateなどで適宜配信されます。

インストールされているルート証明書は以下の手順で確認できます。(IEによる例となります。)

IEのツールをクリックします。

f:id:light-spoqz:20190203155938j:plain

 

②インタネットオプションをクリックします。

f:id:light-spoqz:20190203160131j:plain

 

③コンテンツをクリックし、証明書をクリックします。

f:id:light-spoqz:20190203160144j:plain

 

④信頼されたルート証明機関をクリックすると信頼されたルート認証局が表示されます。

f:id:light-spoqz:20190203160152j:plain

 

 

5.まとめ

  • 認証局は上位の認証機関から信頼できる認証機関から認証を受けることにより、信頼できるものとされる。
  • 証明書には外部の認証局から発行された証明書と自身を認証局として発行した自己証明書の二種類がある。
  • 自己認証局により証明書を発行した場合はクライアントにルート証明書を発行することが必要である。

 6.おまけ

6.1.世界のルート認証局のシェア

SSLèªè¨¼å±ã·ã§ã¢æ¨ç§» 2015å¹´4æ1æ¥ã2018å¹´3æ22æ¥ - è³æ: Q-Successæä¾

SSL/TLSについて① SSL/TLS通信の概要 - インフラエンジニア勉強雑記

SSL/TLSについて② SSLの通信フロー - インフラエンジニア勉強雑記

SSL/TLSについて③ 証明書とは - インフラエンジニア勉強雑記

SSL/TLSについて④ 証明書の発行方法、ルート証明書のインポート方法 - インフラエンジニア勉強雑記

SSL/TLSについて⑤ SSLの終端機器 - インフラエンジニア勉強雑記

SSL/TLSについて⑥ SSLハンドシェイク - インフラエンジニア勉強雑記

SSL/TLSについて② SSLの通信フロー

1.用語の説明

今後は以下の用語を使用します。

  • 公開鍵暗号方式:公開鍵と秘密鍵の2種類の鍵を使用して暗号化通信を行います。公開鍵で送信者が暗号化して受信者に通信を行います。受信者は秘密鍵を使用して受け取った暗号化情報を復号化します。公開鍵は誰でも取得が可能ですが、秘密鍵は受信者のみが持っている情報となります。公開鍵で暗号化された場合、秘密鍵でしか複合化できません。

f:id:light-spoqz:20190202223138j:plain

  • 共通鍵暗号方式:共有鍵と呼ばれる鍵を使用して送信者と受信者が暗号化通信を行います。共通鍵は暗号化と復号化のために使用されます。共通鍵が漏洩すると誰でも本内容の盗聴・改竄が可能であるので扱いに注意が必要です。

f:id:light-spoqz:20190202223133j:plain

  • 証明書:通信相手が本当に正しい通信相手かを確認するためのものです。認証局が発行します。

2.SSL/TLSのフロー

 SSL/TLSがどのように通信を暗号化して、クライアントがどのように通信を復号化しているかを説明します。

流れを説明すると以下です。

  1. 公開鍵暗号化方式によって共通鍵の交換・証明書の検証を行う。
  2. 共通鍵暗号化で暗号化通信を行う。

f:id:light-spoqz:20190203004058j:plain

共通鍵の交換のみを公開鍵暗号方式で行って、実際の通信は共通鍵暗号化方式で通信を行います。

フローの中でサーバ証明書の検証という言葉がありました。サーバ証明書は作成される過程で上位の認証機関に証明をしてもらう必要があります。このサーバ証明書は信頼された証明機関によって署名されている、ということをクライアントが検証します。この工程によって、不審なサイトにアクセスした際に警告を出すことが可能となります。

3.SSL通信に必要なもの

公開されているサーバでSSL通信を有効化するためには以下のファイルが必要となります。

サーバ側:サーバ証明書秘密鍵

クライアント側:ルート証明書

サーバ側のサーバ証明書秘密鍵は発行する際に同時に生成されるので問題ないかと思います。

クライアント側のルート証明書は必ずしも必要ではありませんが、証明書のエラー画面がブラウザで表示されるので注意が必要です。自己証明書を使用していない場合は自動的にブラウザにインストールされています。

証明書に関しては後ほど詳細を説明します。

4.まとめ

SSL/TLSについて① SSL/TLS通信の概要 - インフラエンジニア勉強雑記

SSL/TLSについて② SSLの通信フロー - インフラエンジニア勉強雑記

SSL/TLSについて③ 証明書とは - インフラエンジニア勉強雑記

SSL/TLSについて④ 証明書の発行方法、ルート証明書のインポート方法 - インフラエンジニア勉強雑記

SSL/TLSについて⑤ SSLの終端機器 - インフラエンジニア勉強雑記

SSL/TLSについて⑥ SSLハンドシェイク - インフラエンジニア勉強雑記

 

SSL/TLSについて① SSL/TLS通信の概要

1.SSL/TLSの概要

SSL/TLSとはエンドポイント間の通信を秘匿するための暗号化技術​を指します。

SSL脆弱性が発見されて現在はTLSが主流となっておりますが、一般的にSSL/TLSSSLと表現することが多いため、本ブログでもそのように記載いたします。

HTTPSのイメージが強いですが、それ以外のプロトコルも使用することが可能です。

例としては以下のプロトコルSSLを使用しています。元のプロトコルからポート番号も変更されています。

SSLと組み合わせたプロトコル ポート番号 元のプロトコル ポート番号
HTTPS 443 HTTP 80
SMTPS 465 SMTP 25
LDAPS 636 LDAP 389
FTPS (data) 989 FTP (data) 20
FTPS (control) 990 FTP (control) 21
IMAPS 993 IMAP 143
POP3S 995 POP3 110

2.SSLを使用しないと何が危険か。

通信の秘匿性が失われ盗聴や改竄が行われる可能性が生じます。

  • 盗聴:​第三者がエンドポイント間の情報を収集すること。ユーザIDやパスワードが第三者に盗聴される危険性があります。
  • 改竄:通信の内容を変更すること。意図しないページに誘導される可能性があります。

近年ですとユーザIDやパスワードを求めるページがほとんどであるため、HTTPSなどを使用することが多いように思えます。

f:id:light-spoqz:20190202214823j:plain

一方SSLを使用すると以下のように盗聴や改竄に対して対策を講じることが可能です。

  • 盗聴:盗聴を行われても通信内容が暗号化されているため、通信内容を把握することが不可能。
  • 改竄:暗号化されても改竄は可能だが、SSLではハッシュ関数で改竄されていないことを確認しているため、改竄を検知可能。

f:id:light-spoqz:20190202214825j:plain

 

3.まとめ

  • 平文通信は盗聴や改竄の危険性があります。
  • SSLを有効化したほうがセキュリティ上安全です。

SSL/TLSについて① SSL/TLS通信の概要- インフラエンジニア勉強雑記

SSL/TLSについて② SSLの通信フロー - インフラエンジニア勉強雑記

SSL/TLSについて③ 証明書とは - インフラエンジニア勉強雑記

SSL/TLSについて④ 証明書の発行方法、ルート証明書のインポート方法 - インフラエンジニア勉強雑記

SSL/TLSについて⑤ SSLの終端機器 - インフラエンジニア勉強雑記

SSL/TLSについて⑥ SSLハンドシェイク - インフラエンジニア勉強雑記

*1:Wikipediaから引用