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

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

SSL/TLSについて⑥ SSLハンドシェイク

 1.SSLハンドシェイクとは

1.1.概要

SSL/TLS通信を開始するためにはTCPの3ウェイハンドシェイクのあとにSSLハンドシェイクが行われます。どのようなSSL/TLSのどのバージョンを使用するか、Cipher Suitesの選択、証明書の交換・検証、共通鍵の生成なども行われます。

HTTPS接続でサーバーとクライアントの間で転送されるデータは暗号化されます。共通鍵暗号化方式の方が公開鍵暗号化方式よりも計算コストが少ないので、データの暗号化通信では共通鍵暗号化方式が使用されています。共通鍵暗号化方式を使用するには、両端に共通鍵が必要です。公開鍵暗号化方式で鍵を交換し、共通鍵暗号化方式で通信を暗号化します。

1.2.Cipher Suiteとは

SSL通信で使用する暗号化技術の組み合わせをまとめたものをCipher Suiteといいます。以下はLinux上でコマンドを実行した結果です。

# openssl ciphers -v

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
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
DH-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH/DSS Au=DH Enc=AESGCM(256) Mac=AEAD
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD
DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256
DH-RSA-AES256-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA256
DH-DSS-AES256-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DH-RSA-AES256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA1
DH-DSS-AES256-SHA SSLv3 Kx=DH/DSS Au=DH Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
DH-RSA-CAMELLIA256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(256) Mac=SHA1
DH-DSS-CAMELLIA256-SHA SSLv3 Kx=DH/DSS Au=DH Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
DH-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AESGCM(128) Mac=AEAD
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD
DH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256
DH-RSA-AES128-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA256
DH-DSS-AES128-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
DH-RSA-AES128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA1
DH-DSS-AES128-SHA SSLv3 Kx=DH/DSS Au=DH Enc=AES(128) Mac=SHA1
DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1
DH-RSA-SEED-SHA SSLv3 Kx=DH/RSA Au=DH Enc=SEED(128) Mac=SHA1
DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS Au=DH Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1
DH-RSA-CAMELLIA128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(128) Mac=SHA1
DH-DSS-CAMELLIA128-SHA SSLv3 Kx=DH/DSS Au=DH Enc=Camellia(128) Mac=SHA1
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1
ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
DH-RSA-DES-CBC3-SHA SSLv3 Kx=DH/RSA Au=DH Enc=3DES(168) Mac=SHA1
DH-DSS-DES-CBC3-SHA SSLv3 Kx=DH/DSS Au=DH Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1
PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1
KRB5-IDEA-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=SHA1
KRB5-DES-CBC3-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=SHA1
KRB5-IDEA-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=MD5
KRB5-DES-CBC3-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=MD5
ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1
ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1
KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1
KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5

  一列目の内容を使用して内容を説明します。

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
  • ECDHE-RSA-AES256-GCM-SHA384:Cipher Suiteの名称
  • TLSv1.2:SSL/TLSのバージョン
  • Kx=ECDH:公開鍵暗号化方式
  • Au=RSA:鍵認証時の暗号化方式
  • Enc=AESGCM(256):共通鍵暗号化方式
  • Mac=AEAD:メッセージ認証符号

2.SSLハンドシェイクの詳細

TCP 3ウェイハンドシェイクは完了しているものとします。

2.1.Client Hello

クライアントがサーバに対してSSLコネクションの開始を要求します。

Client HelloにはSSL/TLSのバージョンやCipher Suitesのリストが記載されています。

受信したサーバは、Cipher Suiteのリストを確認して暗号化方式を確定します。もしCipher Suiteのリスト内にサーバが認識できない、サポートしていない暗号化方式があった場合などは無視します。サーバが使用できる暗号化方式がClient HelloのCipher Suiteのリスト内にない場合は失敗のアラートを上げて、コネクションがクローズします。

以下はWireSherkでキャプチャしたClient Helloの内容です。

