Rの技術メモ

1.1.1.1のSSL

1.1.1.1_web

2018/4/1からCDNのCloudflareがIPアドレス1.1.1.1をDNSサーバとして運用を開始した。 1.1.1.1ではWebサーバも公開されており、アクセスしてみた際にドメインではなくで https://1.1.1.1 というIPアドレスでSSL接続していたことに疑問を覚えたので仕組みを調べてみた。

url

証明書の中身を確認

CN, SANで1.1.1.1という値が指定されているはずと考えられるので、まずはブラウザから証明書の中身を確認してみる。

san.png

SANのところでIP Address=1.1.1.1という項目があり、他にも1.0.0.1やIPv6形式のアドレスもあることがわかる。 確かに証明書の中にはIPアドレスで指定されているようだ。そこで、実際に証明書の仕様を確認してみる。

RFC仕様

[RFC5280][rfc5280]のSANの構造を見てみると以下のようになっている。

  SubjectAltName ::= GeneralNames


  GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName


  GeneralName ::= CHOICE {
    otherName                       [0]     OtherName,
    rfc822Name                      [1]     IA5String,
    dNSName                         [2]     IA5String,
    x400Address                     [3]     ORAddress,
    directoryName                   [4]     Name,
    ediPartyName                    [5]     EDIPartyName,
    uniformResourceIdentifier       [6]     IA5String,
    iPAddress                       [7]     OCTET STRING,
    registeredID                    [8]     OBJECT IDENTIFIER
  }

SANには[7]でIPアドレスも指定できることがわかる。他にもいろいろなものが指定できることも確認できる。仕様がわかったので、次はパケットの中身をみてみる。

パケットキャプチャをしてみる

WiresharkでSSLハンドシェイク時のパケットをキャプチャし、サーバからのレスポンスCertificateのSAN部分のバイナリデータとWireshark上で見える内容を確認してみる。

captured_san.png

バイナリ部分の87 04が何を意味しているはわからないが、IPアドレスがオクテット形式でデーター多として見える。

まとめ

SSL証明書のサブジェクトにIPアドレスが使えることが分かった。今回はRFCを読み、実際にパケットをキャプチャしてみることで仕組みを理解することができた。インターネット上の仕様はいろいろなサイトで解説されているが、全てがRFCを元としているので、わからないことがあったら今後はRFCまで調査するように心がけていきたい。

参考

[rfc5280][https://tools.ietf.org/html/rfc5280#section-4.2.1.6]