網際網路上前一百萬個網站的 SSL/TLS 分析

目前看來評估不同的ssl/tls配置已經逐漸成為了我的業餘愛好。在10月份發表了server side tls之後，我參與一些讨論密碼性能、key的長短、橢圓曲線的安全等問題的次數都明顯增多了(比較諷刺的是，當初之是以寫“server side tls”就是非常天真的希望減少我在這個話題上的讨論次數)。

ssl/tls伺服器端的配置教程如今越來越多。其中很快就得到關注的一篇是better crypto，我們曾經也在dev-tech-crpto郵件清單中讨論了多次。

人們總是對這些話題非常有熱情(我也不例外)。但是有一個問題我們一直念念不忘，就是總想着盡快幹掉那些被棄用的密碼，即便這意味着切斷了與一些使用者的連接配接。我是絕對反對這樣做的，并且始終堅信最好的做法是為所有使用者都維持向後相容性，即使是以在我們的tls伺服器上保留rc4、3des或是1024dhe key為代價。

最近在dev-tech-crypto上有這樣一個問題：“我們是否可以在firefox上将rc4完全移除？”。有人可能認為，因為firefox支援所有其他的密碼(aes, aes-gcm, 3des, camelia…)，我們當然可以在不影響使用者的前提下移除rc4。但是我們沒有實際的資料來證明這一點，是以也不能随便作出這樣的決定。

接收挑戰：我将帶上我的武器cipherscan出來兜兜風，并打算掃描下網際網路。

掃描方法

掃描腳本在github上，資料結果在這裡。未壓縮的資料有1.2gb之大，但是xz難以置信的将其壓縮成了一個隻有17mb大小的資料存檔。

我使用alexa所列出的前1,000,000個網站作為資料源。使用“testtop1m.sh”腳本并行掃描目标，并通過節流來限制同時掃描的數量(設定為100)，然後将結果寫入到“results”目錄。每個掃描目标的結果被存放在一個json檔案中。另一個腳本名為“parse_results.py”，它會掃一遍“results”目錄并計算統計資料。非常基礎的東東。

我花了大概36個小時來運作整個掃描流程。發現總共有451470個網站開啟了tls，占總數的45%。

雖然這不是一個全面的統計，但這一資料足以讓我們評價ssl/tls在現實世界中的狀态。

對這451470個網站的ssl/tls調查

密碼

cipherscan傳回了每個目标伺服器上所有支援的密碼。下表顯示了普遍被支援的密碼以及僅被一些網站所支援的密碼。最後一項最有趣，似乎1.23%的網站僅接受3des，而1.56%的網站僅接受rc4。這對于那些正考慮放棄支援3des和rc4的開發者來說是非常重要的資料。

值得注意的是：有兩個人不知出于什麼原因僅僅隻在他們的網站上開啟了camellia。好吧先生們，我為你們舉杯。

對于那些不尋常的密碼，我為其添加了字首“z”并放在清單底部，非常的顯眼。事實上從28%的網站明确支援des-cbc-sha這一點上可以看出更好的tls文檔和教育訓練的必要性。

密匙協商

讓人驚喜的是部署了ecdhe的比例。21%雖然不算是一場勝利，但是對于其被視為一種非常有希望在不久的将來取代rsa(至少是在密匙協商方面)的算法來說，這卻是一個鼓舞人心的數字。

dhe，從sslv3開始支援到現在已經有接近60%的部署量。我們需要盡快将這個數字提升到100%！

完全正向保密(perfect forward secrecy)目前非常流行，是以評估它的部署量最有趣。事實上我重複檢查了3次結果才确定下表所示的比例，75%的網站支援pfs，非常準确，因為對我來講這是非常大的數量。更令人驚訝的是，事實上61%被測試的網站，要麼是自己傾向、要麼是讓用戶端傾向于pfs key交換(des或ecdhe)而不是其它密碼。

不出所料，絕大多數——98%的dhe key是1024位。導緻這個情況的原因如下：

在apache2.4.6及其以前的版本中，dh參數總是設定為1024位并且不是使用者所能配置的。未來apache的版本會為dh參數自動選擇一個更好的值。

java6，或許還有一些其它的庫，并不支援大于1024位的dhe key。

是以，雖然大家都同意需要一個2048位的rsa算法模型，但使用1024位的dhe key，即便其有效的降低了tls的安全性，可目前還沒有任何的解決辦法——不同于打破舊用戶端的向後相容性。

在ecdhe這方面，總是使用p-256曲線來完成握手。同樣的，這也很容易了解，因為ie、chrome、firefox目前僅僅持p256。但是根據最近由djb和lange發表的研究顯示，這可能不是最安全的選擇。

下表中的曲線統計存在一些瑕疵：cipherscan在底層使用openssl，而我并不确定openssl是如何在握手階段選擇曲線的。這是cipherscan需要改進的一塊，是以希望大家不要受這些數字的影響。

協定

在協定掃描的結果中有些地方讓我很吃驚：仍然有18.7%的網站支援sslv2！拜托，各位，我們已經重複了這個問題有很多年了：sslv2漏洞太多了，不要使用它！

我非常欣賞這38個僅僅接受sslv2的網站。幹的好。

同樣有趣的是，2.6%的網站支援tlsv1.2，而不是tls1.1。合理的情況下，tlsv1.2網站的數量應該大于2.6%才對，但事實并非如此(隻有0.001%).是以我隻能想象，出于某些原因，網站都使用tlsv1和tlsv1.2，而不是1.1。

更新：hn上的“harshreality”找出了一條openssl中的更新日志可以來解釋這種行為:

不出所料，絕大多數網站都支援sslv3和tlsv1，分别為99.6%和98.7%。有少量的網站支援tls1.1和1.2，這令人擔憂，但一點也不奇怪。

考慮到近期的商業産品對tls版本的可憐的支援，是以這也不能怪系統管理者。供應商可以肯定會推動這一程序，是以在你更新下一個合同前，確定将tlsv1.2加入你的心願單。

哪些沒有被測試？

這不是一個全面的測試。還有rsa key的大小沒有被評估。同時還有tls擴充，ocsp stapling支援，以及一些值得反複觀察的有趣的特征。下次再說吧。

教育訓練，以及向後相容

如果要說這個小實驗說明了些什麼問題，那就是舊的密碼和協定還遠遠沒有被抛棄。當然，如今你可以決定在用戶端上幹掉rc4和3des，但是要注意有一小部分的網際網路将是你和你的使用者連接配接不到的。

對這個情況我們可以做什麼？教育訓練是關鍵：tls是一個複雜的專題，而大多數的管理者和網站所有者沒有時間和知識去找遍幾十個郵件清單和部落格來得到最好的配置選擇。

這也是編寫server side tls和better crypto等文檔的首要動機。我們中的一些人是緻力于改進這些文檔的。但是我們需要一個團隊來傳播這些資訊，在會議、郵件清單和使用者群中指導管理者們，同時推動網站所有者為他們的網站添加更多的安全配置。我們需要一些幫助：去那裡！教tls吧！

原文連結： julien vehent 翻譯： 伯樂線上 - deathmonkey