01.openssl基礎介紹

本章介紹SSL和OpenSSL庫。 咱們給出一個概述涉及部署圖書館的最大安全風險，並討論如何緩解他們在高層次。 咱們也看看如何使用OpenSSL和Stunnel來保護第三方軟件，例如沒有內置SSL支持的POP服務器。

1.1 Cryptography for the Rest of Us

1.1.1 Goals of Cryptography

有許多不一樣的加密算法，每一個加密算法能夠爲應用程序提供如下一項或多項服務：

Confidentiality (secrecy)
即便數據是經過不安全的介質傳輸的，數據也會被保密。 實際上，這意味着潛在的攻擊者可能會看到實質上「鎖定」的亂碼數據，可是若是沒有正確的信息，他們就不能解鎖數據。 在傳統的密碼學中，加密（加擾）算法是祕密。 在現代密碼學中，這是不可行的。 算法是公開的，加密和解密過程當中使用密鑰。 惟一須要保密的是關鍵。 另外，正如咱們稍後將要演示的，常見的狀況是否是全部的密鑰都須要保密。

Integrity (anti-tampering)
數據完整性背後的基本思想是，一個數據的接收者應該有一種方法來肯定是否在一段時間內進行了修改。 例如，可使用完整性檢查來確保經過線路發送的數據在傳輸過程當中不被修改。 大量的着名校驗和存在，能夠檢測甚至糾正簡單的錯誤。 然而，這樣的校驗和在檢測數據的熟練的有意修改方面不好。 若是正確使用，幾個加密校驗和不具備這些缺點。 請注意，加密不能確保數據的完整性。 整個類的加密算法都受到「翻轉」攻擊。 也就是說，攻擊者能夠改變經過改變相應的加密位數據來實現一位數據的實際值。

Authentication （認證）
密碼學能夠幫助創建身份認證的目的。

Non-repudiation
密碼學可使鮑勃證實他從愛麗絲收到的消息實際上來自愛麗絲。 當Alice向Bob發送這樣一條消息時，Alice本質上能夠被追究責任，由於她不可否認（否定）她發送的消息。 在現實世界中，你必須假設攻擊者不會損害特定的加密密鑰。 SSL協議不支持不能否認性，但經過使用數字簽名很容易添加。

Snooping (passive eavesdropping)
攻擊者會在網絡流量經過並記錄有趣的數據時觀察網絡流量信用卡信息。

Tampering（篡改）
攻擊者監視網絡流量並惡意更改傳輸中的數據（例如，攻擊者可能會修改電子郵件的內容）

Spoofing（欺騙）
攻擊者僞造網絡數據，彷佛來自不一樣於實際來自的網絡地址。 這種攻擊能夠用來阻止基於主機信息（例如，IP地址）進行認證的系統。

Hijacking(劫持)
一旦合法用戶認證，欺騙攻擊就能夠用來「劫持」鏈接。

Capture-replay（重播）
在某些狀況下，攻擊者能夠對網絡交易進行記錄和重放，從而產生不良影響。例如，假設您在出售單個股票的同時價格很高。 若是網絡協議設計得不穩當，攻擊者可能會記錄該協議交易，而後在股票價格下跌的時候重播，直到你全部的股票都沒有了

1.1.2 Cryptographic Algorithms

本書討論了五種密碼算法：對稱密鑰加密，公鑰加密，加密散列函數，消息認證代碼和數字簽名。

1.1.2.1 Symmetric key encryption
對稱密鑰算法使用單個密鑰加密和解密數據。 如圖1-1所示，密鑰和明文消息被傳遞給密碼算法，產生密文。結果能夠經過不安全的媒體發送，只容許有原始密鑰的接收方解密消息，完成 經過將密文和密鑰傳遞給解密算法。 顯然，這項計劃的關鍵必須保密。

對稱密鑰算法的主要缺點是密鑰必須始終保密。 特別是，交換密鑰可能很困難，由於一般您想要在您嘗試使用加密保護的介質上交換密鑰。 在發送密鑰在使用以前清除，在攻擊者甚至尚未記錄密鑰的狀況下，可能會形成攻擊者的可能性開始發送數據。

