Nginxでのセッション再開キャッシュ
数日前、nginxでのセッション再開に関するブログ投稿を読みました。
そのテキストの中で、著者は、nginxはセッションキャッシュを定期的にクリアする機能を提供していないと主張しています。 「ssl_session_timeout」の有効期限が切れると、セッションは使用されなくなりますが、ファイルはまだハードディスク上にあり、攻撃者によって読み取られる可能性があるため、この時点では「ForwardSecrecy」は役に立ちません。
セッションIDを使用する代わりに、セッションキャッシュを無効にして、セッションチケットを使用することをお勧めします。これを行うには、80バイトのランダム性を持つ「ticket_key」を少なくとも1日に1回作成する必要があります。
インターネットで詳細を検索しましたが、役立つ情報が見つかりませんでした。
Q1：nginxセッションキャッシュの場所はどこですか？TLS接続データ（セッション）がハードディスク上にあるかどうかを確認するにはどうすればよいですか？
Q2：セッションチケットを使用することをお勧めしますか？
最初の質問には答えられませんが、2番目の質問について少し話すことができます。
このブログ投稿は、TLSv1.2のセッションチケットの欠陥に関するいくつかの良い情報を提供します： https://blog.filippo.io/we-need-to-talk-about-session-tickets/ 。
マイケルが両方に問題があると言っているように、TLSv1.3（ 文字通りサインオフ を使用していて、執筆時に実装で利用できるようになった場合）のみ、TLS再開を完全に安全に使用できます。
ただし、TLSセッション再開を使用しない場合のパフォーマンスコストは重要であり、IMHOのリスクは比較的低いと言えます（誰かがサーバーにアクセスできる場合、私が知る限り、サーバーはゲームオーバーです）。そのため、ここではセッションIDとセッションチケットの両方を使用することをお勧めします。特に一部のクライアント（SafariおよびIE）はセッションチケットをサポートしていません）として、特にSafariにはまだモバイルとタブレットで多くのユーザーがいます-本当に大幅にやりたいですか？すべてのiOSユーザーの速度を落としますか？