ssl弱加密演算法

① HTTPS的前世今生和原理詳解

HTTPS網路：

HTTP是明文傳輸的協議，數據很容易被竊聽和篡改，並且攻擊者很容易冒充客戶端和服務端，HTTPS可以解決這兩個的安全問題。HTTS仍是HTTP協議，只是在HTTP與TCP之間添加了用於加密數據的TSL/SSL協議。很多其它應用層的協議也採用在傳輸層之上添加TSL/SSL協議來保證安全，如FTPS、IMAPS。

加密和解密使用的是同一個密鑰。加密和解密的雙發都需要持有同一個密鑰。常見對稱加密演算法：AES、DES、3DES。

加密和解密使用的是不同的密鑰，加密時使用的密鑰稱為公鑰匙，解密是使用的密鑰稱為私鑰。使用公鑰加密的密文只能用私鑰解開。公鑰可以發布出去使用，但私鑰一定不能泄漏。常見的非對稱加密演算法：RSA、背包演算法、ECC。

數字簽名用於校驗數據是否被篡改，即數據是否和原數據是否一致。
數字簽名包含簽名和驗證兩個運算。數字簽名具有不可抵賴性，簽名驗證正確後就不能否認。
數字簽名一般包含一個自己知道的私鑰和一個公開的公鑰，與傳統的加密不同的是簽名時使用私鑰，驗證簽名是使用公鑰。

1994年Netscape提出了SSL協議並制訂了SSL協議的原始規范，即SSL1.0。但由於SSL1.0使用的是弱加密演算法而受到密碼學界的質疑，所以SSL1.0並沒有公共發布。

SSL1.0之後Netscape對SLL協議規范進行了重大改近，並在1995年發布 SSL2.0協議 。雖然SSL2.0版本被認為是一個相當強大且健壯的協議，但仍存在一些易受攻擊的漏洞，所以並沒有得到廣泛的使用。

由於SSL2.0的安全問題，Netscape聯合哈佛的Paul Kocher等人重新設計了SSL協議，並在1996年發布，即SSL3.0版本，該版本較2.0版本有較大的差別。 SSL 3.0協議 獲得了互聯網廣泛認可和支持。

隨著互聯網的飛速發展，網路安全越來越重要，業界非常迫切的需要一個標準的安全協議，於是IETE接手了SSL協議，並將其更名為 TSL（Transport Layer Security Protocol，安全傳輸層協議 ，並在1999年發布了TSL1.0版本。
不過TSL1.0於SSL3.0差別並不大（TLS 1.0 內部的協議版本號其實是3.1）。
雖然TSL是SSL的升級，但一些稱呼上還存在混淆，所以大家通常將二者統稱為SSL/TLS協議。

TSL1.1 於2006年發布，主要是修復了一些漏洞。

TSL1.2於2008年發布，1.2版本主要移除了一些老舊的加密套件，並引入了 AEAD 加密模式。1.2版本是目前應用最廣泛的版本。

TSL1.3 於2018年發布。1.3版本在2014年提出，經4年的反復修改直到第28個草案才於2018年正式納入標准。
1.3版本相較1.2版本有很大的改動，即增強了安全性也也大大提升了訪問速度。主要有以下改動：

在公網通訊時想要保證通信信道的安全，目前來看只有將通信的數據進行加密後可防止竊聽、冒充和篡改。

防止竊聽：
數據加密後傳輸的就是加密後的密文，這些密文即使被竊聽了但在沒有解密的密鑰的情況下是得不到真正的內容的。

防冒充和篡改：
通訊的數據加密後傳輸，在沒有加密用的秘鑰的情況下時無法構造出合法的數據包的，也就無法冒充或篡改數據。

將通信數據加密後傳輸可以解決很多的安全問題，但要實現通信的加密最為關鍵的點在於通信的雙發用於加密的密鑰怎麼協商才能保證密鑰不被泄漏和篡改那？密鑰協商是HTTPS中最大的難點。

通信時使用對稱加密，並且在客戶端請求時直接將對稱加密的密鑰返回給客戶端。
但在安全的信道建立起來之前任何傳輸仍是明文的，使用明文風發密鑰毫無安全性可言，並且由對稱加密使用同一個密鑰，所以第三方在竊聽到密鑰後即可以竊聽和篡改數據也可以冒充客戶端和服務端。 所以直接分發對稱加密的密鑰顯然行不通。

為方便說明這里只看客戶端單向向服務端發送數據的情況，服務端向客戶端發送數據與其類似。
通信時使用非對稱加密，在客戶端請求時將公鑰放回給客戶端。
但返回公鑰時仍然是明文傳輸的，所以公鑰還是很容易就會被泄漏，泄漏了公鑰後，雖然第三方無在沒有密鑰的情況下是沒法竊聽數據或直接冒充服務端，但由於泄漏了公鑰第三方還是可以冒充客戶端或者進行『中間人』攻擊。
所以單純使用非對稱加密也是行不通的。

'中間人』攻擊：

只要通信時使用的密鑰不泄漏，那麼在通信時完全沒必要使用非對稱加密，畢竟對稱加密的效率更高。所以可以在通信正式開始前使用非對稱加密來協商出通信時使用的對稱加密的密鑰，步驟如下：

雖然對稱加密與非對稱加密結合可以使我們或得兩種的優點，但這樣還是無法避免『中間人』攻擊。

DH密鑰協商演算法不會直接交互密鑰，而是交互用於生產密鑰的參數，DH演算法基於當前『無法』對大數進行質數分解來保證即使參數泄漏了，第三方也無法通過參數推導出密鑰。
DH演算法密鑰協商步驟：

通過以上步驟客戶端和服務端就協商出了密鑰s，並且整個過程中沒有傳輸過s。為了防止被破解a和b通常非常大，p 是一個至少 300 位的質數，g一般很小通常是3或者5.
但DH演算法的缺點也很明顯，DH無法防止冒充，還是會受到中間人攻擊。

數字證書（digital certificate），又稱公開密鑰認證（Public key certificate）或身份證書（identity certificate），用來下發公鑰匙和證明公鑰擁有者的身份。

證書由第三機構頒發用來驗證服務提供方的合法性，使用時服務提供方將證書給到客戶端，客戶端通過特定的機制驗證書的合法性，從而信任提供證書的服務端和證書中的公鑰。

