service identity

service identity (PKI)

[82] TLS を使う多くのプロトコルでは、サーバー証明書に示されたドメイン名利用者が指定したドメイン名が一致しているかの検査 (service identity の検査) を行うことが求められています。

[83] この検査は、利用者が指定した通りのサーバーに接続していることを確かめるためのものです。 この検査を通過しない場合には、 (サーバーの設定に誤りがあるのでなければ) MITM 攻撃により偽のサーバーに接続している可能性があります。

仕様書

[3] RFC 6125TLSPKIX を用いる場合で、アプリケーションプロトコルにおいてサービスの識別にドメイン名を使う場合に、 その service identity の検査をどう行うべきかを規定するものです。従来 TLS を用いるアプリケーションプロトコルはそれぞれ検査の方法を規定していましたが、 ほぼ同じで細部が異なるものでした。 RFC 6125 はそれを踏まえて新たに標準的な方法を規定するものです。 ただし従来の各プロトコルの規定を廃止するものではなく、新プロトコルや既存プロトコルの改訂版で明示的に参照される場合にのみ適用する >>1 とされています。

[73] RFC 6125 の附属書A、B はそれまでに出版された IETF の仕様書の service identity の検査に関する条項をまとめています。

ドメイン名

[24] 証明書にはドメイン名は色々な形で記述され得ます。そのうち RFC 6125 に従う仕様で service identity を表すものとして解釈されるのは、

... の4つの識別子型の識別子です。 (それ以外も用いることも排除はされていません。)

[25] これらの形式の値の一部または全部が DNSドメイン名とみなされます。 IDNAラベルを使った ASCII のみの形に変換されてから証明書に記述されます。

IP アドレス

[74] 証明書ではIPアドレスSANiPAddress に記述されます。

[75] HTTPS などいくつかの仕様は IPアドレスの場合に iPAddress を検査するべきことを規定しています。それ以外の仕様は (意図的かどうかは不明ですが) 明記していません。 RFC 6125ドメイン名のみが適用対象であるとして IPアドレスには言及していません。

[80] 古い仕様は CNDNSドメイン名のみならず IPアドレスを使えるとするものもあるようです。

証明書

[12] CA完全修飾DNSドメイン名に基づく証明書を発行する時は、 次の規則が適用されます >>11

[22] CN-ID が複数あるべきではない >>11, >>69 とされていますが、 定義上複数あるものは CN-ID ではありません。実際には SNI に対応していない環境に向けても virtual host を実現するために複数の CN-ID証明書に含めることがある >>69 ようです。

[70] ですから、 CN-ID の定義が誤っていると解釈するべきでしょう。

CSR

[27] CSR を作成するサービス提供者に対しては次のような指針が示されています >>26

アプリケーションプロトコル

[5] アプリケーションプロトコルの設計では、次の点を考慮するべきです >>4

[10] しかし既存のアプリケーションは SRV-IDURI-ID に対応していないものが多い >>4 です。

[131] IETF 的には、個々のアプリケーションプロトコルがそれぞれにおける service identity の検証方法を定めるべきである、ということになっています。 共通 RFC 出版以前に策定されたプロトコルも、明示的に仕様書が改定されない限りは、 従前の規定が有効とされています。

[132] しかし、 SRV-IDURI-ID やその他アプリケーション依存の識別子型に関するものはともかく、 最も広く用いられているホストに関する検証で、 アプリケーションごとに証明書に記述するべき内容が異なるとすると、 証明書の利用者はアプリケーションごとに異なる証明書を入手し設定する必要がありますし、 証明書を利用する TLS の実装はプロトコル共通の検証の実装を持つことができず、 アプリケーション非依存の通信当事者認証の仕組みであるはずの PKIX の旨味も半減です。

[133] 実際問題、ホスト認証に関するプロトコルや仕様書間で規定が異なる部分は厳密に仕様書通りに実装されているとは限らず、 実装ごとに解釈が異なる危険な領域であると認識するべきでしょう。

検証

[34] アプリケーションプロトコルクライアントは、 service identity を次のようにして検証 (verify) します >>33

  1. [35] 利用者の入力等に基づき、受け入れる参照識別子のリストを作成します。
  2. [36] サーバー証明書からサーバーの識別子を得ます。
  3. [37] 参照識別子サーバーの識別子が一致するか検査します。