Frame 1165: 251 bytes on wire (2008 bits), 251 bytes captured (2008 bits) on interface 0
Ethernet II, Src: AsustekC_XX:XX:XX (08:62:66:XX:XX:XX), Dst: Vmware_XX:XX:XX (00:0c:29:XX:XX:XX)
Internet Protocol Version 4, Src: 192.168.XX.XX, Dst: 192.168.XX.XX
Transmission Control Protocol, Src Port: 51136, Dst Port: 443, Seq: 1, Ack: 1, Len: 197
Secure Sockets Layer
   TLSv1.2 Record Layer: Handshake Protocol: Client Hello
      Content Type: Handshake (22)
      Version: TLS 1.0 (0x0301) 
      Length: 192
      Handshake Protocol: Client Hello
         Handshake Type: Client Hello (1)
         Length: 188
         Version: TLS 1.2 (0x0303) #クライアントが対応しているSSL/TLSバージョン
         Random: a0c2c39f89971d0f62c98ca3244e031b6b0025d3c5ff71ce...
            GMT Unix Time: Jun 21, 2055 00:37:03.000000000 東京 (標準時)
            Random Bytes: 89971d0f62c98ca3244e031b6b0025d3c5ff71ce63c33e16...
         Session ID Length: 0
         Cipher Suites Length: 40
         Cipher Suites (20 suites) #クライアントが対応しているCipher Suite
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
            Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
            Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
            Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
            Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
            Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
            Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
            Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
            Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
         Compression Methods Length: 1
            Compression Methods (1 method)
         Compression Method: null (0)
         Extensions Length: 107
         Extension: ec_point_formats (len=4)
            Type: ec_point_formats (11)
            Length: 4
            EC point formats Length: 3
            Elliptic curves point formats (3)
               EC point format: uncompressed (0)
               EC point format: ansiX962_compressed_prime (1)
               EC point format: ansiX962_compressed_char2 (2)
         Extension: supported_groups (len=8)
            Type: supported_groups (10)
            Length: 8
            Supported Groups List Length: 6
            Supported Groups (3 groups)
               Supported Group: x25519 (0x001d)
               Supported Group: secp256r1 (0x0017)
               Supported Group: secp384r1 (0x0018)
      Extension: SessionTicket TLS (len=0)
         Type: SessionTicket TLS (35)
         Length: 0
         Data (0 bytes)
      Extension: status_request (len=5)
         Type: status_request (5)
         Length: 5
         Certificate Status Type: OCSP (1)
         Responder ID list Length: 0
         Request Extensions Length: 0
      Extension: application_layer_protocol_negotiation (len=14)
         Type: application_layer_protocol_negotiation (16)
         Length: 14
         ALPN Extension Length: 12
         ALPN Protocol
            ALPN string length: 2
            ALPN Next Protocol: h2
            ALPN string length: 8
            ALPN Next Protocol: http/1.1
      Extension: extended_master_secret (len=0)
         Type: extended_master_secret (23)
         Length: 0
      Extension: signature_algorithms (len=48)
         Type: signature_algorithms (13)
         Length: 48
         Signature Hash Algorithms Length: 46
         Signature Hash Algorithms (23 algorithms)
            Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
            Signature Hash Algorithm Hash: SHA256 (4)
            Signature Hash Algorithm Signature: ECDSA (3)
            Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
            ........(省略)
            Signature Hash Algorithm Hash: SHA512 (6)
            Signature Hash Algorithm Signature: DSA (2)

  

2.2.Server Hello,Server Certificate,Server Key Exchange,Certificate Request,Server Hello Done

サーバはClient HelloのCipher Suitesが問題ない場合、Server Helloを返します。以下の情報が含まれています。

  • Server Hello
  • Server Certificate
  • Server Key Exchange(省略可)
  • Certificate Request(省略可)
  • Server Hello Done

Server HelloではClient Helloで送付されたSSL/TLSのバージョンから1つのバージョンとCipher Suiteから1つの暗号化方式を選択して送付します。

Server Certificateでサーバはサーバ証明書をクライアントに送信します。

Server Key Exchangeでは一時的なRSA鍵を生成してサーバの署名を付けて送信します。サーバが証明書を保有していない場合、Server Certificateで公開鍵が含まれていない場合の代替として使用します。

Certificate Requestではクライアント証明書をクライアントに要求する場合に使用されます。

Server Hello Doneではサーバ側から送信する情報が送信されたことをクライアントに通知します。

