互聯網上前一百萬個網站的 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文檔和培訓的必要性。
Supported Ciphers Count Percent -------------------------+---------+------- 3DES 422845 93.6596 3DES Only 5554 1.2302 AES 411990 91.2552 AES Only 404 0.0895 CAMELLIA 170600 37.7877 CAMELLIA Only 2 0.0004 RC4 403683 89.4152 RC4 Only 7042 1.5598 z:ADH-DES-CBC-SHA 918 0.2033 z:ADH-SEED-SHA 633 0.1402 z:AECDH-NULL-SHA 3 0.0007 z:DES-CBC-MD5 55824 12.3649 z:DES-CBC-SHA 125630 27.8269 z:DHE-DSS-SEED-SHA 1 0.0002 z:DHE-RSA-SEED-SHA 77930 17.2614 z:ECDHE-RSA-NULL-SHA 3 0.0007 z:EDH-DSS-DES-CBC-SHA 11 0.0024 z:EDH-RSA-DES-CBC-SHA 118684 26.2883 z:EXP-ADH-DES-CBC-SHA 611 0.1353 z:EXP-DES-CBC-SHA 98680 21.8575 z:EXP-EDH-DSS-DES-CBC-SHA 11 0.0024 z:EXP-EDH-RSA-DES-CBC-SHA 87490 19.3789 z:EXP-RC2-CBC-MD5 105780 23.4301 z:IDEA-CBC-MD5 7300 1.6169 z:IDEA-CBC-SHA 53981 11.9567 z:NULL-MD5 379 0.0839 z:NULL-SHA 377 0.0835 z:NULL-SHA256 9 0.002 z:RC2-CBC-MD5 63510 14.0674 z:SEED-SHA 93993 20.8193
密匙協商
讓人驚喜的是部署了ECDHE的比例。21%雖然不算是一場勝利，但是對于其被視為一種非常有希望在不久的將來取代RSA(至少是在密匙協商方面)的算法來說，這卻是一個鼓舞人心的數字。
DHE，從SSLv3開始支持到現在已經有接近60%的部署量。我們需要盡快將這個數字提升到100%！
Supported Handshakes Count Percent -------------------------+---------+------- DHE 267507 59.2524 ECDHE 97570 21.6116
PFS
完全正向保密(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需要改進的一塊，所以希望大家不要受這些數字的影響。
Supported PFS Count Percent PFS Percent -------------------------+---------+--------+----------- Support PFS 342725 75.9131 Prefer PFS 279430 61.8934 DH,1024bits 262561 58.1569 98.1511 DH,1539bits 1 0.0002 0.0004 DH,2048bits 3899 0.8636 1.4575 DH,3072bits 2 0.0004 0.0007 DH,3248bits 2 0.0004 0.0007 DH,4096bits 144 0.0319 0.0538 DH,512bits 76 0.0168 0.0284 DH,768bits 825 0.1827 0.3084 ECDH,P-256,256bits 96738 21.4273 99.1473 ECDH,B-163,163bits 37 0.0082 0.0379 ECDH,B-233,233bits 295 0.0653 0.3023 ECDH,B-283,282bits 1 0.0002 0.001 ECDH,B-571,570bits 329 0.0729 0.3372 ECDH,P-224,224bits 4 0.0009 0.0041 ECDH,P-384,384bits 108 0.0239 0.1107 ECDH,P-521,521bits 118 0.0261 0.1209
協議
在協議掃描的結果中有些地方讓我很吃驚：仍然有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中的更新日志可以來解釋這種行為:
Changes between 1.0.1a and 1.0.1b <a title="26 Apr 2012" >26 Apr 2012</a> - OpenSSL 1.0.0 sets SSL_OP_ALL to 0x80000FFFL and OpenSSL 1.0.1 and 1.0.1a set SSL_OP_NO_TLSv1_1 to 0x00000400L which would unfortunately mean any application compiled against OpenSSL 1.0.0 headers setting SSL_OP_ALL would also set SSL_OP_NO_TLSv1_1, unintentionally disablng TLS 1.1 also. Fix this by changing the value of SSL_OP_NO_TLSv1_1 to 0x10000000L Any application which was previously compiled against OpenSSL 1.0.1 or 1.0.1a headers and which cares about SSL_OP_NO_TLSv1_1 will need to be recompiled as a result.
不出所料，絕大多數網站都支持SSLv3和TLSv1，分別為99.6%和98.7%。有少量的網站支持TLS1.1和1.2，這令人擔憂，但一點也不奇怪。
考慮到近期的商業產品對TLS版本的可憐的支持，所以這也不能怪系統管理員。供應商可以肯定會推動這一進程，所以在你更新下一個合同前，確保將TLSv1.2加入你的心愿單。
Supported Protocols Count Percent -------------------------+---------+------- SSL2 85447 18.9264 SSL2 Only 38 0.0084 SSL3 449864 99.6443 SSL3 Only 4443 0.9841 TLS1 446575 98.9158 TLS1 Only 736 0.163 TLS1.1 145266 32.1762 TLS1.1 Only 1 0.0002 TLS1.2 149921 33.2073 TLS1.2 Only 5 0.0011 TLS1.2 but not 1.1 11888 2.6332
哪些沒有被測試？
這不是一個全面的測試。還有RSA key的大小沒有被評估。同時還有TLS擴展，OCSP Stapling支持，以及一些值得反復觀察的有趣的特征。下次再說吧。
培訓，以及向后兼容
如果要說這個小實驗說明了些什么問題，那就是舊的密碼和協議還遠遠沒有被拋棄。當然，如今你可以決定在客戶端上干掉RC4和3DES，但是要注意有一小部分的因特網將是你和你的用戶連接不到的。
對這個情況我們可以做什么？培訓是關鍵：TLS是一個復雜的專題，而大多數的管理員和網站所有者沒有時間和知識去找遍幾十個郵件列表和博客來得到最好的配置選擇。
這也是編寫Server Side TLS和Better Crypto等文檔的首要動機。我們中的一些人是致力于改進這些文檔的。但是我們需要一個團隊來傳播這些信息，在會議、郵件列表和用戶群中指導管理員們，同時推動網站所有者為他們的網站添加更多的安全配置。我們需要一些幫助：去那里！教TLS吧！
原文鏈接： Julien Vehent 翻譯： 伯樂在線 - deathmonkey
譯文鏈接： http://blog.jobbole.com/55550/