[55] 証明書に示された識別子を順に調べ、 参照識別子のリストとの一致を検査します。一致するものが見つかれば、 そこで探すのをやめるべきです>>33

[56] 証明書DNS-IDSRV-IDURI-ID、応用依存の (クライアントが対応する) 識別子型識別子が含まれているなら、 CN-ID参照識別子との一致を調べてはなりません。 含まれていないなら、フォールバックとして CN-ID の一致を検査して構いません。 >>33

[81] 古い仕様は DNS-ID があっても CN-ID を検査することを認めていたものもあるようです。
[71] RFC 6125ドメイン名を対象にしているので応用サービス型 (URL scheme) とドメイン名にしか言及がありませんが、 URI-IDpathquery が含まれる場合や、 URI-ID 相当のものがドメイン名を含まない場合についてもアプリケーションプロトコルはどう比較するか規定しなければならないものと思われます。

参照識別子のリストの作成

[38] クライアントは、参照識別子のリストを作成しなければなりません >>33

[52] まず利用者の入力や設定、ハイパーリンクなどによって指定された接続先情報から、 ドメイン名の情報と応用サービス型を得ます >>33

[39] 例えば入力 URL sips:alice@example.net から、 応用サービス型 「sip」とドメイン名 「example.net」を得ます >>33

[53] これは入力に直接含まれる情報を取り出すだけかもしれませんし、 何らかの解決サービスに問い合わせた結果かもしれません。 ただし攻撃者が介在し得ない安全な方法で得たもの (利用者が明示的に指定したもの、 DNSSEC により得たものなど) でなければなりません >>33。 入力に直接由来するドメイン名 (source domain) を使うべきで、 それを DNS 解決するなどして得られたドメイン名 (derived domain) を使うべきではありません >>33

[40] これは、利用者の入力とサーバー側が示した識別子が一致することをもってのみ、 当該証明書によって安全が保たれると言えるからです。 ただし例外として、人間利用者が証明書を他のドメイン名に「pin」 した場合には、 source domain と他のドメイン名の両方を含むことになります。 >>33

[54] 次に、ドメイン名応用サービス型から、参照識別子のリストを得ます。

[51] この参照識別子のリストの作成は、サーバー側が示す識別子とは独立に、 クライアント側のみで行わなければなりません >>33

[45] どの識別子型の識別子を含めるかは local policy の問題です。 例えば特定のサービスにのみ接続するよう構築されたクライアントでは、 その応用サービス型SRV-ID のみ含めることにできます。 より一般的なクライアントでは SRV-IDDNS-ID の両方を含めます。 当面の間は CN-ID にも対応する必要がある可能性が高いです。 >>33

[76] CN-ID が複数ある場合は定義上 CN-ID とは言わないはずですが、 実際には複数含まれた証明書も存在しています (>>22)。 RFC 6125 の定義通りに処理するなら、複数ある場合には資源識別子のリストには含めないことになります。 HTTPS などいくつかの仕様は、どれを選ぶべきかを規定しています (HTTPSRDN 参照)。

[48] Webブラウザーは、 www.example.comHTTPS において

... を含めることができます >>33

[49] MUA は、 IMAPS example.netmail.example.net に解決される時、

... を含めることができます >>33

[46] これらの識別子は証明書に示された識別子と比較するために用意するだけで、 実際に ASN.1 のような証明書で使われる表現で構築する必要はありません。 >>33

ドメイン名の比較

[57] クライアントは、参照識別子DNSドメイン名部分が一致するか検査しなければなりません参照識別子DNSドメイン名伝統的ドメイン名なら、 ASCII大文字・小文字不区別で各ラベルを順に比較しなければなりません参照識別子DNSドメイン名IDN なら、 UラベルAラベルに変換した上で、 ASCII大文字・小文字不区別で各ラベルを順に比較しなければなりません>>33

[99] ChromeFirefox も、証明書ドメイン名大文字でも、 一致すると判定します。

[100] ChromeFirefox も、証明書ドメイン名非ASCII文字を含む時、 一致しないとみなします。

[101] ただし Chrome は、証明書ドメイン名非ASCII文字を含んでも、 それを正規化すると URLAラベルとなるなら、 一致するとみなすようです。