數字證書以文件的形式存在，證書文件中包含了公鑰信息、擁有者身份信息（主體）、以及數字證書認證機構（發行者）對數字證書自身的數字簽名，證書的數字簽名用來保證證書沒有被篡改。

一般我們向CA申請證書時不用我們我們提供公鑰和私鑰，CA會給我們分配一個密鑰對，並將公鑰寫到證書中，然後將證書和私鑰給我們。

證書有統一的標准，其合法性（證書是否過期、數字簽名是否有效、頒發的機構是否可信）通過一定的程序按標准來進行驗證，如瀏覽器會保證HTTPS證書是否是合法的，linux下openSSL庫提供了證書驗證功能。

核對證書後若證書可信，就可以使用證書中的公鑰對數據進行加密與證書的擁有者進行通信。

HTTPS的證書在擴展欄位中包含了域名相關的信息，所以HTTPS的證書在申請的時候CA會嚴格的校驗申請的機構或個人是否真的擁有這個域名。

數字證書認證機構（英語：Certificate Authority，縮寫為CA）。證書標準是公開的任何人都可以去製作證書，但自己製作的證書是不受信任的，只有權威的CA機構頒發的證書才被信任。

權威的CA證書審核和部署流程嚴苛而繁雜，所以權威的根證書的有效期一般在幾十年內。
也只有權威的CA的根證書會被各大操作系統支持，將其預制與操作系統內。

證書一般遵循X.509規范，主要包含以下內容：

CA生成的證書包含以上內容和一些擴展欄位外，還包含CA使用自己的私鑰對這些內容進行加密後的密文。在驗證證書時使用CA的根證書對秘文進行驗證，從而判斷證書是否是合法的。

權威結構使用根證書來簽發二級CA證書，二級CA證書可以給其它服務簽發證書。但不是所有證書都可以繼續簽發新的證書，證書使用基礎約束擴展來限制證書的簽發，我們普通申請到證書基礎約束擴展都是False的。查看根證書的基本約束可以看到證書頒發機構為『是』。

根證書並不直接簽發服務的證書，只要基於以下兩點：

上一級證書對下一級證書進行簽名，簽名值包含在證書中，可以使用上一級證書中的公鑰來驗證下一級證書的簽名值。根證書的簽名是自己簽的，並且驗證簽名的公鑰包含在根證書中。

完整的證書連的關系應該有伺服器放回，但有的並沒有返回，對於沒有放回完整證書連的證書，證書中的擴展欄位CA 密鑰標識符( Authority Key Identifier)記錄了證書的上一個證書，通過該欄位獲取到上一級中間證書，再從中間證書的該欄位中繼續向上查找，直到根證書。
服務端最好可以返回證書連，這樣可以避免瀏覽器自己去查找，提示握手速度。伺服器返回的證書鏈並不包含根證書，根證書預至與操作系統內部。

在linux中openssl庫會集成根證書。openssl的根證書的存放路徑通過『openssl version -a』查看。

校驗證書時先根據證書鏈逐級校驗證書的簽名，簽名校驗的最關鍵的在根證書。根證書預至於操作系統中，CA要將自己的證書預至與各個系統中是非常困難的，所以預支與系統中的根證書是可信的。

回顧一下對於HTTPS的證書來說申請的時候CA會嚴苛的驗證，保證這個域名是屬於申請這個證書的機構的。這樣攻擊者或許可以偽造一個改域名的證書，但偽造的證書的根證書在系統中並不會存在，所以偽造的證書是不會被信任的。這樣通過證書鏈的校驗就可以有效的防止服務端被『冒充』。

經過上面證書數字簽名驗證只是驗證了證書確實是合法的證書，後還要驗證證書的有效性，有效性驗證主要包括以下欄位：

驗證合法的證書也可能由於種種原因被吊銷，如證書的私鑰泄漏了、證書錯發了等，為了驗證證書是否有效引入了證書吊銷機制。

OSCP是證書提供方提供的證書驗證介面，用戶通過調用OSCP介面驗證證書是否被吊銷了。
但OCSP服務可能因為策略或服務故障導致無法訪問，這時一般瀏覽器會選擇信任證書，畢竟證書被吊銷的情況只是極少數。也有部分CA將OCSP失敗後的策略寫到證書的擴展欄位中，用用戶根據擴展欄位去做處理。
OSCP方式有自己明顯的缺陷，為了驗證證書而請求OSCP的同時也將自己在什麼時候訪問了什麼服務也告訴了CA，CA利用我們的訪問數據作惡咋辦，還有OCSP的介面很慢的話不就拖慢了我們服務的相應數獨。為了解決這兩個問題各大CA廠商聯手推出了CRL方案。

CRL方案是將被吊銷的證書列表定期拉去到本機，一般是幾天拉取一次。在校驗證書時去本機列表中查找。
CA會在證書的擴展欄位中寫入CRL更新的地址：

CRL也有自己明顯的確定，首先CRL是定期拉取的不能保證實時生效，然後CRL的列表一般很大可能達到數M。

CRLSet是chrome自建自用的解決方案。google覺得CRL更新太慢了，每個CA都有自己的CRL並且CRL內容也太多了。於是自己搞了一個CRLSet，將各大CA被吊銷的高風險證書添加到CRLSet中，chrome在校驗證書時可以去自己CRLSet中校驗。
CRLSet只有各個CA吊銷的證書的部分，大概包含所有吊銷證書的2%。
CRLSet的更新相對快一些，最慢幾個小時就會從各個CA中更新一次，CRLSet可以用在需要緊急吊銷證書的情況下讓吊銷快速生效。

CRLSet提供了 https://github.com/agl/crlset-tools 工具來拉取和校驗證書是否在CRLSet中。

可以在 chrome://components/ 中更新chrome的CRLSet

客戶端向服務端發送hello請求，裡麵包含了客戶端SSL/TSL的版本、支持的加密套件和一個隨機數Random1

服務端收到客戶端的hello後，根據客服端支持的加密套件和自己支持的加密套件選擇出後面使用的加密和散列套件並返回給客戶端，同時返回的還有服務端生產的一個隨機數 Random2

服務端向客戶端返回自己的證書，客戶端收到證書後通過校驗證書來信任服務端，並從證書中獲取到證書中的公鑰。