Frame 1167: 1325 bytes on wire (10600 bits), 1325 bytes captured (10600 bits) on interface 0
Ethernet II, Src: Vmware_XX:XX:XX (00:0c:29:XX:XX:XX), Dst: AsustekC_XX:XX:XX (08:62:66:XX:XX:XX)
Internet Protocol Version 4, Src: XX:XX:XX.XX, Dst: XX:XX:XX.XX
Transmission Control Protocol, Src Port: 443, Dst Port: 51136, Seq: 1, Ack: 198, Len: 1271
Secure Sockets Layer
   TLSv1.2 Record Layer: Handshake Protocol: Server Hello
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303) #TLSのバージョン
      Length: 61
      Handshake Protocol: Server Hello
         Handshake Type: Server Hello (2)
         Length: 57
         Version: TLS 1.2 (0x0303)
         Random: 8d9cf0959b23ec35daf4070cfc8e4e09ded3bcfafa54e041...
            GMT Unix Time: Apr 15, 2045 21:37:41.000000000 東京 (標準時)
            Random Bytes: 9b23ec35daf4070cfc8e4e09ded3bcfafa54e0418f0d7a73...
         Session ID Length: 0
         Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) #使用するCipher Suite
         Compression Method: null (0)
         Extensions Length: 17
         Extension: renegotiation_info (len=1)
            Type: renegotiation_info (65281)
            Length: 1
            Renegotiation Info extension
               Renegotiation info extension length: 0
         Extension: ec_point_formats (len=4)
            Type: ec_point_formats (11)
            Length: 4
            EC point formats Length: 3
            Elliptic curves point formats (3)
               EC point format: uncompressed (0)
               EC point format: ansiX962_compressed_prime (1)
               EC point format: ansiX962_compressed_char2 (2)
         Extension: SessionTicket TLS (len=0)
            Type: SessionTicket TLS (35)
            Length: 0
            Data (0 bytes)
   TLSv1.2 Record Layer: Handshake Protocol: Certificate #サーバ証明書の送信、読み飛ばして良い
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 853
      Handshake Protocol: Certificate
         Handshake Type: Certificate (11)
         Length: 849
         Certificates Length: 846
         Certificates (846 bytes)
            Certificate Length: 843
            Certificate: 308203473082022fa003020102020103300d06092a864886... (id-at-commonName=www.test.co.jp,id-at-organizationName=test inc,id-at-stateOrProvinceName=Tokyo,id-at-countryName=JP)
               signedCertificate
                  version: v3 (2)
                  serialNumber: 3
                  signature (sha256WithRSAEncryption)
                     Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)
                  issuer: rdnSequence (0)
                     rdnSequence: 5 items (id-at-commonName=test.co.jp,id-at-organizationName=test inc,id-at-localityName=Default City,id-at-stateOrProvinceName=Tokyo,id-at-countryName=JP)
                        RDNSequence item: 1 item (id-at-countryName=JP)
                           RelativeDistinguishedName item (id-at-countryName=JP)
                              Id: 2.5.4.6 (id-at-countryName)
                              CountryName: JP
                        RDNSequence item: 1 item (id-at-stateOrProvinceName=Tokyo)
                           RelativeDistinguishedName item (id-at-stateOrProvinceName=Tokyo)
                              Id: 2.5.4.8 (id-at-stateOrProvinceName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: Tokyo
                        RDNSequence item: 1 item (id-at-localityName=Default City)
                           RelativeDistinguishedName item (id-at-localityName=Default City)
                              Id: 2.5.4.7 (id-at-localityName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: Default City
                        RDNSequence item: 1 item (id-at-organizationName=test inc)
                           RelativeDistinguishedName item (id-at-organizationName=test inc)
                              Id: 2.5.4.10 (id-at-organizationName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: test inc
                        RDNSequence item: 1 item (id-at-commonName=test.co.jp)
                           RelativeDistinguishedName item (id-at-commonName=test.co.jp)
                              Id: 2.5.4.3 (id-at-commonName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: test.co.jp
                  validity
                     notBefore: utcTime (0)
                        utcTime: 19-02-17 12:02:11 (UTC)
                     notAfter: utcTime (0)
                        utcTime: 29-02-14 12:02:11 (UTC)
                  subject: rdnSequence (0)
                     rdnSequence: 4 items (id-at-commonName=www.test.co.jp,id-at-organizationName=test inc,id-at-stateOrProvinceName=Tokyo,id-at-countryName=JP)
                        RDNSequence item: 1 item (id-at-countryName=JP)
                           RelativeDistinguishedName item (id-at-countryName=JP)
                              Id: 2.5.4.6 (id-at-countryName)
                              CountryName: JP
                        RDNSequence item: 1 item (id-at-stateOrProvinceName=Tokyo)
                           RelativeDistinguishedName item (id-at-stateOrProvinceName=Tokyo)
                              Id: 2.5.4.8 (id-at-stateOrProvinceName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: Tokyo
                        RDNSequence item: 1 item (id-at-organizationName=test inc)
                           RelativeDistinguishedName item (id-at-organizationName=test inc)
                              Id: 2.5.4.10 (id-at-organizationName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: test inc
                        RDNSequence item: 1 item (id-at-commonName=www.test.co.jp)
                           RelativeDistinguishedName item (id-at-commonName=www.test.co.jp)
                              Id: 2.5.4.3 (id-at-commonName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: www.test.co.jp
                  subjectPublicKeyInfo
                     algorithm (rsaEncryption)
                        Algorithm Id: 1.2.840.113549.1.1.1 (rsaEncryption)
                     subjectPublicKey: 3082010a0282010100be8f84e278ef1cbcdf719cb16957b1...
                        modulus: 0x00be8f84e278ef1cbcdf719cb16957b185185cd7a005c138...
                        publicExponent: 65537
                  extensions: 1 item
                     Extension (id-ce-subjectAltName)
                        Extension Id: 2.5.29.17 (id-ce-subjectAltName)
                        GeneralNames: 2 items
                           GeneralName: dNSName (2)
                              dNSName: test.co.jp
                           GeneralName: dNSName (2)
                              dNSName: *.test.co.jp
               algorithmIdentifier (sha256WithRSAEncryption)
                  Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)
               Padding: 0
               encrypted: 3a736d642a393d78dbd219a05326b3bdf77e80a2c835be28...
   TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange #ECDHEを使用しているため、サーバ側の共通鍵の送信
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 333
      Handshake Protocol: Server Key Exchange
         Handshake Type: Server Key Exchange (12)
         Length: 329
         EC Diffie-Hellman Server Params
            Curve Type: named_curve (0x03)
            Named Curve: secp256r1 (0x0017)
            Pubkey Length: 65
            Pubkey: 0458b7a49226cb09596a651985d5c7e613da3a218557a795...
            Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
               Signature Hash Algorithm Hash: SHA256 (4)
               Signature Hash Algorithm Signature: RSA (1)
            Signature Length: 256
            Signature: 9fae3a95e3e856223aaa3b31a58e5e05e93a3cafe5f70eef...
   TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done #Server Helloの完了
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 4
      Handshake Protocol: Server Hello Done
         Handshake Type: Server Hello Done (14)
         Length: 0

 

2.3.ClientKeyExchange,ClientCertificate,CertificateVerify,ChangeCipherSpec,Finished

証明書を受信したクライアントは、証明書の正当性をルート証明書を使用して検証します。検証が問題なく完了すると、公開鍵を取り出します。

以下の情報が含まれています。

  • ClientKeyExchange 
  • ClientCertificate(省略可)
  • CertificateVerify(省略可)
  • ChangeCipherSpec 

ClientKeyExchange ではRSAの場合クライアントはPre-Master Secretを生成し、DHEやECDHEの場合は共通値を生成し送信します。DHEやECDHEの場合はサーバ側で生成した共通値とクライアント側で生成した共通値を元にPre-Master Secretをクライアント側、サーバ側のそれぞれで生成します。

ClientCertificateではCertificate Requestをクライアントから受信した場合に証明書を送信します。

CertificateVerifyではクライアント証明書を送信した場合に、秘密鍵があることを証明するための署名を送信します。

ChangeCipherSpec では無暗号化通信が終了したことを送信します。 

Frame 1169: 180 bytes on wire (1440 bits), 180 bytes captured (1440 bits) on interface 0
Ethernet II, Src: AsustekC_XX:XX:XX (08:62:66:XX:XX:XX), Dst: Vmware_XX:XX:XX (00:0c:29:XX:XX:XX)
Internet Protocol Version 4, Src: XX.XX.XX.XX, Dst: XX.XX.XX.XX
Transmission Control Protocol, Src Port: 51136, Dst Port: 443, Seq: 198, Ack: 1272, Len: 126
Secure Sockets Layer
   TLSv1.2 Record Layer: Handshake Protocol: Client Key Exchange #ClientKeyExchange 
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 70
      Handshake Protocol: Client Key Exchange
         Handshake Type: Client Key Exchange (16)
         Length: 66
         EC Diffie-Hellman Client Params
            Pubkey Length: 65
            Pubkey: 04fd64e92a34b6c46357f68b9f7ed7c8b07cdbb81e2dc91a...
   TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec #ChangeCipherSpec 
      Content Type: Change Cipher Spec (20)
      Version: TLS 1.2 (0x0303)
      Length: 1
      Change Cipher Spec Message
   TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 40
      Handshake Protocol: Encrypted Handshake Message

 2.4. ChangeCipherSpec

以下の情報が含まれています。

  • ChangeCipherSpec 

ChangeCipherSpec では無暗号化通信が終了したことを送信します。 

Frame 1170: 312 bytes on wire (2496 bits), 312 bytes captured (2496 bits) on interface 0
Ethernet II, Src: Vmware_XX:XX:XX (00:0c:29:XX:XX:XX), Dst: AsustekC_XX:XX:XX (08:62:66:XX:XX:XX)
Internet Protocol Version 4, Src: XX.XX.XX.XX, Dst: XX.XX.XX.XX
Transmission Control Protocol, Src Port: 443, Dst Port: 51136, Seq: 1272, Ack: 324, Len: 258
Secure Sockets Layer
   TLSv1.2 Record Layer: Handshake Protocol: New Session Ticket
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 202
      Handshake Protocol: New Session Ticket
         Handshake Type: New Session Ticket (4)
         Length: 198
         TLS Session Ticket
            Session Ticket Lifetime Hint: 300 seconds (5 minutes)
            Session Ticket Length: 192
            Session Ticket: 9279ba948314a9ff957a530421bd544ef1d157b4f254d1d1...
   TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec #ChangeCipherSpec 
      Content Type: Change Cipher Spec (20)
      Version: TLS 1.2 (0x0303)
      Length: 1
      Change Cipher Spec Message
   TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 40
      Handshake Protocol: Encrypted Handshake Message

 

 2.5.暗号化通信開始

この後は生成された共通鍵を使用して暗号化通信を行います。

 

 

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

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

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

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

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

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

SSL/TLSについて④ 証明書の発行方法、ルート証明書のインポート方法

 

1.CSRの発行方法(Linux OpenSSL)

①サーバ用の秘密鍵生成

# openssl genrsa -out /etc/pki/tls/private/server.key 2048

 

Generating RSA private key, 2048 bit long modulus
...................................................+++
................+++
e is 65537 (0x10001)

  

②SAN用の情報作成

# vi /etc/pki/tls/openssl.cnf

 

[alt_names]
DNS.1 = test.com
DNS.2 = *.test.com

  

③サーバ用のCSR生成(サーバ側、認証局どちらでも可)

# openssl req -new -key /etc/pki/tls/private/server.key -out /etc/pki/tls/certs/server.csr

 

 Enter pass phrase for /etc/pki/tls/private/privkey.pem: #①で入力したパスワードを入力

You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----

Country Name (2 letter code) [JP]: #国名、日本だとJP

State or Province Name (full name) [Tokyo]: #都道府県

Locality Name (eg, city) [Default City]: #市区町村

Organization Name (eg, company) [test inc]: #会社名

IT test (eg, section) : #部署名

Common Name (eg, your name or your server's hostname) : #アクセス先サーバのFQDN

  

④証明書の内容確認(テスト用に作成したCSRです)

 # openssl req -text -noout -in /etc/pki/tls/certs/server.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

 

 

CSRを中間認証局に送付、もしくは自己認証局にアップロードして完了となります。

 

2.自己認証局の設定・証明書の発行方法(Linux OpenSSL)

本手順はLinuxサーバを認証局とし、証明書を発行する方法です。本手順ではRHEL7.1を使用しております。SANに関する内容は後述いたします。

①OpenSSLのインストール

# yum -y install openssl

 

認証局として使用するための設定変更

# vi /etc/pki/tls/openssl.cnf

##### [ CA_default ]ハッシュ方式の変更(デフォルト?) #####
default_md = sha256

##### [ req ]ハッシュ方式の変更 #####

default_md = sha256

req_extensions = v3_req

##### [ req_distinguished_name ]CSRで入力する内容を事前に決めておきたい方向け #####

countryName_default = JP #日本
stateOrProvinceName_default = Tokyo #都道府県
localityName_default = Shinjuku #市区町村
0.organizationName_default = test inc. #組織名

organizationalUnitName_default = IT test #部署名

##### [ v3_req ]SAN対応 #####

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectAltName = @alt_names

  

認証局用の秘密鍵生成

# openssl genrsa -aes256 -out /etc/pki/CA/private/cakey.pem 2048

Generating RSA private key, 2048 bit long modulus
..................................+++
.....................+++
e is 65537 (0x10001)
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Verifying - Enter pass phrase for /etc/pki/CA/private/cakey.pem:

  

認証局用のCSR生成

# openssl req -new -key /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.csr

Enter pass phrase for /etc/pki/CA/private/cakey.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [JP]:
State or Province Name (full name) [Tokyo]:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [test inc]:
IT test (eg, section) :
Common Name (eg, your name or your server's hostname)
:
Email Address :

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password :
An optional company name []:

  

認証局用の証明書生成(本証明書がルート証明書となる)

# openssl x509 -days 3650 -in /etc/pki/CA/cacert.csr -req -signkey /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem

Signature ok
subject=/C=JP/ST=Tokyo/L=Default City/O=test inc
Getting Private key
Enter pass phrase for /etc/pki/CA/private/cakey.pem:

  

⑥証明書失効のための準備

# touch /etc/pki/CA/index.txt
# echo 00 > /etc/pki/CA/serial

 

⑦SAN用の情報作成

※証明書を複数発行する場合はopenssl.cnfに書くよりも外部に出したほうが管理が楽となると感じております。

# vi /etc/pki/tls/san1.ext

subjectAltName=DNS:test.com,DNS:*.test.com

  

⑧サーバ用の証明書発行(認証局にて実施)

# openssl ca -in /etc/pki/tls/certs/server.csr -out /etc/pki/tls/certs/server.crt -days 3650 -extfile /etc/pki/tls/san1.ext

 

Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 2 (0x2)
Validity
Not Before: Feb 6 15:03:05 2019 GMT
Not After : Feb 3 15:03:05 2029 GMT
Subject:
countryName = JP
stateOrProvinceName = Tokyo
organizationName = test inc
organizationalUnitName = IT test
commonName = test.com
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:test.com, DNS:*.test.com
Certificate is to be certified until Feb 3 15:03:05 2029 GMT (3650 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

  

⑨作成した証明書をSSL有効化対象のサーバにアップロード

3.証明書の発行方法(Windows ADCA)

今後作成いたします。

4.クライアントにおけるルート証明書のインポート方法(Windows端末)

クライアント端末へのルート証明書のインポート方法です。IEなどのブラウザからも可能ですが、コンピュータアカウントへの追加ができないため、本手順のほうが良いと考えております。

①Winキーを押してmmcと入力し、Enterキーを押します。

②「ファイル」→「スナップインの追加と削除」をクリックします。

③利用できるスナップインから証明書を選択し、「追加」をクリックします。

④一つのユーザに追加する場合は「ユーザアカウント」、コンピュータ全体に導入する場合は「コンピューターアカウント」にチェックを入れて「次へ」をクリックします。

802.1Xを有効にする場合はコンピュータアカウントとすることが必須となります。

⑤「完了」をクリックします。

⑥「OK」をクリックします。

⑦「信頼されたルート証明機関」→「証明書」を右クリックし、「すべてのタスク」→「インポート」をクリックします。

⑧「次へ」をクリックします。

⑨ファイル名を参照して、「次へ」をクリックします。

5.おまけ

5.1.DigiCert SSLTools

Check Website Security | DigiCert SSLTools

SSL/TLSのセキュリティ設定が問題ないか確認するためのサイトです。もちろんですが、イントラネット内のサイトでは使用できません。

 

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

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

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

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

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

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

802.1Xについて① 概要

 

1.IEEE 802.1X認証とは

1.1.概要

NWに接続する端末を認証するための技術です。認証方法の中では設定が面倒な部類に入りますが、セキュリティを強固にすることが可能です。この名称は長いため、ドットイチエックスとかイチエックスと略されて呼ばれることが多いです。

本技術を使用する際にはクライアント、スイッチ、認証サーバの3つが絡むため、障害発生時に原因の切り分けが非常に大変ですが、その分セキュリティも強固なので、導入している企業は多いです。

また、構築だけでなく運用にも気を配る必要があります。802.1X認証に対応していないクライアントに対してはMAB(MAC Authentication Bypass)を有効にしたり、配下にスイッチングハブなどが入っていると正常に認証されない場合などがあります。

本技術の方式の中にはSSL証明書を使用するものもあるため、SSL証明書の検証方法をよく理解しておいたほうが良いです。(SSL証明書を受信したクライアントはどのように証明書が正当なものか検証を行っていたか。)

1.2.通信フロー

この認証を行うためには以下の機器から構成されます。

  • サプリカント(Supplicant):認証クライアント。Windows端末やMac端末などのデバイスやクライアントにインストールされたソフトウェアが対象となる。
  • オーセンティケータ(Authenticator):802.1Xに対応したスイッチや無線LAN
  • 認証サーバ:認証を行うためのサーバ。Radiusが利用されることが多い。

以下は認証のフローです。使用するEAPの種類によってフローが変動するため、注意が必要です。

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

上記で色々な通信を記載してますが、今回では以下を理解してください。

  1. サプリカントがオーセンティケータ(スイッチもしくは無線AP)に接続したタイミングで認証が開始する。
  2. サプリカントとオーセンティケータ間の通信はオーセンティケータがプロキシして認証サーバと通信する。

詳細の通信フローは後日パケットキャプチャを付与して説明します。

2.EAPとは

認証プロコトルの一つです。EAPの中には以下のような認証方法があります。

  • EAP-MD5:ユーザー名とパスワードによる認証だが、平文を流さないためにMD5ハッシュを用いる。クライアント側のみ認証される。
  • EAP-TLS (Transport Layer Security):サーバ、クライアント双方に電子証明書を準備し、これによって認証を行う。両者にルート証明書保有している必要がある。
  • EAP-TTLS (Tunneled TLS):EAP-TLSの拡張版。米ファンク・ソフトウェア社 (Funk Software) が開発したEAP製品。まずはサーバ側にのみ電子証明書を準備してサーバ認証済みのTLS通信路を構築し、その暗号化通信路を通してパスワードによるクライアント認証を行う。
  • EAP-PEAP (Protected EAP):米マイクロソフト社が開発したEAP規格でIDとパスワードで認証する方式。SSL (Secure Sockets Layer) と同じ暗号化技術によって認証通信全体が暗号化されている。サーバ側にのみ電子証明書を準備してサーバの認証を行った後に、TLSによる暗号化通信路を用いてさらにEAP通信を行い、クライアントを認証する。この際クライアントの認証はパスワードやキートークンなど、電子証明書以外の認証手段を利用する事が一般的である。
  • LEAP(Lightweight EAP) :米シスコシステムズ社が開発したEAP製品。

個人的にはEAP-TLSを使用することが多いです。ただし、クライアント端末にクライアント証明書のインポートが必要になるため、PCの更改と合わせて実施することが推奨です。既存のPC環境を変更したくなく、AD環境であればPEAPがいいです。

 

3.まとめ

  • NWのセキュリティを強固にしたいのであればIEEE 802.1Xを導入するべき。
  • クライアント、NW機器、認証サーバの3種類が絡むため、切り分けが困難。
  • 導入や運用に手間がかかるため、コストと相談する必要あり。

BIG-IP ASMについて① ASM概要

 

1.BIG-IP ASM概要

1.1.ASMの概要

BIG-IPは様々なモジュールをインストールすることで、様々な機能を実装することが可能です。その中でもASM(Application Security Firewall)はWAF(Web Applicaiton Firewall)のモジュールとなります。

名称からわかるようにWebを脅威から守るための装置です。近年増加しているWebサイトのセキュリティ脅威増加の対策の一つとして使用します。

例として以下の脅威から守ることが可能です。

1.2.ASMのモード

これらの内容はWAFを導入している企業全般に言えることですが、運用が非常に大変です。セキュリティの脆弱性を突いた攻撃は日々増加しており、それらに対応するためにASMではシグネチャをF5社から取得し、適用が可能です。(平均6週間に一度、現在2000程度のシグネチャが用意)

これらのシグネチャをすべて割り当てればいいわけではありません。適用した結果、誤検知により正常なWeb通信を止めてしまう可能性があるからです。

一般的にWAFを導入する際は暫定的なポリシーを適用し、トランスペアレントモードで1ヶ月ほど運用することが多いです。このモードでは通信に対してセキュリティポリシーで検査を行いますが、通信を遮断することはありません。ログに出力のみ行わせておき、「正常な通信ではこのシグネチャが通信を止めてしまうな」といった判断を人の手を介して行います。1ヶ月後に正常な通信が行えるようにセキュリティポリシーをチューニングして、ブロッキングモードに変更することで通信の遮断を行います。

2.セキュリティポリシーの種類

ASMはセキュリティポリシーを使用してシステムを保護します。保護ルールを定義したものをセキュリティポリシーといい、ポリシーをバーチャルサーバに対して割り当てることで、複数のWebサーバに対して異なるポリシーを割り当てることが可能です。

セキュリティポリシータイプ 用途
Automatic security policy システムがトラフィックを調査し、トラフィックの統計分析とアプリケーションの動作に基づいてポリシーを作成します。ポリシーを手動で変更することもできます。
Manual security policy 「rapid deployment」または「 an application-ready security policy (pre-configured template) 」を使用しポリシーを作成すると、手動でポリシーのチューニングが可能です。初期設定だと基本的なポリシーのみ作成し、チューニングを行います。
Security policy integrated with vulnerability assessment tool WhiteHat Sentinel、IBM®AppScan®、Trustwave®App Scanner(Cenzic)、Qualys®、QuotiumSeeker®、HP WebInspectなどの脆弱性評価ツールからの出力を統合してセキュリティポリシーを作成します。インポートされた脆弱性レポートの結果に基づいて、Application Security Manager™はWebサイトの脆弱性を自動的に軽減するポリシーを作成します。ポリシーを確認して微調整することもできます。
Parent security policy 複数のセキュリティポリシーの基礎となるセキュリティポリシーを作成します。類似のアプリケーションが複数ある場合に便利です。親ポリシーの設定は、子ポリシーに継承されます。親ポリシーを調整することによって、子ポリシーも変更されます。
Child security policy セキュリティポリシーに基づくセキュリティポリシーを作成します。子ポリシーを作成すると、設定の値は親から継承されます。一部の設定は編集でき、その他の設定は親ポリシーでのみ変更できます。
Template security policy テンプレートを使用して、新しいポリシーを設定します。テンプレートはポリシーの作成時にのみ使用されます。親ポリシーとは異なり、テンプレートは作成後のポリシーには影響しません。

3.セキュリティポリシーの作成準備

セキュリティポリシーを作成する前に、保護対象のアプリケーションと、それを保護することの理由を理解しておく必要があります。

以下の点をセキュリティポリシー作成前に確認しておく必要があります。

  • どのくらい厳密なポリシーを作成するか。
  • 保護したいアプリケーションはいくつあるか。複数のアプリケーションを保護する場合、それらは差異があるのか。(一つのポリシーを使い回せるか、それぞれのアプリケーションで別々のポリシーを定義する必要があるか。)
  • 親ポリシーから制御したい機能はあるか。ポリシーは、親ポリシーから設定を継承が可能である。
  • どのくらいのトラフィックを想定しているか、アプリケーションがどのプロトコルを使用するか。HTTPSを使用する場合、セキュリティの検査を行うためにはSSLの終端が必要になるため、BIG-IPの型番からきちんと検討が必要になる。
  • アプリケーションには、たくさんのパラメータとURLが関連付けられているか。

厳密なセキュリティポリシーは、アプリケーションの変更に影響されるため、維持するために時間と稼働がかかることが多いです。一方で基本的なポリシーでは、複数のアプリケーションに適用した場合でも、メンテナンスは少なく済みます。

4.まとめ

  • BIG-IP ASMはWebアプリケーションの脆弱性を突いた攻撃を防ぐための機器。
  • 導入直後はトランスペアレントモード、運用開始後はブロッキングモードが一般的。

おまけ

GartnerにおけるWAF市場調査の結果です。(2018年分)

以下のURLからダウンロードが可能です。ただし、登録が必要となります。

Gartner Magic Quadrant for Web Application Firewalls | Resource Center | Imperva

図だけですと以下ページから確認可能です。(Impervaのページですが)

Imperva Recognized as a 2018 Gartner Magic Quadrant WAF Leader, Five Years Running | Imperva

 

上記内容の概略は以下です。

  • 強み:様々なクラウドに対応しており、iRuleなどの機構により既存のユーザは本WAFを使用している。また、コミュニティが充実している。
  • 弱み:コストが他の製品と比較して高い。Silverline®(F5によるSOC)が南アメリカ、中東、アフリカ、中国に存在していない。

コストはBIG-IPを提案する場合に必ず通る道です。機能ではあまりWAFは差異が出ないです。

 

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ハンドシェイク - インフラエンジニア勉強雑記