SSL証明書を使用する前に「RSASharedPrimes」をテストする必要がありますか？
2012年からいくつかの論文があります 共有素数を因数分解することによっていくつかの係数を因数分解することが可能であると述べています。上記のリンクには、この事実を検証およびテストするためのpythonソースコードが含まれています。
この知識を前提として、サーバーのすべてのSSL証明書、および脆弱である場合とそうでない場合があるその他の暗号化アーティファクトに関して、ITセキュリティプロフェッショナルとして何をすべきか。
質問
SSLが脆弱な場合、影響を受ける証明書をテストして再発行することをお勧めしますか？または、Webサーバーが使用する暗号を単に変更する必要がありますか？
RSAまたはDHEベースのセッションからの以前の暗号化データは脆弱ですか？
テストするのが簡単な場合は、そうすることもできます。私はあなたのためにこのテストを行うサービスや他のメカニズムを知りませんが、もしあなたがそれを持っているなら。攻撃の可能性はおそらくかなり低いですが、重大度はかなり極端です。あなたがそれを検出した場合、それは確かに修正する価値があります。
はい。以前のセッションがキャプチャされた場合、秘密鍵を取得できれば復号化できます。 Diffie-Hellmanを使用してエフェメラルセッションキーを生成しない限り（現在は非常にまれです）。今日のセッションを明日の攻撃から保護する方法については、「PerfectForwardSecrecy」を検索してください。
素数は、certificateではなく、keyを生成するときに決定されることに注意してください。キーの生成には（時間以外は）費用がかからず、何度でも実行できます。したがって、テストする場合は、事前に（または一度に複数の）キーを生成してから、「強力な」キーのみに基づいてCSRを生成することもできます。悪いPRNGは通常、悪いキーのソースであるため、良いTRNGを備えたコンピューター（最近のLinuxやBSDなど）がここで役立ちます。
また、いくつかのCAでは、証明書を「再入力」できます。これは、基本的に、元の有効期限で新しい証明書を発行することを意味します。したがって、いずれかの時点でキーが疑わしい場合は、それがオプションになる可能性があります。
新しいキーを作成したばかりの場合は、わざわざテストしないでください。代わりに、新しいキーを作成するときに、適切なランダム性を使用するようにすることをお勧めします。これは、予防が検出よりもはるかに簡単な状況です。
研究者は、あなたが言及している問題は、主に組み込みデバイス（たとえば、消費者向けワイヤレスアクセスポイント、DSLルーターなど）で生成された秘密鍵で発生することを発見しました。これらのデバイスは、PRNGが不十分で、（多くの場合）キー生成コードがずさんな傾向があります。対照的に、信頼できるソフトウェア（OpenSSLなど）を使用してサーバー上でキーを生成した場合は、おそらく問題ありません。
（例外：Debianの失敗は一部の人々に影響を及ぼしましたが、それはかなり前のことであり、過去1、2年に生成されたキーには影響しないはずです。）