服務端在返回證書後會立即向客戶端發送該請求。不過該請求不是必須的，只有選擇的加密套件需要額外的參數是才會發送該請求交互參數。
如果密鑰協議商演算法是DH演算法，那麼DH的參數就在該請求中返回給客戶端，DH演算法有以下幾種：DHE_DSS、DHE_RSA、ECDHE_ECDSAECDHE_RSA
dh演算法會返回dh的參數p、g、dh的公鑰和公鑰的簽名，公鑰即g^b mod p，b為服務端的隨機數

這里g就是0X03，p就是0X0017。

服務端在發送完上述信息後，就會立馬發送Server Hello Done，來告知客戶端服務端的相關信息已經發送完畢，就等客戶端開始做密鑰協商了。
客戶端在收到該消息後就開始驗證證書，協商密鑰等工作。

在接受到伺服器的Server Hello Done信息之後，客戶端會計數出預備主密鑰，並將其返回給服務端。

如果使用的是RSA/ECDSA演算法，那麼發送的就是預備主密鑰。
如果使用的是DH演算法，那麼發送的就是通過之前的參數計數出來的公鑰匙，即B（ g^b mod p）服務端在收到B後通過 B ^ a mod p得到第三個隨機數。而客戶端已經通過s = A b mod 得到了s。

到了這里服務端和客戶端已經得到了三個隨機數，通過之前協商好的加密演算法使用這個三個隨機數就得到一個對稱加密的密鑰，後面通信時就使用該密鑰。

該請求用於通知對方已經計數出通信用的密鑰，接下來的通信都使用該密鑰進行。服務端和客戶端都會發出該請求，一般是服務端先發出。

在完成上述步驟以後，雙發都會發送一個Finished請求給對方，Finished的數據是通過協商好的密鑰加密的，以此來驗證之前協商好的密鑰、協議版本是否是有效的。

參考資料：

② 什麼是SSL加密，什麼是TLS加密

SSL加密的英文全稱是Secure Socket Layer，翻譯過來就是安全套接層。

它是在傳輸通信協議（TCP/IP）上實現的一種網路安全協議，廣泛支持各種類型的網路，並同時提供三種網路基本安全服務，而且這三種服務都是使用公開密鑰技術。

TLS加密的英文全稱是Transport Layer Security，翻譯過來就是安全傳輸層協議。

TLS是用於在兩個通信應用程序之間，為通信提供保密性和數據完整性。這個協議一共有兩層，分別是記錄協議和握手協議。通過這個協議可以對網站、網路傳真、電子郵件等數據傳輸進行加密、保密。

(2)ssl弱加密演算法擴展閱讀：

1、SSL

SSL協議優勢

SSL協議的優勢在於它是與應用層協議獨立無關的。

高層的應用層協議（例如：HTTP、FTP、Telnet等等）能透明的建立於SSL協議之上。SSL協議在應用層協議通信之前就已經完成加密演算法、通信密鑰的協商以及伺服器認證工作。在此之後應用層協議所傳送的數據都會被加密，從而保證通信的私密性。

SSL體系結構

SSL被設計成使用TCP來提供一種可靠的端到端的安全服務，不是單個協議，而是二層協議。

低層是SSL記錄層，用於封裝不同的上層協議，另一層是被封裝的協議，即SSL握手協議，它可以讓伺服器和客戶機在傳輸應用數據之前，協商加密演算法和加密密鑰，客戶機提出自己能夠支持的全部加密演算法，伺服器選擇最適合它的演算法。

2、TLS

優勢

TLS協議的優勢是與高層的應用層協議（如HTTP、FTP、Telnet等）無耦合。

應用層協議能透明地運行在TLS協議之上，由TLS協議進行創建加密通道需要的協商和認證。應用層協議傳送的數據在通過TLS協議時都會被加密，從而保證通信的私密性。

TLS協議是可選的，必須配置客戶端和伺服器才能使用。

主要有兩種方式實現這一目標：一個是使用統一的TLS協議通信埠（例如：用於HTTPS的埠443）；另一個是客戶端請求伺服器連接到TLS時使用特定的協議機制（例如：郵件、新聞協議和STARTTLS）。

演算法

在客戶端和伺服器開始交換TLS所保護的加密信息之前，他們必須安全地交換或協定加密密鑰和加密數據時要使用的密碼。

參考資料來源：網路-SSL安全套接層

參考資料來源：網路-TLS安全傳輸層

③ 什麼是SSL加密，什麼是TLS加密

SSL加密是Netscape公司所提出的安全保密協議，在瀏覽器和Web伺服器之間構造安全通道來進行數據傳輸，SSL運行在TCP/IP層之上、應用層之下，為應用程序提供加密數據通道，它採用了RC4、MD5以及RSA等加密演算法，使用40 位的密鑰，適用於商業信息的加密。

TLS是安全傳輸層協議。安全傳輸層協議（TLS）用於在兩個通信應用程序之間提供保密性和數據完整性。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。較低的層為 TLS 記錄協議，位於某個可靠的傳輸協議上面。

(3)ssl弱加密演算法擴展閱讀：

SSL加密並不保護數據中心本身，而是確保了SSL加密設備的數據中心安全，可以監控企業中來往於數據中心的最終用戶流量。

從某個角度來看，數據中心管理員可以放心將加密裝置放在某個地方，需要使用時再進行應用，數據中心應該會有更合理的方法來應對利用SSL的惡意攻擊，需要找到SSL加密應用的最佳實踐。

TLS協議是可選的，必須配置客戶端和伺服器才能使用。主要有兩種方式實現這一目標：一個是使用統一的TLS協議通信埠（例如：用於HTTPS的埠443）。另一個是客戶端請求伺服器連接到TLS時使用特定的協議機制（例如：郵件、新聞協議和STARTTLS）。

一旦客戶端和伺服器都同意使用TLS協議，他們通過使用一個握手過程協商出一個有狀態的連接以傳輸數據。通過握手，客戶端和伺服器協商各種參數用於創建安全連接。

參考資料來源：網路-SSL加密技術

參考資料來源：網路-TLS

④ 常見的幾種SSL/TLS漏洞及攻擊方式

