SSLセッションIDとCookieベースのセッション検証を一緒に使用する方が安全ですか？
私はDjangoを使用しています。これはPythonのWebフレームワークです。大好きですが、セッション処理はCookieベースです。SSLを使用すると、かなり「安全」であると確信していますが、そのCookieが危険にさらされた場合のフェイルセーフの種類があると思います。また、Apache2とMod_WSGIを使用していることにも言及する必要があります。Apache2セッションごとに、ルートから取得できるSSL_SESSION_ID環境変数pythonモジュール具体的には、私の質問は、Apache2からのSSL_SESSION_IDがデータベース（およびクライアントブラウザ）のSession_Key Cookieと一致することを要求することで、MITM攻撃やセッションハイジャックなどの防止に役立ちます。一方は、クライアントがSSL_SESSION_IDについてわからない（私は考える）ためにそれを偽造することができなかったので、それが可能であると考えています。他方で、攻撃者が暗号化またはブラウザを危険にさらして、とにかくパスワードを取得して開始するだけのクッキーよりも新しいセッション。
SSLセッションIDは一時的なものです。これは、クライアントが以前のSSLハンドシェイク、特にそのハンドシェイクの非対称暗号から取得したネゴシエートされた対称秘密値について覚えている「SSLセッションパラメータ」を指定します。これはRAM=にのみ保持されます。ユーザーが再起動した場合、または単にすべてのブラウザーウィンドウを閉じた場合でも、ユーザーはセッションIDを忘れます。認証メカニズムの一部としてSSLセッションIDを使用する場合その後、ブラウザを閉じて再度開くユーザーは、パスワードで再度認証する必要があります。
それが必要な場合は、SSLセッションIDを使用してください。 Webベースの銀行口座管理のためにそうした銀行を知っています。
serverが再起動すると、SSLセッションIDも廃止されます。データベースに保存されている場合でも、再起動されたサーバーは実際のセッションキー（サーバー、また、それをRAM=のみ）に保存するため、クライアントからの次の接続時にフルハンドシェイクで新しいセッションをネゴシエートします。また、過去のセッションのサーバーメモリは構成可能ですが、多くの場合時間制限があります（Apacheの場合、 ドキュメント 、ディレクティブSSLSessionCacheおよびSSLSessionCacheTimeoutを参照してください。）クライアントのメモリがプロセスに基づいていることにも注意してください：PCでは、すべてのウィンドウを閉じるとブラウザープロセスが終了する傾向があります;スマートフォンやタブレットでは、物事を非常に長い時間実行し続けたいので、プロセスを本当に強制終了するのは、より複雑なプロセスです（通常、ブラウザーユーザーがバッテリーを使い切ったときにのみ「閉じる」）。
一方、それほど重要ではないサイトの場合（ユーザーの観点から）、ユーザーは認証を1回したときにそれを好む傾向があり、再起動後や再起動後でも「記憶」されます。ブラウザも閉じます。このような機能が機能するためには、それを回避することはできません。クライアント側にユーザー固有のシークレットが格納されている必要があります。 Cookieは他のどのメカニズムよりも悪くはありません。Cookieは、すぐに利用でき、すべてのブラウザと互換性がある唯一のメカニズムです。
概要：非常に一時的なセッションが必要な場合は、SSLセッションIDを使用します。これは、ブラウザを閉じると自動的に消えます（ブラウザ）プロセス、関連するウィンドウだけではありません）。有効期間の長い認証にはCookieを使用してください。これらは互換性がありません。それらは同じ時間スケールで動作しません。
セキュリティについて厳密に話している場合は、SSLで十分です。
- SSLはMITM攻撃を防止します（サーバーの秘密鍵が危険にさらされたり、交渉された鍵が開示されたりしない限り）。
- 誰かがクライアントからCookieを盗んだ場合、クライアントPCが危険にさらされ、あなたはそれについて何もすることができません。攻撃者は完全に制御できるようになり、必要なだけトークン/セキュリティを追加できますが、攻撃者は完全にアクセスできます。
とにかく、いつでもCookieを使用してユーザーを識別することができます。たとえば、さまざまな接続内でのアクティビティの追跡、広告、ユニークアクセス数のカウントなどです。