密鑰分發問題的一個解決方案是使用密碼密鑰交換協議.OpenSSL爲此提供了Diffie-Hellman協議，它容許密鑰協商而不實際泄露網絡上的密鑰。 可是，Diffie-Hellman並不能保證與你交換密鑰的一方的身份。 某種形式的身份驗證機制對於確保您不會意外與攻擊者交換密鑰是必要的。

目前，Triple DES（一般是3DES，或者有時是DES3）是最保守的對稱密碼。 它被普遍使用，可是，新的高級加密標準AES將最終取代它做爲最普遍使用的密碼。 AES確實比3DES更快，可是3DES已經有了更長的時間，所以對於超偏執的人來講是更保守的選擇。 值得一提的是，RC4獲得了現有客戶端和服務器的普遍支持。 它比3DES快，但難以正確設置（不用擔憂，SSL使用RC4）。 爲了與既不支持AES也不支持3DES的現有軟件兼容，RC4特別感興趣。 咱們不建議在沒有充分理由的狀況下支持其餘算法。 對於感興趣的，咱們在第6章討論密碼選擇。

安全性與密鑰的長度有關。 更長的鑰匙長度固然更好。 爲確保安全性，您只能使用80位或更高的密鑰長度。 雖然64位密鑰多是安全的，但它們可能不會很長，而80位密鑰在至少幾年內應該是安全的。 AES只支持128位和更高的密鑰，而3DES則具備固定的112位有效安全性[1]。 在可預見的將來，這兩種方法都應該是安全的，以知足全部的密碼需求。大型密鑰多是沒必要要的。 56位（常規DES）或更少（40位密鑰常見）的密鑰長度太弱; 他們已經證實是能夠經過適量的時間和精力來解決的。

1.1.2.2 Public key encryption
公鑰密碼學提出瞭解決對稱密碼術的關鍵分佈問題的解決方案。 在最流行的公鑰密碼體制中，每一方都有兩個密鑰，一個必須保密（私鑰）和一個能夠自由分配的密鑰（公鑰）。 這兩個鍵有一個特殊的數學關係。 對於Alice使用公鑰加密發送消息給Bob（見圖1-2），Alice必須先擁有Bob的公鑰。 而後，她使用Bob的公鑰加密她的消息，並將其傳遞。 一旦加密，只有擁有Bob私鑰的人才能成功解密郵件（但願這只是Bob）

公鑰加密解決了密鑰分發的問題，假設有一些方法能夠找到Bob的公鑰並確保密鑰真的屬於Bob。 在實踐中，公鑰經過一系列稱爲證書的支持信息傳遞，這些證書由可信任的第三方驗證。 一般狀況下，一個可信的第三方是一個對那些但願驗證其證書的人進行研究（如信用檢查）的組織。 SSL使用可信的第三方來解決密鑰分發問題.

公鑰密碼學有一個顯着的缺點，可是對於大消息來講，速度慢得使人難以忍受。 對稱密鑰加密一般能夠快速完成，以加密和解密機器能夠管理的全部網絡流量。 公鑰加密通常受加密速度的限制，而不是進入計算機的帶寬，特別是在須要同時處理多個鏈接的服務器上。

所以，大多數使用公鑰密碼系統（包括SSL）的系統儘量少地使用它。 一般狀況下，公鑰加密用於協商對稱算法的加密密鑰，而後全部進一步的加密都使用對稱算法完成。 所以，公鑰加密算法主要用於密鑰交換協議以及須要不能否認的狀況。

RSA是最流行的公鑰加密算法。 Diffie-Hellman密鑰交換協議基於公鑰技術，能夠經過交換對稱密鑰實現相同的目的，用於執行實際的數據加密和解密。 爲了使公鑰方案有效，一般須要有一個涉及與加密自己分離的可信第三方的認證機制。 大多數狀況下，咱們在下面討論的數字簽名方案提供了必要的認證。

