|
|
|
花了數小時閱讀了如潮的好評，Bob最終迫不及待為他購買的托斯卡納全脂牛奶點擊了“進行結算”，然后……
哇!剛剛發生了什么?
在點擊按鈕過后的220毫秒時間內，發生了一系列有趣的事情，火狐瀏覽器(Firefox)不僅改變了地址欄顏色，而且在瀏覽器的右下角出現了一個小鎖頭的標志。在我最喜歡的互聯網工具Wireshark的幫助下，我們可以通過一個經過略微調整的用于debug的火狐瀏覽器來探究這一過程。
根據RFC 2818標準(譯者注：RFC 2818為HTTP Over TLS-網絡協議)，火狐瀏覽器自動通過連接Amazon.com的443端口來響應HTTPS請求。
很多人會把HTTPS和網景公司(Netscape)于上世紀九十年代中期創建的SSL(安全套接層)聯系起來。事實上，隨著時間的推移，這兩者之間的關系也慢慢淡化。隨著網景公司漸漸的失去市場份額，SSL的維護工作移交給了Internet工程任務組(IETF)。由網景公司發布的第一個版本被重新命名為TLS 1.0(安全傳輸層協議 1.0)，并于1999年1月正式發布。考慮到TLS已經發布了將近10年，如今已經很難再見到真正的SSL通信了。
客戶端問候(Client Hello)
TLS將全部的通信以不同方式包裹為“記錄”(Records)。我們可以看到，從瀏覽器發出的第一個字節為0×16(十進制的22)，它表示了這是一個“握手”記錄。
接下來的兩個字節是0×0301，它表示了這是一條版本為3.1的記錄，同時也向我們表明了TLS1.0實際上是基于SSL3.1構建而來的。
整個握手記錄被拆分為數條信息，其中第一條就是我們的客戶端問候(Client Hello)，即0×01。在客戶端問候中，有幾個需要著重注意的地方：
隨機數：
在客戶端問候中，有四個字節以Unix時間格式記錄了客戶端的協調世界時間(UTC)。協調世界時間是從1970年1月1日開始到當前時刻所經歷的秒數。在這個例子中，0x4a2f07ca就是協調世界時間。在他后面有28字節的隨機數，在后面的過程中我們會用到這個隨機數。
SID(Session ID)：
在這里，SID是一個空值(Null)。如果我們在幾秒鐘之前就登陸過了Amazon.com，我們有可能會恢復之前的會話，從而避免一個完整的握手過程。
密文族(Cipher Suites)：
密文族是瀏覽器所支持的加密算法的清單。整個密文族是由推薦的加密算法“TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA”和33種其他加密算法所組成。別擔心其他的加密算法會出現問題，我們一會兒就會發現Amazon也沒有使用推薦的加密算法。
Server_name擴展：
通過這種方式，我們能夠告訴Amazon.com：瀏覽器正在試圖訪問https://www.amazon.com。這確實方便了很多，因為我們的TLS握手時間發生在HTTP通信之前，而HTTP請求會包含一個“Host頭”，從而使那些為了節約成本而將數百個網站域名解析到一個IP地址上的網絡托管商能夠分辨出一個網絡請求對應的是哪個網站。傳統意義上的SSL同樣要求一個網站請求對應一個IP地址，但是Server_name擴展則允許服務器對瀏覽器的請求授予相對應的證書。如果沒有其他的請求，Server_name擴展應該允許瀏覽器訪問這個IPV4地址一周左右的時間。
服務器問候(Server Hello)
Amazon.com回復的握手記錄由兩個比較大的包組成(2551字節)。記錄中包含了0×0301的版本信息，意味著Amazon同意我們使用TLS1.0訪問的請求。這條記錄包含了三條有趣的子信息：
1.服務器問候信息(Server Hello)(2):
我們得到了服務器的以Unix時間格式記錄的UTC和28字節的隨機數。
32字節的SID，在我們想要重新連接到Amazon.com的時候可以避免一整套握手過程。
在我們所提供的34個加密族中，Amazon挑選了“TLS_RSA_WITH_RC4_128_MD5”(0×0004)。這就意味著Amazon會使用RSA公鑰加密算法來區分證書簽名和交換密鑰，通過RC4加密算法來加密數據，利用Md5來校驗信息。我們之后會深入的研究這一部分內容。我個人認為，Amazon選擇這一密碼組是有其自身的原因的。在我們所提供的密碼族中，這一加密組的加密方式是CPU占用最低的，這就允許Amazon的每臺服務器接受更多的連接。當然了，也許還有一個原因是，Amazon是在向這三種加密算法的發明者Ron Rivest(羅恩·李·維斯特)致敬。
2.證書信息(11)：
這段巨大的信息共有2464字節，其證書允許客戶端在Amazon服務器上進行認證。這個證書其實并沒有什么奇特之處，你能通過瀏覽器瀏覽它的大部分內容。
3.服務器問候結束信息(14)：
這是一個零字節信息，用于告訴客戶端整個“問候”過程已經結束，并且表明服務器不會再向客戶端詢問證書。
校驗證書
此時，瀏覽器已經知道是否應該信任Amazon.com。在這個例子中，瀏覽器通過證書確認網站是否受信，它會檢查 Amazon.com 的證書，并且確認當前的時間是在“最早時間”2008年8月26日之后，在“最晚時間”2009年8月27日之前。瀏覽器還會確認證書所攜帶的公共密鑰已被授權用于交換密鑰。
為什么我們要信任這個證書?
證書中所包含的簽名是一串非常長的大端格式的數字：
任何人都可以向我們發送這些字節，但我們為什么要信任這個簽名?為了解釋這個問題，我們首先要回顧一些重要的數學知識：
RSA加密算法的基礎介紹
人人常常會問，編程和數學之間有什么聯系?證書就為數學在編程領域的應用提供了一個實際的例子。Amazon的服務器告訴我們需要使用RSA算法來校驗證書簽名。什么又是RSA算法呢?RSA算法是由麻省理工(MIT)的Ron Rivest、Adi Shamirh和Len Adleman(RSA命名各取了三人名字中的首字母)三人于上世紀70年代創建的。三位天才的學者結合了2000多年數學史上的精華，發明了這種簡潔高效的算法：
選取兩個較大的初值p和q，相乘得n;n = p*q 接下來選取一個較小的數作為加密指數e，d作為解密指數是e的倒數。在加密的過程中，n和e是公開信息，解密密鑰d則是最高機密。至于p和q，你可以將他們公開，也可以作為機密保管。但是一定要記住，e和d是互為倒數的兩個數。
假設你現在有一段信息M(轉換成數字)，將其加密只需要進行運算：C ≡ Me (mod n)
這個公式表示M的e次冪，mod n表示除以n取余數。當這段密文的接受者知道解密指數d的時候就可以將密文進行還原：Cd ≡ (Me)d ≡ Me*d ≡ M1 ≡ M (mod n)
有趣的是，解密指數d的持有者還可以將信息M進行用解密指數d進行加密：Md ≡ S (mod n)
加密者將S、M、e、n公開之后，任何人都可以獲得這段信息的原文：Se ≡ (Md)e ≡ Md*e ≡ Me*d ≡ M1 ≡ M (mod n)
如同RSA的公共密鑰加密算法經常被稱之為非對稱算法，因為加密密鑰(在我們的例子中為e)和解密密鑰(在我們的例子中是d)并不對稱。取余運算的過程也不像我們平常接觸的運算(諸如對數運算)那樣簡單。RSA加密算法的神奇之處在于你可以非常快速的進行數據的加密運算，即 ，但是如果沒有解密密碼d，你將很難破解出密碼，即運算 將不可能實現。正如我們所看到的，通過對n進行因式分解而得到p和q，再推斷出解密密鑰d的過程難于上青天。
簽名驗證
在使用RSA加密算法的時候，最重要的一條就是要確保任何涉及到的數字都要足夠復雜才能保證不被現有的計算方法所破解。這些數字要多復雜呢?Amazon.com的服務器是利用“VeriSign Class 3 Secure Server CA”來對證書進行簽名的。從證書中，我們可以看到這個VeriSign(電子簽名校驗器，也稱威瑞信公司)的系數n有2048位二進制數構成，換算成十進制足足有617位數字：
1890572922 9464742433 9498401781 6528521078 8629616064 3051642608 4317020197 7241822595 6075980039 8371048211 4887504542 4200635317 0422636532 2091550579 0341204005 1169453804 7325464426 0479594122 4167270607 6731441028 3698615569 9947933786 3789783838 5829991518 1037601365 0218058341 7944190228 0926880299 3425241541 4300090021 1055372661 2125414429 9349272172 5333752665 6605550620 5558450610 3253786958 8361121949 2417723618 5199653627 5260212221 0847786057 9342235500 9443918198 9038906234 1550747726 8041766919 1500918876 1961879460 3091993360 6376719337 6644159792 1249204891 7079005527 7689341573 9395596650 5484628101 0469658502 1566385762 0175231997 6268718746 7514321
(如果你想要對這一大串數字進行分解因式獲得p和q，那就祝你好運!順便一提，如果你真的計算出了p和q，那你就破解了Amazon.com數字簽名證書了!)
這個VeriSign的加密密鑰e是 。當然，他們將解密密鑰d保管得十分嚴密，通常是在擁有視網膜掃描和荷槍實彈的警衛守護的機房當中。在簽名之前，VeriSign會根據相關約定的技術文檔，對Amazon.com證書上所提供的信息進行校驗。一旦證書信息符合相關要求，VeriSign會利用SHA-1哈希算法獲取證書的哈希值(hash)，并對其進行聲明。在Wireshark中，完整的證書信息會顯示在“signedCertificate”(已簽名證書)中：
這里應該是軟件的用詞不當，因為這一段實際上是指那些即將被簽名的信息，而不是指那些已經包含了簽名的信息。
實際上經過簽名的信息S，在Wireshark中被稱之為“encrypted”(密文)。我們將S的e次冪除以n取余數(即公式： )就能計算出被加密的原文，其十六進制如下：
0001FFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFF00302130 0906052B0E03021A05000414C19F8786 871775C60EFE0542 E4C2167C830539DB
根據PKCS#1 v1.5標準(譯者注：The Public-Key Cryptography Standards (PKCS)是由美國RSA數據安全公司及其合作伙伴制定的一組公鑰密碼學標準)規定：“第一個字節是00，這樣就可以保證加密塊在被轉換為整數的時候比其加密參數要小。”第二個字節為01，表示了這是一個私有密鑰操作(數字簽名就是私有密鑰操作的一種)。后面緊接著的一連串的FF字節是為了填充數據，使得這一串數字變得足夠大(加大黑客惡意破解的難度)。填充數字以一個00字節結束。緊接著的30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14這些字節是PKCS#1 v2.1標準中用于說明這段哈希值是通過SHA-1算法計算而出的。最后的20字節是SHA-1算法所計算出來的哈希值，即對未加密信息的摘要描述。(譯者注：原文中這里使用了帶引號的signedCertificate，根據作者前文描述，這應該是Wireshark軟件的bug，實際上應指的是未被加密的信息。)
因為這段信息的格式正確，且最后的哈希值與我們獨立計算出來的校驗一致，所以我們可以斷定，這一定是知道“VeriSign Class 3 Secure Server CA”的解密密鑰d的人對它進行了簽名。而世界上只有VeriSign公司才知道這串密鑰。
當然了，我們也可以重復驗證這個“VeriSign Class 3 Secure Server CA”的證書的確是通過VeriSign公司的“第三類公私證書認證(Class 3 Public Primary Certification Authority)”進行簽名的。
但是，即便是這樣，我們為什么要信任VeriSign公司?整個的信任鏈條就此斷掉了。
由圖可以看到，“VeriSign Class 3 Secure Server CA”對Amazon.com進行了簽名，而“VeriSign Class 3 Public Primary Certification Authority”對“VeriSign Class 3 Secure Server CA”進行了簽名，但是最頂部的“VeriSign Class 3 Public Primary Certification Authority”則對自己進行了簽名。這是因為，這個證書自從NSS(網絡安全服務)庫中的certdata.txt 升級到1.4版之后就作為“受信任的根證書頒發機構”(譯者注：參照微軟官方翻譯)被編譯到了Mozilla產品中(火狐瀏覽器)。這段信息是由網景公司的Robert Relyea于2000年9月6日提交的，并隨附以下注釋：
“由僅存的NSS編譯了框架。包含一個在線的certdata.txt文檔，其中包含了我們受信的跟證書頒發機構(一旦我們獲得了其他受信機構的許可會陸續將他們添加進去)”。
這個舉動有著相當長遠的影響，因為這些證書的有效日期是從1996年1月28日到2028年1月1日。
肯·湯普遜(Ken Thompson)在他的《對深信不疑的信任》(譯者注：Reflections on Trusting Trust是肯湯普遜1983年獲得圖靈獎時的演說)的演說中解釋的很好：你最終還是要絕對信任某一人，在這個問題上沒有第二條路可走。在本文的例子中，我們就毫無保留的信任Robert Relyea做了一個正確的決定。我們同樣希望Mozilla在自己軟件中加入“受信任根證書頒發機構”這種行為也是合理的吧。
這里需要注意的是：這一系列的證書和簽名只是用來形成一個信任鏈。在公共互聯網上，VeriSign的根證書被火狐瀏覽器完全信任的時間遠早于你接觸互聯網。在一個公司中，你可以創建自己的受信任的根證書頒發機構并把它安裝到任何人的計算機中。
相對的，你也可以購買VeriSign公司的業務，降低整個證書信任鏈的信任風險。通過第三方的認證機構(在這個例子里是VeriSign公司)我們能利用證書建立起信任關系。如果你有類似于“悄悄話”的安全途徑來傳遞一個秘密的key，那你也可以使用一個預共享密鑰(PSK)來建立起信任關系。諸如TLS-PSK、或者帶有安全遠程密碼(SRP)的TLS擴展包都能讓我們使用預共享密鑰。不行的是，這些擴展包在應用和支持方面遠遠比不上TLS，所以他們有的時候并不實用。另外，這些替代選項需要額外德爾安全途徑進行保密信息的傳輸，這一部分的開銷遠比我們現在正在應用的TLS龐大。換句話說，這也就是我們為什么不應用那些其他途徑構建信任關系的原因。
言歸正傳，我們所需要的最后確認的信息就是在證書上的主機名跟我們預想的是一樣的。Nelson Bolyard在SSL_AuthCertificate 函數中的注釋為我們解釋其中的原因：
“SSL連接的客戶端確認證書正確，并檢查證書中所對應的主機名是否正確，因為這是我們應對中間人攻擊的唯一方式!” (譯者注：中間人攻擊是一種“間接”的入侵攻擊，這種攻擊模式是通過各種技術手段將受入侵者控制的一臺計算機虛擬放置在網絡連接中的兩臺通信計算機之間，這臺計算機就稱為“中間人”。)
/* cert is OK. This is the client side of an SSL connection.
* Now check the name field in the cert against the desired hostname.
* NB: This is our only defense against Man-In-The-Middle (MITM) attacks! */
這樣的檢查是為了防止中間人攻擊：因為我們對整個信任鏈條上的人都采取了完全信任的態度，認為他們并不會進行黑客行為，就像我們的證書中所聲稱它是來自Amazon.com，但是假如他的真實來源并非Amazon.com，那我們可能就有被攻擊的危險。如果攻擊者使用域名污染(DNS cache poisoning)等技術對你的DNS服務器進行篡改，那么你也許會把黑客的網站誤認為是一個安全的受信網站(諸如Amazon.com)，因為地址欄顯示的信息一切正常。這最后一步對證書頒發機構的檢查就是為了防止這樣的事情發生。
隨機密碼串(Pre-Master Secret)
現在我們已經了解了Amazon.com的各項要求，并且知道了公共解密密鑰e和參數n。在通信過程中的任何一方也都知道了這些信息(佐證就是我們通過Wireshark獲得了這些信息)。現在我們所需要做的事情就是生成一串竊密者/攻擊者都不能知道的隨機密碼。這并不像聽上去的那么簡單。早在1996年，研究人員就發現了網景瀏覽器1.1的偽隨機數發生器僅僅利用了三個參數：當天的時間，進程ID和父進程ID。正如研究人員所指出的問題：這些用于生成隨機數的參數并不具有隨機性，而且他們相對來說比較容易被破解。
因為一切都是來源于這三個隨機數參數，所以在1996，利用當時的機器僅需要25秒鐘的時間就可以破解一個SSL通信。找到一種生成真正隨機數的方法是非常困難的，如果你不相信這一點，那就去問問Debian OpenSSL的維護工程師吧。如果隨機數的生成方式遭到破解，那么建立在這之上的一系列安全措施都是毫無意義的。
在Windows操作系統中，用于加密目的隨機數都是利用一個叫做CryptGenRandom的函數生成的。這個函數的哈希表位對超過125個來源的數據進行抽樣!火狐瀏覽器利用CryptGenRandom函數和它自身的函數來構成它自己的偽隨機數發生器。(譯者注：之所以稱之為偽隨機數是因為真正意義上的隨機數算法并不存在，這些函數還是利用大量的時變、量變參數來通過復雜的運算生成相對意義上的隨機數，但是這些數之間還是存在統計學規律的，只是想要找到生成隨機數的過程并不那么容易)。
我們并不會直接利用生成的這48字節的隨機密碼串，但是由于很多重要的信息都是由他計算而來的，所以對隨機密碼串的保密就顯得格外重要。正如我之前所預料到的，火狐瀏覽器對隨機密碼串的保密十分嚴格，所以我不得不編譯了一個用于debug的版本。為了觀察隨機密碼串，我還特地設置了SSLDEBUGFILE和SSLTRACE兩個環境變量。
其中，SSLDEBUGFILE顯示的就是隨機密碼串的值：
1|
|
發表留言請先登錄！
|