[103] Chrome でも Firefox でも、証明書ドメイン名PSL に含まれるものであっても、かわらず普通に扱います。

[104] Chrome でも Firefox でも、証明書ドメイン名内部名であっても、 かわらず普通に扱います。

[58] ワイルドカード文字の扱いについては、ワイルドカード証明書の項を参照。

[95] 末尾の点も参照。

応用サービス型の比較

[59] SRV-IDURI-ID については応用サービス型一致も検査しなければなりません >>33

[60] SRV-ID の応用サービス名部分は、 DNS SRV の仕様にそって大文字・小文字不区別で比較しなければなりません >>33

[61] URI-IDURL scheme 部分は、 URL の仕様にそって大文字・小文字不区別で比較しなければなりません >>33

一致判定

[62] 証明書に示された識別子で資源識別子一致するものが見つかれば、 service identity の検査は成功です。クライアントはその資源識別子を当該応用サービス検証済み (validated) identity として使わなければなりません >>33

[63] 証明書に示された識別子で資源識別子一致するものが見つからなかった場合で、 以前に当該応用サービス証明書をいずれかの資源識別子pin している場合で、証明書pin された証明書と一致する場合には、 service identity の検査は成功です >>33

[64] 証明書に示された識別子で資源識別子一致するものが見つからなかった場合で、 pin された証明書もない場合、対話的なクライアントは利用者identity が一致しなかったと通知し、通信は問題ある証明書であるとの誤りにより自動的に終端するべきです >>33

[65] 対話的なクライアントの中には、その場合であっても処理を続行する、 つまり証明書pin する選択肢を利用者に示すものもあります。 特殊な状況ではそのような動作も必要かもしれませんが、高度な利用者のみに提示するべきものです。 しかも極めて注意して取り扱うべきものですから、 pin する前に certification path 全体の確認を強制するなど注意が必要です。 >>33

[66] クライアントが人間利用者が直接制御しない自動化された応用である場合には、 問題ある証明書であるとの誤りにより自動的に終端し、誤りを適宜記録するべきです。 これを抑制する設定を設けても構いませんが、既定値としてはなりません>>33

[68] pin は、示された証明書とその承認された文脈の両方を考慮しなければなりません。 ここでいう文脈とは、当該証明書から trust anchor までの証明書鎖source domain応用サービス型、サービスの derived domainポート番号、その他利用者クライアントが持つ関係する情報を含みます。 >>33

HTTPS サーバー認証

[154] クライアントは、ホスト名が分かっているなら、 Certificate メッセージに示されたidentity を検査しなければなりません。 通常は URL で指定されたホスト要求を送信するので、 ホスト名は既知です。 >>151

[156]dNSNamesubjectAltName 拡張が示されている場合には、 これを identity として使わなければなりません。そうでない場合には、 証明書Subject 欄の (最も詳細な) Common Name 欄を identity として使わなければなりません>>151

[157] Common Name を使うのが慣習となっていますが、非推奨であり、 dNSName が推奨されています >>151

[97] ChromeFirefox も、 SAN があるとき、 CN を無視します。 (仕様通りの動作。)

[122] 「最も詳細な」の部分について、 RFC 6125 は混乱があることを指摘し、 CN が複数含まれない場合のみ CN-ID とみなすことにしています (RDNCN-ID 参照)。ただし RFC 6125RFC 2818 を更新するものではなく、 また HTTPS の実装が実際にどう処理するかは定かではありません。

[98] Chrome は、 CN が複数ある時、最後のものを採用するようです。 Firefox は、最初のものを採用するようです。

[158] 一致の判定は、 RFC 2459 の規則によります。 複数の identity が示されている場合には、いずれかに一致すれば一致とします。 >>151, >>168 ワイルドカード文字も使えます。

[161] ホスト名ではなく IPアドレスを指定して接続する場合には、 証明書subjectAltName 拡張の iPAddress と完全に一致しなければなりません。 >>151

[125] 実際の Webブラウザーは、 SAN がないとき、 CNIPアドレスと完全に一致するなら、 一致とみなします >>124ChromeFirefoxCNIPv4アドレスを指定すると、 そのように動作します。

