目前看來評估不同的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文件和培訓的必要性。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
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%！
|
1 2 3 4 |
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需要改進的一塊，所以希望大家不要受這些數字的影響。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
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中的更新日誌可以來解釋這種行為:
|
1 2 |
Changes between 1.0.1a and 1.0.1b <a title="26 Apr 2012" href="https://jve.linuxwall.info/blog/26%20Apr%202012">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加入你的心願單。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
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吧！