SSL/TLS漏洞目前還是比較普遍的，首先關閉協議：SSL2、SSL3（比較老的SSL協議）配置完成ATS安全標准就可以避免以下的攻擊了，最新的伺服器環境都不會有一下問題，當然這種漏洞都是自己部署證書沒有配置好導致的。

Export 加密演算法

Export是一種老舊的弱加密演算法，是被美國法律標示為可出口的加密演算法，其限制對稱加密最大強度位數為40位，限制密鑰交換強度為最大512位。這是一個現今被強制丟棄的演算法。

Downgrade（降級攻擊）

降級攻擊是一種對計算機系統或者通信協議的攻擊，在降級攻擊中，攻擊者故意使系統放棄新式、安全性高的工作方式，反而使用為向下兼容而准備的老式、安全性差的工作方式，降級攻擊常被用於中間人攻擊，講加密的通信協議安全性大幅削弱，得以進行原本不可能做到的攻擊。 在現代的回退防禦中，使用單獨的信號套件來指示自願降級行為，需要理解該信號並支持更高協議版本的伺服器來終止協商，該套件是TLS_FALLBACK_SCSV(0x5600)

MITM（中間人攻擊）

MITM(Man-in-the-MiddleAttack) ，是指攻擊者與通訊的兩端分別創建獨立的聯系，並交換其所有收到的數據，使通訊的兩端認為他們正在通過一個私密的連接與對方直接對話，但事實上整個對話都被攻擊者完全控制，在中間人攻擊中，攻擊者可以攔截通訊雙方的通話並插入新的內容。一個中間人攻擊能成功的前提條件是攻擊者能夠將自己偽裝成每個參與會話的終端，並且不被其他終端識破。

BEAST（野獸攻擊）

BEAST(CVE-2011-3389) BEAST是一種明文攻擊，通過從SSL/TLS加密的會話中獲取受害者的COOKIE值（通過進行一次會話劫持攻擊），進而篡改一個加密演算法的 CBC（密碼塊鏈）的模式以實現攻擊目錄，其主要針對TLS1.0和更早版本的協議中的對稱加密演算法CBC模式。

RC4 加密演算法

由於早期的BEAST野獸攻擊而採用的加密演算法，RC4演算法能減輕野獸攻擊的危害，後來隨著客戶端版本升級，有了客戶端緩解方案（Chrome 和 Firefox 提供了緩解方案），野獸攻擊就不是什麼大問題了。同樣這是一個現今被強制丟棄的演算法。

CRIME（罪惡攻擊）

CRIME(CVE-2012-4929)，全稱Compression Ratio Info-leak Made Easy，這是一種因SSL壓縮造成的安全隱患，通過它可竊取啟用數據壓縮特性的HTTPS或SPDY協議傳輸的私密Web Cookie。在成功讀取身份驗證Cookie後，攻擊者可以實行會話劫持和發動進一步攻擊。

SSL 壓縮在下述版本是默認關閉的： nginx 1.1.6及更高/1.0.9及更高（如果使用了 OpenSSL 1.0.0及更高）， nginx 1.3.2及更高/1.2.2及更高（如果使用較舊版本的 OpenSSL）。

如果你使用一個早期版本的 nginx 或 OpenSSL，而且你的發行版沒有向後移植該選項，那麼你需要重新編譯沒有一個 ZLIB 支持的 OpenSSL。這會禁止 OpenSSL 使用 DEFLATE 壓縮方式。如果你禁用了這個，你仍然可以使用常規的 HTML DEFLATE 壓縮。

Heartbleed（心血漏洞）

Heartbleed(CVE-2014-0160) 是一個於2014年4月公布的 OpenSSL 加密庫的漏洞，它是一個被廣泛使用的傳輸層安全（TLS）協議的實現。無論是伺服器端還是客戶端在 TLS 中使用了有缺陷的 OpenSSL，都可以被利用該缺陷。由於它是因 DTLS 心跳擴展（RFC 6520）中的輸入驗證不正確（缺少了邊界檢查）而導致的，所以該漏洞根據「心跳」而命名。這個漏洞是一種緩存區超讀漏洞，它可以讀取到本不應該讀取的數據。如果使用帶缺陷的Openssl版本，無論是伺服器還是客戶端，都可能因此受到攻擊。

POODLE漏洞（捲毛狗攻擊）

2014年10月14號由Google發現的POODLE漏洞，全稱是Padding Oracle On Downloaded Legacy Encryption vulnerability，又被稱為「貴賓犬攻擊」（CVE-2014-3566），POODLE漏洞只對CBC模式的明文進行了身份驗證，但是沒有對填充位元組進行完整性驗證，攻擊者竊取採用SSL3.0版加密通信過程中的內容，對填充位元組修改並且利用預置填充來恢復加密內容，以達到攻擊目的。

TLS POODLE（TLS捲毛狗攻擊）

TLS POODLE(CVE-2014-8730) 該漏洞的原理和POODLE漏洞的原理一致，但不是SSL3協議。由於TLS填充是SSLv3的一個子集，因此可以重新使用針對TLS的POODLE攻擊。TLS對於它的填充格式是非常嚴格的，但是一些TLS實現在解密之後不執行填充結構的檢查。即使使用TLS也不會容易受到POODLE攻擊的影響。

CCS

CCS(CVE-2014-0224) 全稱openssl MITM CCS injection attack，Openssl 0.9.8za之前的版本、1.0.0m之前的以及1.0.1h之前的openssl沒有適當的限制ChangeCipherSpec信息的處理，這允許中間人攻擊者在通信之間使用0長度的主密鑰。

FREAK

FREAK(CVE-2015-0204) 客戶端會在一個全安全強度的RSA握手過程中接受使用弱安全強度的出口RSA密鑰，其中關鍵在於客戶端並沒有允許協商任何出口級別的RSA密碼套件。

Logjam

Logjam(CVE-2015-4000) 使用 Diffie-Hellman 密鑰交換協議的 TLS 連接很容易受到攻擊，尤其是DH密鑰中的公鑰強度小於1024bits。中間人攻擊者可將有漏洞的 TLS 連接降級至使用 512 位元組導出級加密。這種攻擊會影響支持 DHE_EXPORT 密碼的所有伺服器。這個攻擊可通過為兩組弱 Diffie-Hellman 參數預先計算 512 位元組質數完成，特別是 Apache 的 httpd 版本 2.1.5 到 2.4.7，以及 OpenSSL 的所有版本。