[110] Chrome でも Firefox でも、これは正規形の IPv4アドレスの文字列表現でなければ認識されません。

[105] Chrome >>102Firefox >>118 のソースコードによると、 この扱いは IPv4アドレスのみで、 IPv6アドレスには適用されないようです。

[108] SAN がないというのは、 DNS-IDIPアドレスの指定がどちらもないことをいいます。 他の、例えばメールアドレスの指定があっても、 FirefoxChrome も、 CN-ID を使います。

[96] ChromeFirefox も、 CNSANIPv4アドレスを指定しても、 IPアドレスURL でアクセスした時一致とみなしませんでした。

[93] ChromeFirefox も、IPアドレスの記述のない証明書のとき、 IPアドレスURL でのアクセスでエラーとします。

[129] ChromeFirefox も、2017年には CN への対応を原則として廃止しました。


[172] クライアントは信頼する CA を注意深く選び、 信頼する CA証明書を保存する場所が不正に改変されないよう注意するべきです >>171

[170] これらの identity の検査のことを、 HTTPSサーバー認証 (HTTPS server authentication) >>171 などと呼ぶことがあります。

[155] クライアントが外部情報によりの期待される identity を承知しているなら、ホスト名の検査を省略できます。 例えば番地ホスト名が動的に決まる機械に接続する場合で、 が示す証明書が分かっているなら、省略できます。 特別な場合にはidentity を完全に無視しても構いませんが、 危険なことは理解しなければなりません。 >>151

[162] ホスト名証明書identity一致しない場合には、 利用者指向のクライアント利用者にこれを通知するか、 証明書誤りにより接続を終端するかのいずれかとしなければなりません。 通知する場合には、利用者接続を継続するか選択させても構いません。 自動化されたクライアントは (あれば) 誤りを記録しなければならず証明書誤りにより接続を終端するべきです。 自動化されたクライアントは設定によりこの検査を無効化しても構いませんが、 有効にする設定を設けなければなりません>>151

[163] なお、 URL など接続先のホスト名が外部の信頼できない情報源からもたらされた場合、 identity を検査したとしても攻撃を回避できるわけではありません。 利用者証明書を注意して調べるなどの対策が必要です。 >>151 一般的な Webブラウザー証明書の一部の情報をアドレスバーなどに表示すると共に、 詳細な情報を表示する方法を提供しています。

[106] 対話的Webブラウザーは、原則としてこれらの規定に従うものの、 利用者の判断により名前が一致しない証明書であっても個別に閲覧を認められるのが一般的です。 Webアプリケーションの開発用など一般向けでない場合を中心に、 そのような利用方法が可能なことに依存している場合もあります。 非対話的利用者エージェントも、証明書の検証を省略する動作モードを用意していることが普通です。

[107] ルート証明書の更新などのクライアント側で必要な作業がそのような利用者エージェント (の動作環境) では蔑ろにされがちであり、 そのような環境でも HTTPS に意図通り接続させるため、敢えて検証を省略する状態でシェルスクリプト等が記述されていることも少なくありません。 (もちろん、これは好ましい状況ではありません。ただ証明書にまつわるトラブルは珍しくなく、 原因の究明と対策は一般の開発者にとって難しいため、 このような回避策を取らざるをえない場合があることも残念ながら事実です。)

実装

[77] 複数のプロトコルでの利用を想定した実装では、プロトコル名などを指定してワイルドカードの動作を切り替えられることがあります。

[84] 552346 – Stop honoring DNS names found in subject common names in CERT_VerifyCertName ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=552346>

[85] 高木浩光@自宅の日記 - こんな銀行は嫌だ, オレオレ証明書の区分 第三版 (高木浩光 著, 版) <http://takagi-hiromitsu.jp/diary/20071117.html>

[86] Netscape Certificate Extensions Specification ( 版) <http://web.archive.org/web/19970727173508/http://home.netscape.com/eng/security/cert-exts.html>

netscape-ssl-server-name:[Not supported until 3.0b5]

The value is an IA5String. It is a "shell expression" that can be used to match the hostname of the SSL server that is using this certificate. It is recommended that if the server's hostname does not match this pattern the user be notified and given the option to terminate the SSL connection. If this extension is not present then the CommonName in the certificate subject's distinguished name is used for the same purpose.

