[82] TLS を使う多くのプロトコルでは、サーバー証明書に示されたドメイン名と利用者が指定したドメイン名が一致しているかの検査 (service identity の検査) を行うことが求められています。
[83] この検査は、利用者が指定した通りのサーバーに接続していることを確かめるためのものです。 この検査を通過しない場合には、 (サーバーの設定に誤りがあるのでなければ) MITM 攻撃により偽のサーバーに接続している可能性があります。
[3] RFC 6125 は TLS と PKIX を用いる場合で、アプリケーションプロトコルにおいてサービスの識別にドメイン名を使う場合に、 その service identity の検査をどう行うべきかを規定するものです。従来 TLS を用いるアプリケーションプロトコルはそれぞれ検査の方法を規定していましたが、 ほぼ同じで細部が異なるものでした。 RFC 6125 はそれを踏まえて新たに標準的な方法を規定するものです。 ただし従来の各プロトコルの規定を廃止するものではなく、新プロトコルや既存プロトコルの改訂版で明示的に参照される場合にのみ適用する >>1 とされています。
[73] RFC 6125 の附属書A、B はそれまでに出版された IETF の仕様書の service identity の検査に関する条項をまとめています。
[24] 証明書にはドメイン名は色々な形で記述され得ます。そのうち
RFC 6125 に従う仕様で service identity を表すものとして解釈されるのは、
[25] これらの形式の値の一部または全部が DNSドメイン名とみなされます。 IDN は Aラベルを使った ASCII のみの形に変換されてから証明書に記述されます。
[74] 証明書ではIPアドレスは SAN の iPAddress
に記述されます。
[75] HTTPS などいくつかの仕様は IPアドレスの場合に iPAddress
を検査するべきことを規定しています。それ以外の仕様は (意図的かどうかは不明ですが)
明記していません。 RFC 6125 もドメイン名のみが適用対象であるとして
IPアドレスには言及していません。
[12] CA が完全修飾DNSドメイン名に基づく証明書を発行する時は、
次の規則が適用されます >>11。XmppAddr など応用依存の識別子も含んで構いません。
[22] CN-ID が複数あるべきではない >>11, >>69 とされていますが、 定義上複数あるものは CN-ID ではありません。実際には SNI に対応していない環境に向けても virtual host を実現するために複数の CN-ID を証明書に含めることがある >>69 ようです。
[27] CSR を作成するサービス提供者に対しては次のような指針が示されています >>26。
[5] アプリケーションプロトコルの設計では、次の点を考慮するべきです >>4。SRV レコードを使ってドメイン名の解決を行うなら、
証明書で SRV-ID 識別子型への対応を要求または推奨することを検討するべきです >>4。CN
欄のDNSドメイン名を使う必要があるなら CN-ID
識別子型にフォールバックとして対応することを推奨することを検討するべきです >>4。
[131] IETF 的には、個々のアプリケーションプロトコルがそれぞれにおける service identity の検証方法を定めるべきである、ということになっています。 共通 RFC 出版以前に策定されたプロトコルも、明示的に仕様書が改定されない限りは、 従前の規定が有効とされています。
[132] しかし、 SRV-ID や URI-ID やその他アプリケーション依存の識別子型に関するものはともかく、 最も広く用いられているホストに関する検証で、 アプリケーションごとに証明書に記述するべき内容が異なるとすると、 証明書の利用者はアプリケーションごとに異なる証明書を入手し設定する必要がありますし、 証明書を利用する TLS の実装はプロトコル共通の検証の実装を持つことができず、 アプリケーション非依存の通信当事者認証の仕組みであるはずの PKIX の旨味も半減です。
[133] 実際問題、ホストの認証に関するプロトコルや仕様書間で規定が異なる部分は厳密に仕様書通りに実装されているとは限らず、 実装ごとに解釈が異なる危険な領域であると認識するべきでしょう。
[34] アプリケーションプロトコルのクライアントは、 service identity
を次のようにして検証します >>33。
[55] 証明書に示された識別子を順に調べ、 参照識別子のリストとの一致を検査します。一致するものが見つかれば、 そこで探すのをやめるべきです。 >>33
[56] 証明書に DNS-ID、SRV-ID、URI-ID、応用依存の (クライアントが対応する) 識別子型の識別子が含まれているなら、 CN-ID の参照識別子との一致を調べてはなりません。 含まれていないなら、フォールバックとして CN-ID の一致を検査して構いません。 >>33
[38] クライアントは、参照識別子のリストを作成しなければなりません >>33。
[52] まず利用者の入力や設定、ハイパーリンクなどによって指定された接続先情報から、 ドメイン名の情報と応用サービス型を得ます >>33。
[53] これは入力に直接含まれる情報を取り出すだけかもしれませんし、 何らかの解決サービスに問い合わせた結果かもしれません。 ただし攻撃者が介在し得ない安全な方法で得たもの (利用者が明示的に指定したもの、 DNSSEC により得たものなど) でなければなりません >>33。 入力に直接由来するドメイン名 (source domain) を使うべきで、 それを DNS 解決するなどして得られたドメイン名 (derived domain) を使うべきではありません >>33。
[54] 次に、ドメイン名と応用サービス型から、参照識別子のリストを得ます。
[45] どの識別子型の識別子を含めるかは local policy の問題です。 例えば特定のサービスにのみ接続するよう構築されたクライアントでは、 その応用サービス型の SRV-ID のみ含めることにできます。 より一般的なクライアントでは SRV-ID と DNS-ID の両方を含めます。 当面の間は CN-ID にも対応する必要がある可能性が高いです。 >>33
[76] CN-ID が複数ある場合は定義上 CN-ID とは言わないはずですが、 実際には複数含まれた証明書も存在しています (>>22)。 RFC 6125 の定義通りに処理するなら、複数ある場合には資源識別子のリストには含めないことになります。 HTTPS などいくつかの仕様は、どれを選ぶべきかを規定しています (HTTPS、RDN 参照)。
[48] Webブラウザーは、 www.example.com の HTTPS において
[49] MUA は、 IMAPS example.net が
mail.example.net に解決される時、
[57] クライアントは、参照識別子のDNSドメイン名部分が一致するか検査しなければなりません。 参照識別子のDNSドメイン名が伝統的ドメイン名なら、 ASCII大文字・小文字不区別で各ラベルを順に比較しなければなりません。 参照識別子のDNSドメイン名が IDN なら、 UラベルをAラベルに変換した上で、 ASCII大文字・小文字不区別で各ラベルを順に比較しなければなりません。 >>33
[99] Chrome も Firefox も、証明書のドメイン名が大文字でも、 一致すると判定します。
[100] Chrome も Firefox も、証明書のドメイン名が非ASCII文字を含む時、 一致しないとみなします。
[101] ただし Chrome は、証明書のドメイン名が非ASCII文字を含んでも、 それを正規化すると URL の Aラベルとなるなら、 一致するとみなすようです。
[103] Chrome でも Firefox でも、証明書のドメイン名が PSL に含まれるものであっても、かわらず普通に扱います。
[104] Chrome でも Firefox でも、証明書のドメイン名が内部名であっても、 かわらず普通に扱います。
[58] ワイルドカード文字の扱いについては、ワイルドカード証明書の項を参照。
[59] SRV-ID や URI-ID については応用サービス型の一致も検査しなければなりません >>33。
[60] SRV-ID の応用サービス名部分は、 DNS SRV の仕様にそって大文字・小文字不区別で比較しなければなりません >>33。
[61] URI-ID の URL scheme 部分は、 URL の仕様にそって大文字・小文字不区別で比較しなければなりません >>33。
[62] 証明書に示された識別子で資源識別子に一致するものが見つかれば、 service identity の検査は成功です。クライアントはその資源識別子を当該応用サービスの検証済み identity として使わなければなりません >>33。
[63] 証明書に示された識別子で資源識別子に一致するものが見つからなかった場合で、 以前に当該応用サービスの証明書をいずれかの資源識別子に pin している場合で、証明書が pin された証明書と一致する場合には、 service identity の検査は成功です >>33。
[64] 証明書に示された識別子で資源識別子に一致するものが見つからなかった場合で、 pin された証明書もない場合、対話的なクライアントは利用者に identity が一致しなかったと通知し、通信は問題ある証明書であるとの誤りにより自動的に終端するべきです >>33。
[65] 対話的なクライアントの中には、その場合であっても処理を続行する、 つまり証明書を pin する選択肢を利用者に示すものもあります。 特殊な状況ではそのような動作も必要かもしれませんが、高度な利用者のみに提示するべきものです。 しかも極めて注意して取り扱うべきものですから、 pin する前に certification path 全体の確認を強制するなど注意が必要です。 >>33
[66] クライアントが人間利用者が直接制御しない自動化された応用である場合には、 問題ある証明書であるとの誤りにより自動的に終端し、誤りを適宜記録するべきです。 これを抑制する設定を設けても構いませんが、既定値としてはなりません。 >>33
[134] HTTPSサーバー認証は、 RFC 2818 により定められています。
[135] RFC 6125 に基づく改訂は、未だ行われていません。
[136] JWSの取得プロトコルは RFC 6125 による認証を求めています。
[154] クライアントは、鯖のホスト名が分かっているなら、
鯖の Certificate メッセージに示された鯖の identity
を検査しなければなりません。
通常は URL で指定されたホストに要求を送信するので、
ホスト名は既知です。 >>151
[156] 型 dNSName の subjectAltName 拡張が示されている場合には、 これを identity として使わなければなりません。そうでない場合には、 証明書の Subject 欄の (最も詳細な) Common Name 欄を identity として使わなければなりません。 >>151
[97] Chrome も Firefox も、 SAN があるとき、 CN を無視します。 (仕様通りの動作。)
[122] 「最も詳細な」の部分について、 RFC 6125 は混乱があることを指摘し、
CN が複数含まれない場合のみ CN-ID とみなすことにしています
(RDN、CN-ID 参照)。ただし RFC 6125 は RFC 2818 を更新するものではなく、
また HTTPS の実装が実際にどう処理するかは定かではありません。
[98] Chrome は、 CN が複数ある時、最後のものを採用するようです。 Firefox は、最初のものを採用するようです。
[158] 一致の判定は、 RFC 2459 の規則によります。 複数の identity が示されている場合には、いずれかに一致すれば一致とします。 >>151, >>168 ワイルドカード文字も使えます。
[161] ホスト名ではなく IPアドレスを指定して接続する場合には、
証明書の subjectAltName 拡張の iPAddress と完全に一致しなければなりません。
>>151
[125] 実際の Webブラウザーは、 SAN がないとき、 CN が IPアドレスと完全に一致するなら、 一致とみなします >>124。 Chrome も Firefox も CN に IPv4アドレスを指定すると、 そのように動作します。
[110] Chrome でも Firefox でも、これは正規形の IPv4アドレスの文字列表現でなければ認識されません。
[105] Chrome >>102 と Firefox >>118 のソースコードによると、 この扱いは IPv4アドレスのみで、 IPv6アドレスには適用されないようです。
[108] SAN がないというのは、 DNS-ID と IPアドレスの指定がどちらもないことをいいます。 他の、例えばメールアドレスの指定があっても、 Firefox も Chrome も、 CN-ID を使います。
[96] Chrome も Firefox も、 CN と SAN にIPv4アドレスを指定しても、 IPアドレスの URL でアクセスした時一致とみなしませんでした。
[93] Chrome も Firefox も、IPアドレスの記述のない証明書のとき、 IPアドレスの URL でのアクセスでエラーとします。
[129] Chrome も Firefox も、2017年には CN への対応を原則として廃止しました。
[172] クライアントは信頼する CA を注意深く選び、 信頼する CA証明書を保存する場所が不正に改変されないよう注意するべきです >>171。
[155] クライアントが外部情報により鯖の期待される identity を承知しているなら、ホスト名の検査を省略できます。 例えば番地とホスト名が動的に決まる機械に接続する場合で、 鯖が示す証明書が分かっているなら、省略できます。 特別な場合には鯖の identity を完全に無視しても構いませんが、 危険なことは理解しなければなりません。 >>151
[162] ホスト名と証明書の identity が一致しない場合には、 利用者指向のクライアントは利用者にこれを通知するか、 証明書誤りにより接続を終端するかのいずれかとしなければなりません。 通知する場合には、利用者に接続を継続するか選択させても構いません。 自動化されたクライアントは (あれば) 誤りを記録しなければならず、 証明書誤りにより接続を終端するべきです。 自動化されたクライアントは設定によりこの検査を無効化しても構いませんが、 有効にする設定を設けなければなりません。 >>151
[106] 対話的な Webブラウザーは、原則としてこれらの規定に従うものの、 利用者の判断により名前が一致しない証明書であっても個別に閲覧を認められるのが一般的です。 Webアプリケーションの開発用鯖など一般向けでない場合を中心に、 そのような利用方法が可能なことに依存している場合もあります。 非対話的な利用者エージェントも、証明書の検証を省略する動作モードを用意していることが普通です。
[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
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
When using TLS, the client MUST perform a TLS/SSL
server certificate check, per RFC 6125 [RFC6125].
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
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
テキサス大学オースティン校およびスタンフォード大学の研究者らによる研究(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
[138] Ballot 144 - Validation rules for .onion names - CAB Forum, https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/
[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