DROWN（溺水攻擊/溺亡攻擊）

2016年3月發現的針對TLS的新漏洞攻擊——DROWN（Decrypting RSA with Obsolete and Weakened eNcryption，CVE-2016-0800），也即利用過時的、弱化的一種RSA加密演算法來解密破解TLS協議中被該演算法加密的會話密鑰。 具體說來，DROWN漏洞可以利用過時的SSLv2協議來解密與之共享相同RSA私鑰的TLS協議所保護的流量。 DROWN攻擊依賴於SSLv2協議的設計缺陷以及知名的Bleichenbacher攻擊。

通常檢查以下兩點伺服器的配置

• 伺服器允許SSL2連接，需要將其關閉。

• 私鑰同時用於允許SSL2連接的其他伺服器。例如，Web伺服器和郵件伺服器上使用相同的私鑰和證書，如果郵件伺服器支持SSL2，即使web伺服器不支持SSL2，攻擊者可以利用郵件伺服器來破壞與web伺服器的TLS連接。

Openssl Padding Oracle

Openssl Padding Oracle(CVE-2016-2107) openssl 1.0.1t到openssl 1.0.2h之前沒有考慮某些填充檢查期間的內存分配，這允許遠程攻擊者通過針對AES CBC會話的padding-oracle攻擊來獲取敏感的明文信息。

強制丟棄的演算法

• aNULL 包含了非驗證的 Diffie-Hellman 密鑰交換，這會受到中間人（MITM）攻擊

• eNULL 包含了無加密的演算法（明文）

• EXPORT 是老舊的弱加密演算法，是被美國法律標示為可出口的

• RC4 包含的加密演算法使用了已棄用的 ARCFOUR 演算法

• DES 包含的加密演算法使用了棄用的數據加密標准（DES）

• SSLv2 包含了定義在舊版本 SSL 標准中的所有演算法，現已棄用

• MD5 包含了使用已棄用的 MD5 作為哈希演算法的所有演算法

⑤ 什麼是SSL加密技術

SSL是Netscape公司所提出的安全保密協議，在瀏覽器（如Internet Explorer、Netscape Navigator）和Web伺服器（如Netscape的Netscape Enterprise Server、ColdFusion Server等等）之間構造安全通道來進行數據傳輸，SSL運行在TCP/IP層之上、應用層之下，為應用程序提供加密數據通道，它採用了RC4、MD5以及RSA等加密演算法，使用40 位的密鑰，適用於商業信息的加密。

SSL加密並不保護數據中心本身，而是確保了SSL加密設備的數據中心安全，可以監控企業中來往於數據中心的最終用戶流量。從某個角度來看，數據中心管理員可以放心將加密裝置放在某個地方，需要使用時再進行應用，數據中心應該會有更合理的方法來應對利用SSL的惡意攻擊，需要找到SSL加密應用的最佳實踐。

⑥ 什麼是ssl

ssl加密的方法
關鍵詞： ssl加密的方法
隨著計算機網路技術的發展，方便快捷的互連網使人們漸漸習慣了從Web頁上收發E-mail、購物和
交易，這時Web頁面上需要傳輸重要或敏感的數據，例如用戶的銀行帳戶、密碼等，所以網路安全
就成為現代計算機網路應用急需解決的問題。

現行網上銀行和電子商務等大型的網上交易系統普遍採用HTTP和SSL相結合的方式。伺服器端採用
支持SSL的Web伺服器，用戶端採用支持SSL的瀏覽器實現安全通信。
SSL是Secure Socket Layer（安全套接層協議）的縮寫，可以在Internet上提供秘密性傳輸。
Netscape公司在推出第一個Web瀏覽器的同時，提出了SSL協議標准,目前已有3.0版本。SSL採用公
開密鑰技術。其目標是保證兩個應用間通信的保密性和可靠性,可在伺服器端和用戶端同時實現支
持。目前，利用公開密鑰技術的SSL協議，已成為Internet上保密通訊的工業標准。本文著重在
SSL協議和SSL程序設計兩方面談談作者對SSL的理解。

SSL協議初步介紹
安全套接層協議能使用戶/伺服器應用之間的通信不被攻擊者竊聽，並且始終對伺服器進行認證，
還可選擇對用戶進行認證。SSL協議要求建立在可靠的傳輸層協議(TCP)之上。SSL協議的優勢在於
它是與應用層協議獨立無關的，高層的應用層協議(例如：HTTP，FTP，TELNET等)能透明地建立於
SSL協議之上。SSL協議在應用層協議通信之前就已經完成加密演算法、通信密鑰的協商及伺服器認證
工作。在此之後應用層協議所傳送的數據都會被加密，從而保證通信的私密性。
通過以上敘述，SSL協議提供的安全信道有以下三個特性：
1.數據的保密性
信息加密就是把明碼的輸入文件用加密演算法轉換成加密的文件以實現數據的保密。加密的過程需要
用到密匙來加密數據然後再解密。沒有了密鑰，就無法解開加密的數據。數據加密之後，只有密匙
要用一個安全的方法傳送。加密過的數據可以公開地傳送。
2.數據的一致性
加密也能保證數據的一致性。例如:消息驗證碼（MAC），能夠校驗用戶提供的加密信息，接收者可
以用MAC來校驗加密數據，保證數據在傳輸過程中沒有被篡改過。
3.安全驗證
加密的另外一個用途是用來作為個人的標識，用戶的密匙可以作為他的安全驗證的標識。
SSL是利用公開密鑰的加密技術（RSA）來作為用戶端與伺服器端在傳送機密資料時的加密通訊協定。
目前，大部分的Web 伺服器及瀏覽器都廣泛支持SSL 技術。當瀏覽器試圖連接一個具有SSL認證加
密的伺服器時,就會喚醒一個SSL會話,瀏覽器檢查認證,必須具備下面三個條件:
1）有一個權威機構發放證書，當然可以創建自我簽訂的證書（x509 結構）。
2）證書不能過期。
3）證書是屬於它所連接的伺服器的。
只有全部具備了這三個條件,瀏覽器才能成功完成認證。通過這三個條件,用戶能確認其瀏覽器連接
到正確的伺服器,而不是連接到一些想盜取用戶密碼等重要信息的虛假的伺服器上。
在當今的電子商務中還有一項被廣泛使用的安全協議是SET協議。SET(Secure Electronic Transaction，
安全電子交易)協議是由VISA和MasterCard兩大信用卡公司於1997年5月聯合推出的規范。SET能在電
子交易環節上提供更大的信任度、更完整的交易信息、更高的安全性和更少受欺詐的可能性。SET交
易分三個階段進行:用戶向商家購物並確定支付;商家與銀行核實;銀行向商家支付貨款。每個階段都
涉及到RSA對數據加密，以及RSA數字簽名。使用SET協議，在一次交易中，要完成多次加密與解密操作，
故有很高的安全性，但SET協議比SSL協議復雜，商家和銀行都需要改造系統以實現互操作。
在Linux 下，比較流行支持SSL認證的是OpenSSL伺服器。OpenSSL項目是一個合作的項目，開發一個
健壯的、商業等級的、完整的開放源代碼的工具包，用強大的加密演算法來實現安全的Socket層
（Secure Sockets Layer，SSL v2/v3）和傳輸層的安全性（Transport Layer Security，TLS v1）。
這個項目是由全世界的志願者管理和開發OpenSSL工具包和相關文檔。
如何在Linux下配置OpenSSL伺服器，首先從OpenSSL的主頁（http://www.openssl.org/）上下載
openssl-version.tar.gz軟體包來編譯安裝，與Apache伺服器配合可以建立支持SSL的Web伺服器，
並可以使用自我簽訂的證書做認證，關於如何編譯、安裝OpenSSL伺服器，可以參考一下OpenSSL HOWTO
文檔。