[87] 1184059 – (presumably) mozilla::pkix disallows several hyphens in domain label ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=1184059>

[88] 660749 – (CVE-2011-0082) Firefox doesn't (re)validate certificates when loading a HTTPS page from the cache ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=660749>

[89] Phishing for Confirmations --- Certificate spoofing with subjectAltName and domain name wildcards ( 版) <http://nils.toedtmann.net/pub/subjectAltName.txt>

[90] RFC 7592 - OAuth 2.0 Dynamic Client Registration Management Protocol ( 版) <https://tools.ietf.org/html/rfc7592>

When using TLS, the client MUST perform a TLS/SSL

server certificate check, per RFC 6125 [RFC6125].

[91] RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol ( 版) <https://tools.ietf.org/html/rfc7591>

When using TLS, the client MUST perform a

TLS/SSL server certificate check, per RFC 6125 [RFC6125].

[92] RFC 7817 - Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols ( 版) <https://tools.ietf.org/html/rfc7817>

[94] OpenSSL ( (OpenSSL Foundation, Inc.著, )) <https://www.openssl.org/docs/manmaster/crypto/X509_check_host.html>

[102] [chrome] Contents of /trunk/src/net/cert/x509_certificate.cc ( ()) <https://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate.cc#l504>

[109] 469533 – FireFox 3.0.6 only processes 'Last' CN in x509 certificate when multiple CNs are present - ssl_error_bad_cert_domain ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=469533>

[111] 1063281 – Implement RFC6125-compliant name matching in mozilla::pkix ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=1063281>

[112] 1089104 – ssl_error_bad_cert_domain when subjectAltName extension is missing and Subject CN is encoded as TeletexString ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=1089104>

[113] Issue 308330 - chromium - Remove support for common names in certificates; only support Subject Alt Names - Monorail ( ()) <https://bugs.chromium.org/p/chromium/issues/detail?id=308330>

[114] 1245280 – don't fall back to subject common name for name information for new certificates ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=1245280>

[115] gecko-dev/BRNameMatchingPolicy.cpp at master · mozilla/gecko-dev ( ()) <https://github.com/mozilla/gecko-dev/blob/master/security/certverifier/BRNameMatchingPolicy.cpp>

[116] gecko-dev/BRNameMatchingPolicy.h at master · mozilla/gecko-dev ( ()) <https://github.com/mozilla/gecko-dev/blob/master/security/certverifier/BRNameMatchingPolicy.h>

[117] gecko-dev/CertVerifier.cpp at master · mozilla/gecko-dev ( ()) <https://github.com/mozilla/gecko-dev/blob/master/security/certverifier/CertVerifier.cpp>

BRNameMatchingPolicy nameMatchingPolicy(

isBuiltInRoot ? mNameMatchingMode

: BRNameMatchingPolicy::Mode::DoNotEnforce);

[118] gecko-dev/pkixnames.cpp at master · mozilla/gecko-dev ( ()) <https://github.com/mozilla/gecko-dev/blob/master/security/pkix/lib/pkixnames.cpp>

[119] 不正なSSL証明書のチェックをしないモバイルアプリにご注意を | スラド セキュリティ ( ()) <http://security.srad.jp/story/14/02/14/0943234/>

テキサス大学オースティン校およびスタンフォード大学の研究者らによる研究(PDF)によると、Amazon EC2のJavaライブラリやAmazonおよびPayPalのSDK、ECサイト構築ソフトウェア、モバイル向けの広告コードなどで、証明書が正しく検証されていない例が確認されたという。また、iOS向けのネットバンキングアプリの40%で、証明書の検証に不備があるとも述べられている(Netcraft)。

[120] 1250696 – .onion names contain their own validator, we should use that () <https://bugzilla.mozilla.org/show_bug.cgi?id=1250696>

[121] 「国税クレジットカードお支払サイト」は誰が運営するサイトなのか - Togetterまとめ () <https://togetter.com/li/1067266>

[123] RFC 8143 - Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) () <https://tools.ietf.org/html/rfc8143>

[130] Define hosts' public suffix and registrable domain. by mikewest · Pull Request #391 · whatwg/url () <https://github.com/whatwg/url/pull/391>