公鑰算法中的密鑰本質上是具備特定屬性的大數字。 所以，公鑰密碼中密鑰的比特長度不能直接與對稱算法相比較。 對於公鑰加密算法，應該使用1024位以上的密鑰來保證合理的安全性。 512位密鑰可能太弱了。 大於2048位的任何內容均可能太慢，而且極可能不會購買更實用的安全性。 最近有人擔憂1,024位密鑰太弱，但在撰寫本文時尚未確切的證據.若是您的密鑰可能須要保護多年，那麼您可能須要繼續使用2,048位鍵。

在爲公鑰算法選擇密鑰長度時，一般還須要選擇對稱密鑰長度。 建議有所不一樣，可是咱們建議您在使用長度小於100位的對稱密鑰時使用1,024位密鑰。 若是您使用的是3DES或128位密鑰，咱們推薦使用2,048位公鑰。 若是您偏執到使用192位密鑰或更高，咱們推薦使用4096位公鑰。

若是您使用的是橢圓曲線加密（ECC），那麼對密鑰長度的要求就會發生變化。這是對公鑰加密技術的一種修改，可使用更快的操做和更小的密鑰來提供相同的安全性。 OpenSSL目前不支持ECC，對於那些但願使用它的人來講，可能會有一些懸而未決的專利問題。 對於對此主題感興趣的開發人員，咱們推薦Michael Rosing（Manning）撰寫的「實現橢圓曲線加密」一書。

1.1.2.3 Cryptographic hash functions and Message Authentication Codes
加密哈希函數本質上是具備特殊屬性的校驗和算法。 您將數據傳遞給哈希函數，並輸出固定大小的校驗和（一般稱爲消息摘要），或者簡稱爲摘要。 將相同的數據傳遞給哈希函數兩次將老是產生相同的結果。 可是，結果沒有提供有關輸入到該功能的數據的信息。 另外，找到兩個產生相同消息摘要的輸入其實是不可能的。 通常來講，當咱們討論這樣的功能時，咱們談論的是單向功能。 也就是說，在任何狀況下，輸出和算法都不可能重構輸入。 固然有可逆的哈希函數，可是咱們在本書的範圍內並不考慮這種狀況。

對於通用的用法，一個最小安全的密碼哈希算法應該有一個摘要是最小安全對稱密鑰算法的兩倍。 MD5和SHA1是最流行的單向加密散列函數。 MD5的摘要長度只有128位，而SHA1是160位。 對於某些用途，MD5的密鑰長度是適合的，對於其餘用戶來講，這是危險的。 爲了安全起見，咱們建議只使用產生160位摘要或更大的加密散列算法，除非您須要支持傳統算法。 另外，因爲部分算法存在一些密碼上的弱點，MD5被普遍認爲是「接近破碎」。 因此，咱們建議您避免在任何新的應用程序中使用MD5。

密碼散列函數已被用於許多用途。 它們常常用做密碼存儲解決方案的一部分。 在這種狀況下，經過在密碼和一些額外的數據上運行散列函數來檢查登陸，並根據存儲的值檢查登陸。 這樣，服務器沒必要存儲實際的密碼，所以即便攻擊者設法獲取密碼數據庫，選擇的密碼也是安全的。

人們喜歡用加密哈希來作的另外一件事就是在發佈軟件的同時發佈它們。 例如，OpenSSL可能會與歸檔的MD5校驗和一塊兒發佈。當您下載歸檔時，還能夠下載校驗和。 而後，您能夠計算歸檔上的校驗和，並查看計算出的校驗和是否與下載的校驗和相匹配。您可能但願若是兩個校驗和匹配，那麼您已經安全地下載了實際發佈的文件，而且沒有獲得一些特洛伊木馬的修改版本 在裏面。 不幸的是，狀況並不是如此，由於沒有涉及的祕密。 攻擊者能夠用修改後的版本替換存檔，並用有效值替換校驗和。 這是可能的，由於消息摘要算法是公開的，沒有祕密信息輸入給它。