SSL 程序設計初步介紹
SSL 通訊模型為標準的C/S 結構，除了在 TCP 層之上進行傳輸之外，與一般的通訊沒有什麼明顯的區
別。在這里，我們主要介紹如何使用OpenSSL進行安全通訊的程序設計。關於OpenSSL 的一些詳細的信
息請參考OpenSSL的官方主頁 http://www.openssl.org。
在使用OpenSSL前，必須先對OpenSSL 進行初始化，以下的三個函數任選其一:
SSL_library_init(void);
OpenSSL_add_ssl_algorithms();
SSLeay_add_ssl_algorithms();
事實上 後面的兩個函數只是第一個函數的宏。
如果要使用OpenSSL的出錯信息，使用SSL_load_error_strings (void)進行錯誤信息的初始化。以後
可以使用void ERR_print_errors_fp(FILE *fp) 列印SSL的錯誤信息。
一次SSL連接會話一般要先申請一個SSL 環境，基本的過程是：
1. SSL_METHOD* meth = TLSv1_client_method(); 創建本次會話連接所使用的協議，如果是客戶端可
以使用
SSL_METHOD* TLSv1_client_method(void); TLSv1.0 協議
SSL_METHOD* SSLv2_client_method(void); SSLv2 協議
SSL_METHOD* SSLv3_client_method(void); SSLv3 協議
SSL_METHOD* SSLv23_client_method(void); SSLv2/v3 協議
伺服器同樣需要創建本次會話所使用的協議:
SSL_METHOD *TLSv1_server_method(void);
SSL_METHOD *SSLv2_server_method(void);
SSL_METHOD *SSLv3_server_method(void);
SSL_METHOD *SSLv23_server_method(void);
需要注意的是客戶端和伺服器需要使用相同的協議。
2．申請SSL會話的環境 CTX，使用不同的協議進行會話，其環境也是不同的。申請SSL會話環
境的OpenSSL函數是
SSLK_CTX* SSL_CTX_new (SSL_METHOD*); 參數就是前面我們申請的 SSL通訊方式。返回當前
的SSL 連接環境的指針。
然後根據自己的需要設置CTX的屬性，典型的是設置SSL 握手階段證書的驗證方式和載入自己
的證書。
void SSL_CTX_set_verify (SSL_CTX* , int , int* (int, X509_STORE_CTX*) )
設置證書驗證的方式。
第一個參數是當前的CTX 指針，第二個是驗證方式，如果是要驗證對方的話，就使用
SSL_VERIFY_PEER。不需要的話，使用SSL_VERIFY_NONE.一般情況下，客戶端需要驗證對方，而
伺服器不需要。第三個參數是處理驗證的回調函數，如果沒有特殊的需要，使用空指針就可以了。
void SSL_CTX_load_verify_locations(SSL_CTX*, const char* , const char*);
載入證書;
第一個參數同上，參數二是證書文件的名稱，參數三是證書文件的路徑;
int SSL_CTX_use_certificate_file(SSL_CTX *ctx, const char *file, int type);
載入本地的證書;type 指明證書文件的結構類型;失敗返回-1
int SSL_CTX_use_PrivateKey_file(SSL_CTX *ctx, const char *file, int type);
載入自己的私鑰；type 參數指明私鑰文件的結構類型；失敗返回-1
載入了證書和文件之後，就可以驗證私鑰和證書是否相符：
BOOl SSL_CTX_check_private_key (SSL_CTX*);
3．既然SSL 使用TCP 協議，當然需要把SSL attach 到已經連接的套接字上了：
SSL* SSL_new (SSL_CTX*); 申請一個SSL 套節字；
int SSL_set_rfd (SSL*); 綁定只讀套接字
int SSL_set_wfd (SSL*); 綁定只寫套接字
int SSL_set_fd ( SSL*); 綁定讀寫套接字
綁定成功返回 1， 失敗返回0;
4． 接下來就是SSL 握手的動作了
int SSL_connect (SSL*); 失敗返回 -1
5. 握手成功之後，就可以進行通訊了，使用SSL_read 和SS_write 讀寫SSL 套接字代替傳統的
read 、write
int SSL_read (SSL *ssl, char *buf, int num );
int SSL_write (SSL *ssl, char *buf, int num);
如果是伺服器，則使用 SSL_accept 代替傳統的 accept 調用
int SSL_accept(SSL *ssl);
6. 通訊結束，需要釋放前面申請的 SSL資源
int SSL_shutdown(SSL *ssl); 關閉SSL套接字;
void SSL_free (ssl); 釋放SSL套接字;
void SSL_CTX_free (ctx); 釋放SSL環境;
OpenSSL 雖然已經發展到了0.9.96版本，但是它的文檔還很少，甚至連最基本的man 函數手
冊都沒有完成。所以，本文緊緊是講述了使用OpenSSL 進行程序設計的框架。更加詳細的資
料可以參考OpenSSL 的文檔或者 Apache mod_ssl 的文檔。
通過以上的介紹，我想讀者對SSL協議已經有了一定的了解，作者有機會將會繼續給大家介紹
SSL協議的其他方面的內容。

