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