若是您與軟件分銷商共享密鑰，則分銷商能夠將存檔與密鑰結合起來，以產生一個攻擊者不該該僞造的消息摘要，由於他不會有這個祕密。 用於使用密鑰散列的方案，即涉及密鑰的散列被稱爲消息認證碼（MAC）。MAC一般用於爲通用數據傳輸提供消息完整性，不管是否加密。 事實上，SSL使用MAC來達到這個目的。

1.1.2.4 Digital signatures
對於許多應用來講，MAC並非很是有用，由於它們須要就共享密鑰達成一致。 可以認證消息而不須要共享祕密將是很好的。 公鑰密碼學使這成爲可能。 若是Alice用她的祕密簽名密鑰簽署消息，則任何人均可以使用她的公鑰來驗證她是否簽署了該消息。 RSA提供數字簽名。 基本上，公鑰和私鑰是能夠互換的。 若是Alice用她的私鑰加密一條消息，任何人均可以解密它。 若是Alice沒有對消息進行加密，則使用她的公鑰解密消息將致使垃圾。

很像公鑰加密，數字簽名很是緩慢。 爲了加快速度，算法通常不會對整個要簽名的消息進行操做。 相反，消息被加密散列，而後消息的散列被簽名。 儘管如此，簽名計劃仍然很昂貴。 爲此，若是發生任何類型的安全密鑰交換，則MAC是優選的。

因爲數字簽名是公鑰加密的一種形式，所以您應該確保使用1024位或更高的密鑰長度來確保安全

1.2 Overview of SSL

SSL是目前應用最普遍的安全協議。 它是安全HTTP（HTTPS）背後的安全協議，所以負責網絡瀏覽器角落的小鎖定。 SSL可以保護經過TCP工做的任何協議。

SSL事務（見圖1-3）從客戶端向服務器發送握手開始。 在服務器的響應中，它發送它的證書。 如前所述，證書是包含與服務器關聯的公鑰和其餘感興趣信息的數據片斷，例如證書全部者，其到期日期以及與服務器關聯的徹底限定的域名[2]

在鏈接過程當中，服務器將使用其私鑰證實其身份，以成功解密客戶端使用服務器公鑰加密的挑戰。 客戶端須要接收正確的未加密數據才能繼續。 所以，服務器的證書能夠保持公開 - 攻擊者須要證書副本以及相關的私鑰，以假裝成已知的服務器

可是，攻擊者老是能夠攔截服務器消息並呈現攻擊者的證書。僞造的證書的數據字段能夠看起來是合法的（例如與服務器關聯的域名和與證書關聯的實體的名稱）。在這種狀況下，攻擊者可能創建到目標服務器的代理鏈接，而後竊聽全部的數據。這樣的攻擊被稱爲「中間人」攻擊，如圖1-4所示。爲了徹底阻止中間人攻擊，客戶端不只要對服務器證書進行完全的驗證，並且還要有一些肯定證書自己是否可信的方法。肯定可信度的一種方法是將有效證書列表硬編碼到客戶端中。這個解決方案的問題是它不可擴展。想象一下，在開始瀏覽網頁以前，須要爲每一個安全的HTTP服務器提供證書，這些服務器可能但願在存儲在網絡瀏覽器中的網絡上使用。

這個問題的實際解決方案是涉及一個可信的第三方，負責保存有效證書的數據庫。 可信的第三方（稱爲認證中心）使用其私鑰對有效的服務器證書進行簽名。 簽名表示認證機構已經對擁有證書的實體進行了背景檢查，

客戶端能夠驗證當局的簽名，假設它在本地擁有認證中心的公鑰。 若是檢查成功，則客戶能夠合理確信證書由可信第三方已知的實體擁有，而後能夠檢查存儲在證書中的其餘信息的有效性，例如證書是否過時。

雖然不多，服務器也能夠從客戶端請求證書。 在證書驗證完成以前，客戶端和服務器就要使用哪些加密算法達成一致。 在證書驗證以後，客戶端和服務器使用安全密鑰協商協議（使用對稱密鑰加密算法傳輸數據）就對稱密鑰達成一致。 一旦全部的談判都完成，客戶端和服務器能夠隨意交換數據。

SSL協議的細節稍微複雜一些。 消息認證碼普遍用於確保數據完整性。 另外，在證書驗證期間，一方能夠去證書吊銷列表（CRL）的證書頒發機構，以確保看起來有效的證書實際上沒有被盜取

咱們不會深刻到SSL協議（或其後繼者，TLS）的細節。 就咱們的目的而言，咱們能夠把全部其餘事情看成黑箱。 再一次，若是您對這些細節感興趣，咱們推薦Eric Rescorla的書籍SSL和TLS。

1.3 Problems with SSL

SSL是一個很好的協議。 像許多工具同樣，它是有效的在誰知道如何使用它的人的手中，但容易被誤用。 人們在部署SSL時會遇到許多陷阱，其中大部分能夠經過一些工做來避免。

1.3.1 Efficiency
SSL比傳統的不安全的TCP / IP鏈接要慢不少。 這個問題是提供足夠安全性的直接結果。 當一個新的SSL會話正在創建時，服務器和客戶端交換了至關數量的信息，這些信息是他們相互驗證和贊成用於會話的密鑰所必需的。 最初的握手包括大量使用公鑰加密，正如咱們已經提到的那樣，這種加密很慢。 這也是使用SSL時最大的放緩。 在當前的高端我的電腦硬件上，OpenSSL在實際工做負載下努力實現每秒100個鏈接。

一旦初始握手完成並創建會話，開銷就會大大下降，但仍然有一部分與不安全的TCP / IP鏈接相比。 具體來講，更多的數據傳輸比正常。 數據以包的形式傳輸，包含SSL協議所需的信息以及正在使用的對稱密碼所需的任何填充。 固然，也有加密和解密數據的開銷，但好消息是對稱密碼正在使用，因此一般不是瓶頸。 對稱密碼的效率能夠根據所使用的算法和密鑰的強度而有很大的變化。 然而，即便是最慢的算法也是有效的，因此它們幾乎不是瓶頸。

因爲公鑰密碼學效率低下，許多人在乎識到沒法處理足夠大的負載時決定不使用SSL。 有些人根本就沒有安全感，這顯然不是一個好主意。 其餘人試圖設計本身的協議來彌補。 這是一個糟糕的主意，由於有不少不明顯的缺陷可讓你感到困惑。 不熟練的密碼員設計的協議不可避免地會有問題。 SSL的設計確實考慮了效率; 它只是不肯意犧牲安全來提升速度。 你應該懷疑使用更高效的協議。

有辦法在不放棄協議的狀況下改善這個問題。 SSL確實支持鏈接恢復機制，這樣在斷開鏈接以後不久就能夠從新鏈接的客戶端能夠這樣作，而不會產生創建鏈接的所有開銷。 雖然這對於HTTP頗有用，但對於其餘協議一般不起做用。

1.3.1.1 Cryptographic acceleration hardware
加速SSL的一種常見方法是使用硬件加速。 許多供應商提供PCI卡，能夠從您的處理器卸載加密操做的負擔，OpenSSL支持其中大部分。 咱們討論使用硬件加速的具體細節

1.3.1.2 Load balancing
用於管理SSL效率問題的另外一個受歡迎的選擇是負載均衡，即簡單地在多個機器之間透明地分配鏈接，使得該機器羣體出於全部意圖和目的而做爲單個機器出如今外部世界。 這可能比加速卡更具成本效益的解決方案，特別是若是您已經有硬件躺在附近。 然而，負載均衡一般須要更多的工做來確保持久數據隨時可用於後端的全部服務器。 負載平衡的另外一個問題是許多解決方案將新的鏈接路由到任意的機器，這能夠消除鏈接恢復的大部分好處，由於在從新鏈接期間不多的客戶機實際上將鏈接到原始機器。

一種簡單的負載均衡機制是循環DNS，其中多個IP地址被分配給單個DNS名稱。 爲了響應DNS查找，DNS服務器在發送相同地址兩次以前，遍歷該DNS名稱的全部地址。 這是一個流行的解決方案，由於它是低成本的，不須要特殊的硬件。 鏈接恢復通常適用於這個解決方案，由於機器每每會保留DNS結果的短時間記憶.

硬件負載均衡器的價格和功能各不相同。 那些可以記住外部機器並經過多個鏈接將它們映射到同一臺內部機器的人每每會更昂貴，並且對於SSL更有效

1.3.2 Keys in the Clear
在典型的SSL安裝中，服務器維護憑據，以便客戶端能夠驗證服務器。 除了在鏈接時提供的證書以外，服務器還維護一個私鑰，這對於證明提供證書的服務器實際上呈現本身的證書是必需的。

該私鑰須要住在服務器上的某個地方。 最安全的解決方案是使用加密加速硬件。 這些設備中的大多數能夠生成和存儲密鑰資料，而且另外防止私鑰被入侵到機器的攻擊者訪問。 爲此，私鑰僅在卡上使用，除特殊狀況外不容許關閉。

在硬件解決方案不可行的狀況下，沒有絕對的辦法來保護得到root訪問權限的攻擊者的私鑰，由於在處理新的鏈接時，密鑰必須至少在內存中不加密。[4] 若是攻擊者擁有root權限，她一般能夠將一個調試器附加到服務器進程中，並提取未加密的密鑰。

在這些狀況下有兩種選擇。 首先，您能夠簡單地將密鑰保存在磁盤上。 這是最簡單的解決方案，可是若是他具備物理訪問權限，攻擊者的工做也會變得簡單，由於他能夠關閉計算機並拔出磁盤，或者直接重啓到單用戶模式。 或者，您可使用密碼在磁盤上保存密鑰，管理員在SSL服務器啓動時必須鍵入該密碼。 在這種狀況下，密鑰只能在服務器進程的地址空間中未加密，所以對於能夠關閉機器並直接訪問磁盤的用戶是不可用的。

此外，許多襲擊者正在尋找低窪的水果，即便他們有這樣的技能，他們也不可能追隨他們。 這個解決方案的不利之處在於無人蔘與重啓是不可能的，由於不管什麼時候機器重啓（或者SSL服務器進程崩潰），都必須輸入密碼，這一般不太實際，特別是在無人環境中。 明顯存放鑰匙顯然不存在這個問題。

不管哪一種狀況，最好的防護措施是使用最好的鎖定技術（包括物理鎖定技術）來保護主機和網絡。 這樣的解決方案超出了本書的範圍。

若是服務器的私鑰被泄露，究竟意味着什麼？ 最明顯的結果是攻擊者能夠假裝成服務器，咱們將在下一節討論這個問題。 另外一個結果（可能不那麼明顯）是全部使用密鑰的通訊均可能被解密。 若是攻擊者可以泄露私鑰，攻擊者也可能記錄了之前的通訊。 解決這個問題的方法是使用臨時密鑰。 這意味着在建立新的SSL會話時會生成臨時密鑰對。 而後這被用於密鑰交換，並隨後被銷燬。 經過使用臨時密鑰，能夠實現前向保密，這意味着若是一個密鑰受到攻擊，用之前的密鑰加密的消息將不會受到攻擊[5]。 咱們將在第5章更詳細地討論短暫的密鑰和前向保密。

1.3.3 Bad Server Credentials
服務器的私鑰可能被盜。 在這種狀況下，攻擊者一般能夠假裝成服務器而不受懲罰。 此外，認證機構有時也會爲欺騙性地表明本身的人簽署證書，儘管CA作出了努力來驗證全部關於請求證書籤名的一方的重要信息[6]。 例如，在2001年年初，VeriSign簽署了聲稱屬於微軟的證書，但實際上並無。 可是，因爲他們已經由一個知名的認證機構簽名，因此他們對於驗證這些證書籤名的任何人都是真實的。

SSL有一個阻止這些問題的機制：證書吊銷列表。 一旦證書頒發機構得知證書被盜或簽名不當，證書頒發機構會將證書的序列號添加到CRL中。 客戶端能夠訪問CRL並使用CA的證書驗證它們，由於服務器使用其私鑰簽署CRL。