SSL原理解密
本文出自:
http://noc.cstnet.net.cn/
范曉明

RSA公鑰加密在計算機產業中被廣泛使用在認證和加密。可以從RSA Data Security Inc.獲得的RSA公鑰加密許可證。公鑰加密是使用一對非對稱的密碼加密或解密的方法。每一對密碼由公鑰和私鑰組成。公鑰被廣泛發布。私鑰是隱密的，不公開。用公鑰加密的數據只能夠被私鑰解密。反過來，使用私鑰加密的數據只能用公鑰解密。這個非對稱的特性使得公鑰加密很有用。

使用公鑰加密法認證

認證是一個身份認證的過程。在下列例子中包括甲和乙，公鑰加密會非常輕松地校驗身份。符號{數據} key意味著"數據"已經使用密碼加密或解密。假如甲想校驗乙的身份。乙有一對密碼，一個是公開的，另一個是私有的。乙透露給甲他的公鑰。甲產生一個隨機信息發送給乙。甲——〉乙：random-message

乙使用他的私鑰加密消息，返回甲加密後的消息。 乙——〉甲：{random-message}乙的私鑰

甲收到這個消息然後使用乙的以前公開過的公鑰解密。他比較解密後的消息與他原先發給乙的消息。如果它們完全一致，就會知道在與乙說話。任意一個中間人不會知道乙的私鑰，也不能正確加密甲檢查的隨機消息。

除非你清楚知道你加密的消息。用私鑰加密消息，然後發送給其他人不是一個好主意。因為加密值可能被用來對付你，需要注意的是：因為只有你才有私鑰，所以只有你才能加密消息。所以，代替加密甲發來的原始消息，乙創建了一個信息段並且加密。信息段取自隨機消息（random-message）並具有以下有用的特性：

1. 這個信息段難以還原。任何人即使偽裝成乙，也不能從信息段中得到原始消息；

2. 假冒者將發現不同的消息計算出相同的信息段值；

3. 使用信息段，乙能夠保護自己。他計算甲發出的隨機信息段，並且加密結果，並發送加密信息段返回甲。甲能夠計算出相同的信息段並且解密乙的消息認證乙。

這個技術僅僅描繪了數字簽名。通過加密甲產生的隨機消息，乙已經在甲產生的消息簽名。因此我們的認證協議還需要一次加密。一些消息由乙產生：

甲——〉乙：你好，你是乙么?

乙——〉甲：甲，我是乙

{信息段[甲，我是乙] } 乙的私鑰

當你使用這個協議，乙知道他發送給乙的消息，他不介意在上面簽名。他先發送不加密的信息，"甲，我是乙。"，然後發送信息段加密的消息版本。甲可以非常方便地校驗乙就是乙，同時，乙還沒有在他不想要的信息上簽名。

提交公鑰

那麼，乙怎樣以可信的方式提交他的公鑰呢？看看認證協議如下所示：

甲——〉乙：你好

乙——〉甲：嗨，我是乙，乙的公鑰

甲——〉乙：prove it

乙——〉甲：甲，我是乙 {信息段[甲，我是乙] } 乙的私鑰

在這個協議下，任何人都能夠成為"乙"。所有你所要的只是公鑰和私鑰。你發送給甲說你就是乙，這樣你的公鑰就代替了乙的密碼。然後，你發送用你的私鑰加密的消息，證明你的身份。甲卻不能發覺你並不是乙。為了解決這個問題，標准組織已經發明了證書。一個證書有以下的內容：

* 證書的發行者姓名

* 發行證書的組織

* 標題的公鑰

* 郵戳

證書使用發行者的私鑰加密。每一個人都知道證書發行者的公鑰（這樣，每個證書的發行者擁有一個證書）。證書是一個把公鑰與姓名綁定的協議。通過使用證書技術，每一個人都可以檢查乙的證書，判斷是否被假冒。假設乙控制好他的私鑰，並且他確實是得到證書的乙，就萬事大吉了。

這些是修訂後的協議：

甲——〉乙：你好

乙——〉甲：嗨，我是乙，乙的校驗

甲——〉乙：prove it

乙——〉甲：甲，我是乙 {信息段[甲， 我是乙] } 乙的私鑰

現在當甲收到乙的第一個消息，他能檢查證書，簽名（如上所述，使用信息段和公鑰解密），然後檢查標題（乙的姓名），確定是乙。他就能相信公鑰就是乙的公鑰和要求乙證明自己的身份。乙通過上面的過程，製作一個信息段，用一個簽名版本答復甲。甲可以校驗乙的信息段通過使用從證書上得到的公鑰並檢查結果。

如果一個黑客，叫H

甲——〉H：你好

H——〉不能建立一個令甲相信的從乙的消息。

交換密碼（secret）

一旦甲已經驗證乙後，他可以發送給乙一個只有乙可以解密、閱讀的消息：

甲——〉乙：{secret}乙的公鑰

唯一找到密碼的方法只有使用乙的私鑰解碼上述的信息。交換密碼是另一個有效使用密碼加密的方法。即使在甲和乙之間的通訊被偵聽，只有乙才能得到密碼。

使用密碼作為另一個secret-key增強了網路的安全性，但是這次這是一個對稱的加密演算法（例如DES、RC4、IDE甲）。因為甲在發送給乙之前產生了密碼，所以甲知道密碼。乙知道密碼因為乙有私鑰，能夠解密甲的信息。但他們都知道密碼，他們都能夠初始化一個對稱密碼演算法，而且開始發送加密後的信息。這兒是修定後的協議：

甲——〉乙：你好

乙——〉甲：嗨，我是乙，乙的校驗

甲——〉乙：prove it

乙——〉甲：甲，我是乙 {信息段[甲，我是乙] }乙的私鑰

甲——〉乙：ok 乙，here is a secret {secret}乙的公鑰

乙——〉甲：{some message}secret-key

黑客竊聽

