2010-02-01 139 views
3

我已經被賦予了尋找替代一段舊代碼的任務。我假設它測試了瀏覽器是否支持128位加密。這裏是舊代碼:(我故意將鏈接分成4行)

http://www.verisign.com/update-cgi/outPage.exe
?good=../docs/html/good.html
&nsbad=../docs/html/upgradeNSonly.html
&ie2=../docs/html/upgradeIEonly.html

你有沒有看過這個代碼?
如何在php頁面中複製此功能?

如何測試瀏覽器以查看它是否支持128位加密?

澄清
老站長髮現了一個鏈接,威瑞信,即這瀏覽器檢查。 Verisign自此停止支持此鏈接。就個人而言,我認爲我們應該簡單地告訴我們的客戶點擊幫助>關於有瀏覽器中,並查找CYPHER強度。如果它不是至少128,那麼我們只是告訴他們升級瀏覽器。

回答

1

所有現代瀏覽器都支持128位加密的開箱。你是否需要支持比IE 5.5更早的瀏覽器?

您可以檢查瀏覽器的用戶代理字符串並進行假設,也可以將它們引導至使用128位SSL證書的頁面,如果它們繼續存在,那麼它們必須支持它。

+0

@CalebD - 感謝您指點我「保持簡單愚蠢」。我決定保持簡單,並告訴客戶如何自行檢查瀏覽器的密碼強度。 – 2010-02-02 20:23:28

0

所有現代瀏覽器都支持128位。但是,您應該以管理方式強制執行此服務器端,因爲有人可能會使用較舊的瀏覽器或僞造使用較低位級別加密(例如40或56)的請求。

我建議你問如何去執行根據你的平臺上設置在Web服務器了:

http://serverfault.com

1

您在這裏粘貼的東西是不是代碼 - 它的URL。

如果你不理解的差異那麼我希望你不會真正瞭解任何答案的隱含問題「你如何衡量在PHP加密質量?」但在這裏不用反正....

首先,有沒有辦法測試,如果瀏覽器支持特定的加密算法或其他比測試使用加密方式連接密鑰大小 - 因此,這意味着配置多個不同級別的加密在你的服務器上並在每一箇中創建網頁,然後測試瀏覽器可以連接到什麼。這不是一項微不足道的任務,也不是大多數人在正常生活中會遇到的問題。

如果您在apache上使用mod_ssl,並結合mod_php(您沒有說PHP運行的是OS/webserver),那麼您將能夠看到各種附加的$ _SERVER變量,包括「SSL_CIPHER」 「SSL_CIPHER_USEKEYSIZE」,「SSL_CIPHER_ALGKEYSIZE」和「SSL_SERVER_A_KEY」

又見

http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#envvars

所以我真的懷疑你是問錯了問題,但我不能告訴正確的問題是什麼,直到你可以回答這個問題:

通過了解瀏覽器是否支持128位加密,你期望達到什麼目的?

C.

+0

我們的網站只支持具有128位或更高級別加密的瀏覽器。如果我們客戶的瀏覽器不支持這種級別的加密,我需要發佈一條消息,告訴他們升級瀏覽器。我認爲最簡單的做法是讓客戶點擊幫助並查找密碼強度。 – 2010-02-01 22:30:14

+0

您可能想嘗試將https iframe放入http頁面並嘗試檢測它是否加載(可能通過在iframe中呈現一些javascript) - 但我懷疑大多數瀏覽器可能會將這些視爲不同的來源,因此會隔離這兩個框架。當然,從http頁面到https頁面的Ajax調用將不起作用。Cookie將在http和https之間傳輸,因此您可以嘗試從http中刪除cookie,嘗試在https iframe中檢測它,然後使用會話在後續頁面上處理結果。 – symcbean 2010-02-02 09:40:10

1

在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位,那麼這是一個需要考慮的問題。

相關問題