CRL的一個問題是漏洞的窗口可能很大。 一個組織可能須要必定的時間才能意識到私鑰可能已經被盜，並通知CA. 即便發生這種狀況，CA也必須更新其CRL，這一般不會實時發生（所需時間取決於CA）。 而後，一旦CRL被更新，客戶端必須下載它們，以便檢測出現的證書已被撤銷。 在大多數狀況下，客戶端永遠不會下載或更新CRL。 在這種狀況下，被破壞的證書每每會一直受到損害，直至到期。

這種現象有幾個緣由。 首先，CRL每每足夠大，以至須要花費大量時間進行下載，而且本地可能須要至關大的存儲空間，特別是當SSL客戶端是具備有限存儲容量的嵌入式設備時。 RFC 2560中指定的在線證書狀態協議（OCSP）解決了這些問題。 不幸的是，這還不是一個被普遍接受的標準協議，也不會很快成爲現實。 此外，普遍部署的惟一版本存在嚴重的安全問題（請參閱第3章瞭解更多信息）。 OpenSSL僅在0.9.7版本中增長了OCSP支持，甚至不多有CA甚至提供它做爲服務。 其餘權威機構能夠增量更新CRL，只需最少的下載時間，但該解決方案仍然須要客戶端或某種緩存服務器上的空間。

這些解決方案都須要CA的服務器高度可用，若是客戶要有最新的信息。 有些客戶端將部署在不可能鏈接到CA的環境中。 另外，查詢CA的需求會增長鏈接時間的顯着延遲，這對最終用戶是不能容忍的。

因爲圍繞CRL的許多問題，採起一切可行的措施來確保SSL私鑰不被盜用就顯得尤其重要。 您至少應該設置入侵檢測系統來檢測您的私鑰的泄露狀況，以便您能夠快速向CA報告泄密狀況。

雖然SSL協議和TLS的第3版被認爲是至關安全的（若是正確使用的話），[8] SSLv2（第2版）有基本的設計問題，致使後續版本的普遍變化（版本1從未公開部署）。 所以，您不該該支持該協議的版本2，只是爲了確保攻擊者不會啓動致使客戶端和服務器解決協議不安全版本的網絡攻擊。 您只須要攔截鏈接請求併發送響應，使其看起來像v3服務器不存在。 而後客戶端將嘗試使用協議的版本2進行鏈接。

請注意，服務器一般會根據客戶端提供的受支持密碼列表挑選密碼。 咱們建議在可行的狀況下只支持服務器中的強密碼。 在其餘狀況下，確保選擇客戶提供的最強密碼。 咱們將在第5章詳細討論密碼選擇

1.4 What SSL Doesn’t Do Well

1.4.1 Other Transport Layer Protocols
SSL在TCP / IP上運行良好。 可是，對於不是面向鏈接的傳輸層協議（如UDP和IPX），它根本不起做用。 也沒有真正的方法來使這種協議工做，不管是。 對不能保證順序和可靠性的協議的安全加密是一個挑戰，而且超出了SSL的範圍。 咱們在第6章中概述了加密UDP流量的解決方案。

在第10章中，咱們將討論如何使用S / MIME簽名加密的消息。 經過在發送數據以前簽署數據，可使用相同的技術經過SSL發送消息。 或者，能夠簡單地經過SSL鏈接發送S / MIME消息以實現相同的結果。

1.5 Securing Third-Party Software

雖然本書的大部份內容都着重於如何使用OpenSSL API來爲您的應用程序添加安全性，但您一般會但願使用OpenSSL來保護其餘人的應用程序。 已經構建了許多應用程序來支持OpenSSL。 例如，OpenSSH普遍地使用OpenSSL密碼學基礎，而且要求在編譯以前該庫存在。 在這種特殊狀況下，安裝軟件的正常過程將會處理全部的細節，只要你在系統上的一個熟知的地方安裝了一個OpenSSL版本便可。 不然，能夠在配置軟件時明確指定OpenSSL的位置。