那麼如果有一個惡意的黑客H在甲和乙中間，雖然不能發現甲和乙已經交換的密碼，但能幹擾他們的交談。他可以放過大部分信息，選擇破壞一定的信息（這是非常簡單的，因為他知道甲和乙通話採用的協議）。

甲——〉H：你好

H——〉乙：你好

乙——〉H：嗨，我是乙，乙的校驗

H——〉甲：嗨，我是乙，乙的校驗

甲——〉H：prove it

H——〉乙：prove it

乙——〉H：甲，我是乙 {信息段[甲，我是乙] }乙的私鑰

H——〉甲：甲，我是乙 {信息段[甲，我是乙] }乙的私鑰

甲——〉H：ok 乙，here is a secret {secret} 乙的公鑰

H——〉乙：ok 乙，here is a secret {secret} 乙的公鑰

乙——〉H：{some message}secret-key

H——〉甲：Garble[{some message}secret-key ]

H忽略一些數據不修改，直到甲和乙交換密碼。然後H干擾乙給甲的信息。在這一點上，甲相信乙，所以他可能相信已經被干擾的消息並且盡力解密。

需要注意的是，H不知道密碼，他所能做的就是毀壞使用秘鑰加密後的數據。基於協議，H可能不能產生一個有效的消息。但下一次呢？

為了阻止這種破壞，甲和乙在他們的協議中產生一個校驗碼消息（message authentication code）。一個校驗碼消息（MAC）是一部分由密碼和一些傳輸消息產生的數據。信息段演算法描述的上述特性正是它們抵禦H的功能：

MAC= Digest[some message，secret ]

因為H不知道密碼，他不能得出正確的值。即使H隨機干擾消息，只要數據量大，他成功的機會微乎其微。例如，使用HD5（一個RSA發明的好的加密演算法），甲和乙能夠發送128位MAC值和他們的消息。H猜測正確的MAC的幾率將近1/18，446，744，073，709，551，616約等於零。

這是又一次修改後的協議：

甲——〉乙：你好

乙——〉甲：嗨，我是乙，乙的校驗

甲——〉乙：prove it

乙——〉甲：嗨，我是乙，乙的校驗

甲，我是乙

{信息段[甲，我是乙] } 乙的私鑰

ok 乙，here is a secret {secret} 乙的公鑰

{some message，MAC}secret-key

現在H已經無技可施了。他干擾了得到的所有消息，但MAC計算機能夠發現他。甲和乙能夠發現偽造的MAC值並且停止交談。H不再能與乙通訊。

OpenSSL FAQ

⑦ ssl用哪些加密演算法，認證機制

SSL是一個安全協議，它提供使用 TCP/IP 的通信應用程序間的隱私與完整性。網際網路的 超文本傳輸協議（HTTP）使用 SSL 來實現安全的通信。

在客戶端與伺服器間傳輸的數據是通過使用對稱演算法（如 DES 或 RC4）進行加密的。公用密鑰演算法（通常為 RSA）是用來獲得加密密鑰交換和數字簽名的，此演算法使用伺服器的SSL數字證書中的公用密鑰。

有了伺服器的SSL數字證書，客戶端也可以驗證伺服器的身份。SSL 協議的版本 1 和 2 只提供伺服器認證。版本 3 添加了客戶端認證，此認證同時需要客戶端和伺服器的數字證書。

詳細介紹：網頁鏈接

⑧ ssl證書的加密演算法

作用與目的相同都是為了進行加密，更好的保護平台，SSL安全哈希演算法，是數字簽名演算法標准，所以無論您在哪裡注冊無論多少價格的證書，其演算法基本上都是相同的！

申請SSL證書為考慮到瀏覽器兼容性，保持更多的瀏覽器可以訪問，通常採取加密演算法：RSA 2048 bits，簽名演算法：SHA256WithRSA，該演算法被公認使用，就是網路也使用該演算法！

RSA加密演算法：公鑰用於對數據進行加密，私鑰用於對數據進行解密。

RSA簽名演算法：在簽名演算法中，私鑰用於對數據進行簽名，公鑰用於對簽名進行驗證。

加密演算法分為兩大類：1、對稱加密演算法 2、非對稱加密演算法。

由於計算能力的飛速發展，從安全性角度考慮，很多加密原來SHA1WithRSA簽名演算法的基礎上，新增了支持SHA256WithRSA的簽名演算法。該演算法在摘要演算法上比SHA1WithRSA有更強的安全能力。目前SHA1WithRSA的簽名演算法會繼續提供支持，但為了您的應用安全，強烈建議使用SHA256WithRSA的簽名演算法。

⑨ 目前SSL證書通常採用的哪種演算法

為了考慮瀏覽器兼容性，通常使用以下演算法：
加密演算法：RSA
哈希簽名演算法：SHA256
加密位數：2048
最近ECC演算法也比較普遍，主要有點是讀取速度快了，但相反瀏覽器支持率降低了，首先IE7、IE6是肯定不支持的，甚至IE8也不支持。

⑩ SSL 證書的演算法有哪些

根據密鑰類型不同將現代密碼技術分為兩類：對稱加密演算法（秘密鑰匙加密）和非對稱加密演算法（公開密鑰加密）。

對稱鑰匙加密系統是加密和解密均採用同一把秘密鑰匙，而且通信雙方都必須獲得這把鑰匙，並保持鑰匙的秘密。非對稱密鑰加密系統採用的加密鑰匙（公鑰）和解密鑰匙（私鑰）是不同的。

對稱加密演算法用來對敏感數據等信息進行加密，常用的演算法包括：

DES（Data Encryption Standard）：數據加密標准，速度較快，適用於加密大量數據的場合。

3DES（Triple DES）：是基於DES，對一塊數據用三個不同的密鑰進行三次加密，強度更高。

AES（Advanced Encryption Standard）：高級加密標准，是下一代的加密演算法標准，速度快，安全級別高；

常見的非對稱加密演算法如下：

RSA：由 RSA 公司發明，是一個支持變長密鑰的公共密鑰演算法，需要加密的文件塊的長度也是可變的；

DSA（Digital Signature Algorithm）：數字簽名演算法，是一種標準的 DSS（數字簽名標准）；

ECC（Elliptic Curves Cryptography）：橢圓曲線密碼編碼學。