在SSL中,客戶端連接併發送它所支持的密碼列表;那麼服務器會選擇其中一個也支持的密碼,並且該密碼用於連接。只有當連接建立時(「握手」完成)HTTP纔會起作用。
在您的設置中,這意味着您應該配置您的SSL服務器以接受各種密碼,但要優先使用128位以上的私鑰而不是其他密鑰。因此,只有當客戶端和服務器都不支持128位或更多的密碼時,纔會選擇小於128位的密碼。然後,根據實際協商的密碼,在該連接內發送的頁面將被更改。
對於這樣的設置,你必須能夠做到以下幾點:
- 用來配置SSL服務器支持的密碼列表;
- 在客戶端和服務器都支持的密碼列表中強制執行客戶端首選項的服務器首選項;
- 訪問您的頁面生成引擎中實際使用的密碼,例如PHP。
在Apache的mod_ssl,看來1點很容易(「的SSLCipherSuite」指令)和「環境變量」一節似乎表明SSL服務器願意給上選擇什麼密碼的一些信息頁面生成引擎;尤其是SSL_CIPHER_USEKEYSIZE
變量看起來相當不錯。因此第3點看起來也很容易。但我不確定這是如何轉化爲PHP世界的。
對於第2點,這有點困難。 「SSLCipherSuite」的文檔似乎告訴服務器,默認情況下,它使用自己的首選順序,因此第二點也很容易,但這需要一些測試。
現在只剩下一個小點,這就是3DES的狀態。名義上,它使用一個192位密鑰。任何體面的密碼編程者或程序員都會指出,在這192位中,只有168位被使用(額外的位應該用作奇偶校驗位,但沒有人會證實這些位,他們只是被忽略)。現在,一些學者還表示,實際的算法強度較低,至少在適當的學術光線下看來,與112位密鑰相當。因此,NIST(美國聯邦機構處理此類標準)因此發佈了一項建議,即3DES應被視爲提供「僅112位安全性」,並且112低於128.
當然,112位在技術上不可行的領域還有很長的路要走(即使技術進步一直保持其繁忙的步伐,至少應該保持30年),所以這對於任何實際情況都不是問題,但如果您處於一個標準瘋狂的思維框架,並希望執行「真正的」128位,那麼這是一個需要考慮的問題。
@CalebD - 感謝您指點我「保持簡單愚蠢」。我決定保持簡單,並告訴客戶如何自行檢查瀏覽器的密碼強度。 – 2010-02-02 20:23:28