OCSP Stapingの調査
OCSP Stapingの概要
OCSPとは?
- Online Certificate Status Protocol
- オンラインで証明書の状態を検証するプロトコル
- RFC2560
- 応答する証明書の状態は有効(good)、失効(revoke)、不明(unknown)の3通り。それに加えて、OCSP応答状態(無応答)も考慮する必要がある。
OCSP応答の例
- openssl s_clientコマンドで以下のように確認できる。
> openssl s_client -connect www.office.com:https -CApath /etc/ssl/certs -status
CONNECTED(00000005)
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: 546D834E713BB4ED0E57829451B0BED494F9E833
Produced At: Nov 9 04:03:09 2018 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 2985FC613DBE2FB0120F5E420E4C9EC3D59EFD7C
Issuer Key Hash: 08FE259F74EA8704C2BCBB8EA8385F33C6D16C65
Serial Number: 2D000084B7E83E2BB6EC8EA1920000000084B7
Cert Status: good
This Update: Nov 9 04:03:09 2018 GMT
Next Update: Nov 13 04:03:09 2018 GMT
Response Single Extensions:
OCSP Archive Cutoff:
Nov 9 04:03:09 2017 GMT
- この例では、サーバ証明書の状態は:good
- 直近の状態確認は2017/11/9 04:03:09 GMTに実施。次の更新は11/13予定。
OCSPアクセス情報をもつサーバ証明書の例
- OCSPアクセスを要求するかどうかはTLSサーバ次第。(サーバ証明書次第)
- chromeなどのブラウザでアクセスし、URLバーにある証明書アイコンをクリックするとOCSPへのアクセス先が確認できる。以下の図では、拡張領域、認証局情報アクセスというのが確認できる。
> openssl s_client -connect www.office.com:https -CApath /etc/ssl/certs -status
CONNECTED(00000005)
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: 546D834E713BB4ED0E57829451B0BED494F9E833
Produced At: Nov 9 04:03:09 2018 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 2985FC613DBE2FB0120F5E420E4C9EC3D59EFD7C
Issuer Key Hash: 08FE259F74EA8704C2BCBB8EA8385F33C6D16C65
Serial Number: 2D000084B7E83E2BB6EC8EA1920000000084B7
Cert Status: good
This Update: Nov 9 04:03:09 2018 GMT
Next Update: Nov 13 04:03:09 2018 GMT
Response Single Extensions:
OCSP Archive Cutoff:
Nov 9 04:03:09 2017 GMT
* 上記例では、方法1としてCA発行者の証明書へのURI(この例では中間CAの証明書)、方法2としてオンライン証明書状況プロトコルによるURIが提示されている。
OCSPの問題点
- HTTPSクライアントとCAとの間にOCSPリクエスト・レスポンスの通信が発生する。
- 通信負荷の増加
- 通信のための穴が必要
- 通信できない場合、失効確認ができない。
- HTTPSクライアントのアクセス履歴がCAに漏れる。
OCSP Stapingとは?
- Staple(ホッチキスでとめる):SSLハンドシェイク中にサーバ応答に添付するという意味。添付される情報は、CAがこのサーバ証明書の失効状態を確認してますよ、という証明。
- 上記の意味からわかるように、失効状態の取得・更新は、WebサーバとCAとの間で行われ、クライアント(ブラウザ)は、SSLハンドシェイク中にサーバから応答された証明書の有効状態を検証・判断するだけで、Webサーバ以外に問い合わせはしない。
- 上記で述べたOCSPの問題点2つがクリアされる。
TLS拡張ハンドシェイク
- TLS拡張:RFC6066
- TLSクライアントは、ClientHelloにCertificateStatusRequestを含める。下の図はTLSサーバ側でキャプチャしものでClient Helloに拡張status_requestとして、OCSP Status Requestが乗っているのが確認できる。
- TLSサーバは、TLSクライアントのOCSP Status Requestに対して、Server HelloにCertificate Statusを応答、その中にOCSP応答を含む。
まとめ
- OCSPはTLSハンドシェイクの過程で、サーバ認証を行う際に、そのサーバ証明書(または中間証明書)が有効かどうかを判定するプロトコル。
- OCSPでは、TLSクライアントが、そのサーバ証明書の発行母体に対して、OCSPで問い合わせするが、通信負荷の問題、プライバシーの問題がある。
- OCSP Staplingは、OCSP要求をTLSサーバが適切なタイミングで行い、OCSP応答をキャッシュ、TLSハンドシェイク時に、TLSクライアントから要求(ocsp status request)があれば、Certificate StatusとしてOCSP応答データを応答する。
- TLSクライアントが、ocsp status requestを要求するかどうかは、サーバ証明書の拡張領域に認証局情報アクセスが登録されているかどうかよる。
- 証明書の拡張領域に認証局情報アクセスを付与するのは、その証明書を発行するCA。アクセス先、証明書の状態(有効、無効、不明)管理も、発行CAの役割となる。
Author And Source
この問題について(OCSP Stapingの調査), 我々は、より多くの情報をここで見つけました https://qiita.com/thetsuthetsu/items/ddbed701c08bd4711cad著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .