原文地址 http://blog.csdn.net/u012409247/article/details/49852919

SSL/TLS協(xié)議運(yùn)行機(jī)制的概述（http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html）

一、作用

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文傳播，帶來了三大風(fēng)險(xiǎn)。

（1）竊聽風(fēng)險(xiǎn)（eavesdropping）：第三方可以獲知通信內(nèi)容。

（2）篡改風(fēng)險(xiǎn)（tampering）：第三方可以修改通信內(nèi)容。

（3）冒充風(fēng)險(xiǎn)（pretending）：第三方可以冒充他人身份參與通信。

SSL/TLS協(xié)議是為了解決這三大風(fēng)險(xiǎn)而設(shè)計(jì)的，希望達(dá)到：

（1） 所有信息都是加密傳播，第三方無法竊聽。

（2） 具有校驗(yàn)機(jī)制，一旦被篡改，通信雙方會(huì)立刻發(fā)現(xiàn)。

（3） 配備身份證書，防止身份被冒充。

互聯(lián)網(wǎng)是開放環(huán)境，通信雙方都是未知身份，這為協(xié)議的設(shè)計(jì)帶來了很大的難度。而且，協(xié)議還必須能夠經(jīng)受所有匪夷所思的攻擊，這使得SSL/TLS協(xié)議變得異常復(fù)雜。

二、歷史

互聯(lián)網(wǎng)加密通信協(xié)議的歷史，幾乎與互聯(lián)網(wǎng)一樣長。

1994年，NetScape公司設(shè)計(jì)了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布。

1995年，NetScape公司發(fā)布SSL 2.0版，很快發(fā)現(xiàn)有嚴(yán)重漏洞。

1996年，SSL 3.0版問世，得到大規(guī)模應(yīng)用。

1999年，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司，發(fā)布了SSL的升級版TLS1.0版。

2006年和2008年，TLS進(jìn)行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動(dòng)是2011年TLS 1.2的修訂版。

目前，應(yīng)用最廣泛的是TLS 1.0，接下來是SSL 3.0。但是，主流瀏覽器都已經(jīng)實(shí)現(xiàn)了TLS 1.2的支持。

TLS 1.0通常被標(biāo)示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。

三、基本的運(yùn)行過程

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。

但是，這里有兩個(gè)問題。

（1）如何保證公鑰不被篡改？

解決方法：將公鑰放在數(shù)字證書中。只要證書是可信的，公鑰就是可信的。

（2）公鑰加密計(jì)算量太大，如何減少耗用的時(shí)間？

解決方法：每一次對話（session），客戶端和服務(wù)器端都生成一個(gè)"對話密鑰"（session key），用它來加密信息。由于"對話密鑰"是對稱加密，所以運(yùn)算速度非?？?，而服務(wù)器公鑰(非對稱加密)只用于加密"對話密鑰"本身，這樣就減少了加密運(yùn)算的消耗時(shí)間。

因此，SSL/TLS協(xié)議的基本過程是這樣的：

（1） 客戶端向服務(wù)器端索要并驗(yàn)證公鑰。

（2） 雙方協(xié)商生成"對話密鑰"。

（3） 雙方采用"對話密鑰"進(jìn)行加密通信。

上面過程的前兩步，又稱為"握手階段"（handshake）。

四、握手階段的詳細(xì)過程

"握手階段"涉及四次通信，我們一個(gè)個(gè)來看。需要注意的是，"握手階段"的所有通信都是明文的。

4.1 客戶端發(fā)出請求（ClientHello）

首先，客戶端（通常是瀏覽器）先向服務(wù)器發(fā)出加密通信的請求，這被叫做ClientHello請求。

在這一步，客戶端主要向服務(wù)器提供以下信息。

（1） 支持的協(xié)議版本，比如TLS 1.0版。

（2） 一個(gè)客戶端生成的隨機(jī)數(shù)，稍后用于生成"對話密鑰"。

（3） 支持的加密方法，比如RSA公鑰加密。

（4） 支持的壓縮方法。

這里需要注意的是，客戶端發(fā)送的信息之中不包括服務(wù)器的域名。也就是說，理論上服務(wù)器只能包含一個(gè)網(wǎng)站，否則會(huì)分不清應(yīng)該向客戶端提供哪一個(gè)網(wǎng)站的數(shù)字證書。這就是為什么通常一臺(tái)服務(wù)器只能有一張數(shù)字證書的原因。

對于虛擬主機(jī)的用戶來說，這當(dāng)然很不方便。2006年，TLS協(xié)議加入了一個(gè)Server Name Indication擴(kuò)展，允許客戶端向服務(wù)器提供它所請求的域名。

4.2 服務(wù)器回應(yīng)（SeverHello）

服務(wù)器收到客戶端請求后，向客戶端發(fā)出回應(yīng)，這叫做SeverHello。服務(wù)器的回應(yīng)包含以下內(nèi)容。

（1） 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信。

（2） 一個(gè)服務(wù)器生成的隨機(jī)數(shù)，稍后用于生成"對話密鑰"。

（3） 確認(rèn)使用的加密方法，比如RSA公鑰加密。

（4） 服務(wù)器證書。

除了上面這些信息，如果服務(wù)器需要確認(rèn)客戶端的身份，就會(huì)再包含一項(xiàng)請求，要求客戶端提供"客戶端證書"。比如，金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，就會(huì)向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。

4.3 客戶端回應(yīng)

客戶端收到服務(wù)器回應(yīng)以后，首先驗(yàn)證服務(wù)器證書。如果證書不是可信機(jī)構(gòu)頒布、或者證書中的域名與實(shí)際域名不一致、或者證書已經(jīng)過期，就會(huì)向訪問者顯示一個(gè)警告，由其選擇是否還要繼續(xù)通信。

如果證書沒有問題，客戶端就會(huì)從證書中取出服務(wù)器的公鑰。然后，向服務(wù)器發(fā)送下面三項(xiàng)信息。

（1） 一個(gè)隨機(jī)數(shù)。該隨機(jī)數(shù)用服務(wù)器公鑰加密，防止被竊聽。

（2） 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。

（3） 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來供服務(wù)器校驗(yàn)。

上面第一項(xiàng)的隨機(jī)數(shù)，是整個(gè)握手階段出現(xiàn)的第三個(gè)隨機(jī)數(shù)，又稱"pre-master key"。有了它以后，客戶端和服務(wù)器就同時(shí)有了三個(gè)隨機(jī)數(shù)，接著雙方就用事先商定的加密方法，各自生成本次會(huì)話所用的同一把"會(huì)話密鑰"。

至于為什么一定要用三個(gè)隨機(jī)數(shù)，來生成"會(huì)話密鑰"，dog250解釋得很好：

"不管是客戶端還是服務(wù)器，都需要隨機(jī)數(shù)，這樣生成的密鑰才不會(huì)每次都一樣。由于SSL協(xié)議中證書是靜態(tài)的，因此十分有必要引入一種隨機(jī)因素來保證協(xié)商出來的密鑰的隨機(jī)性。

對于RSA密鑰交換算法來說，pre-master-key本身就是一個(gè)隨機(jī)數(shù)，再加上hello消息中的隨機(jī)，三個(gè)隨機(jī)數(shù)通過一個(gè)密鑰導(dǎo)出器最終導(dǎo)出一個(gè)對稱密鑰。

pre master的存在在于SSL協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)，如果隨機(jī)數(shù)不隨機(jī)，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機(jī)因素，那么客戶端和服務(wù)器加上pre master secret三個(gè)隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了，一個(gè)偽隨機(jī)可能完全不隨機(jī)，可是是三個(gè)偽隨機(jī)就十分接近隨機(jī)了，每增加一個(gè)自由度，隨機(jī)性增加的可不是一。"

此外，如果前一步，服務(wù)器要求客戶端證書，客戶端會(huì)在這一步發(fā)送證書及相關(guān)信息。

4.4 服務(wù)器的最后回應(yīng)

服務(wù)器收到客戶端的第三個(gè)隨機(jī)數(shù)pre-master key之后，計(jì)算生成本次會(huì)話所用的"會(huì)話密鑰"。然后，向客戶端最后發(fā)送下面信息。

（1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。

（2）服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來供客戶端校驗(yàn)。

至此，整個(gè)握手階段全部結(jié)束。接下來，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議，只不過用"會(huì)話密鑰"加密內(nèi)容。

網(wǎng)址2：http://blog.163.com/magicc_love/blog/static/185853662201321423527263/

1.??HTTPS

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。 它是一個(gè)URI scheme（抽象標(biāo)識符體系），句法類同http:體系。用于安全的HTTP數(shù)據(jù)傳輸。https:URL表明它使用了HTTPS，但HTTPS存在不同于HTTP的默認(rèn)端口及一個(gè)加密/身份驗(yàn)證層（在HTTP與TCP之間）。這個(gè)系統(tǒng)的最初研發(fā)由網(wǎng)景公司進(jìn)行，提供了身份驗(yàn)證與加密通訊方法，現(xiàn)在它被廣泛用于萬維網(wǎng)上安全敏感的通訊，例如交易支付方面

HTTPS和HTTP的區(qū)別

一、https協(xié)議需要到ca申請證書，一般免費(fèi)證書很少，需要交費(fèi)。

二、http是超文本傳輸協(xié)議，信息是明文傳輸，https?則是具有安全性的ssl加密傳輸協(xié)議。

三、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

四、http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

https的實(shí)現(xiàn)原理

有兩種基本的加解密算法類型

1)對稱加密：密鑰只有一個(gè)，加密解密為同一個(gè)密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；

2)非對稱加密：密鑰成對出現(xiàn)（且根據(jù)公鑰無法推知私鑰，根據(jù)私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

https的通信過程

圖2.1 https的通信過程

https通信的優(yōu)點(diǎn)

1）客戶端產(chǎn)生的密鑰只有客戶端和服務(wù)器端能得到；

2）加密的數(shù)據(jù)只有客戶端和服務(wù)器端才能得到明文；

3）客戶端到服務(wù)端的通信是安全的。

HTTPS解決的問題

一、信任主機(jī)的問題.

采用https的服務(wù)器必須從CA?（Certificate Authority）申請一個(gè)用于證明服務(wù)器用途類型的證書。該證書只有用于對應(yīng)的服務(wù)器的時(shí)候，客戶端才信任此主機(jī)。所以目前所有的銀行系統(tǒng)網(wǎng)站，關(guān)鍵部分應(yīng)用都是https?的?？蛻敉ㄟ^信任該證書，從而信任了該主機(jī)。其實(shí)這樣做效率很低，但是銀行更側(cè)重安全。這一點(diǎn)對我們沒有任何意義，我們的服務(wù)器，采用的證書不管是自己發(fā)布的還是從公眾的地方發(fā)布的，其客戶端都是自己人，所以我們也就肯定信任該服務(wù)器。

二、通訊過程中的數(shù)據(jù)的泄密和被篡改

1． 一般意義上的https，就是服務(wù)器有一個(gè)證書。

a)?主要目的是保證服務(wù)器就是他聲稱的服務(wù)器，這個(gè)跟第一點(diǎn)一樣。

b)?服務(wù)端和客戶端之間的所有通訊，都是加密的。

i.?具體講，是客戶端產(chǎn)生一個(gè)對稱的密鑰，通過服務(wù)器的證書來交換密鑰，即一般意義上的握手過程。

ii.?接下來所有的信息往來就都是加密的。第三方即使截獲，也沒有任何意義，因?yàn)樗麤]有密鑰，當(dāng)然篡改也就沒有什么意義了。

2． 少許對客戶端有要求的情況下，會(huì)要求客戶端也必須有一個(gè)證書。

a)?這里客戶端證書，其實(shí)就類似表示個(gè)人信息的時(shí)候，除了用戶名/密碼，還有一個(gè)CA?認(rèn)證過的身份。因?yàn)閭€(gè)人證書一般來說是別人無法模擬的，所有這樣能夠更深的確認(rèn)自己的身份。

b)?目前少數(shù)個(gè)人銀行的專業(yè)版是這種做法，具體證書可能是拿U盤（即U盾）作為一個(gè)備份的載體

理解誤區(qū)

它的安全保護(hù)依賴瀏覽器的正確實(shí)現(xiàn)以及服務(wù)器軟件、實(shí)際加密算法的支持.

一種常見的誤解是“銀行用戶在線使用https:就能充分徹底保障他們的銀行卡號不被偷竊?！睂?shí)際上，與服務(wù)器的加密連接中能保護(hù)銀行卡號的部分，只有用戶到服務(wù)器之間的連接及服務(wù)器自身。并不能絕對確保服務(wù)器自己是安全的，這點(diǎn)甚至已被攻擊者利用，常見例子是模仿銀行域名的釣魚攻擊。少數(shù)罕見攻擊在網(wǎng)站傳輸客戶數(shù)據(jù)時(shí)發(fā)生，攻擊者會(huì)嘗試竊聽傳輸中的數(shù)據(jù)。

商業(yè)網(wǎng)站被人們期望迅速盡早引入新的特殊處理程序到金融網(wǎng)關(guān)，僅保留傳輸碼(transaction number)。不過他們常常存儲(chǔ)銀行卡號在同一個(gè)數(shù)據(jù)庫里。那些數(shù)據(jù)庫和服務(wù)器少數(shù)情況有可能被未授權(quán)用戶攻擊和損害。

SSL

SSL介紹

SSL安全套接層協(xié)議(Secure Socket Layer)

為Netscape所研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸之安全，利用數(shù)據(jù)加密(Encryption)技術(shù)，可確保數(shù)據(jù)在網(wǎng)絡(luò)上之傳輸過程中不會(huì)被截取及竊聽。目前一般通用之規(guī)格為40 bit之安全標(biāo)準(zhǔn)，美國則已推出128 bit之更高安全標(biāo)準(zhǔn)，但限制出境。只要3.0版本以上之IE或Netscape瀏覽器即可支持SSL。

當(dāng)前版本為3.0。它已被廣泛地用于Web瀏覽器與服務(wù)器之間的身份認(rèn)證和加密數(shù)據(jù)傳輸。

SSL協(xié)議位于TCP/IP協(xié)議與各種應(yīng)用層協(xié)議之間，是一種國際標(biāo)準(zhǔn)的加密及身份認(rèn)證通信協(xié)議,為TCP提供一個(gè)可靠的端到端的安全服務(wù)，為兩個(gè)通訊個(gè)體之間提供保密性和完整性(身份鑒別)。SSL協(xié)議可分為兩層：SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開始前，通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。

SSL協(xié)議特點(diǎn)

1）SSL協(xié)議可用于保護(hù)正常運(yùn)行于TCP之上的任何應(yīng)用協(xié)議，如HTTP、FTP、SMTP或Telnet的通信，最常見的是用SSL來保護(hù)HTTP的通信。

2）SSL協(xié)議的優(yōu)點(diǎn)在于它是與應(yīng)用層協(xié)議無關(guān)的。高層的應(yīng)用協(xié)議（如HTTP、FTP、Telnet等）能透明地建立于SSL協(xié)議之上。

3）SSL協(xié)議在應(yīng)用層協(xié)議之前就已經(jīng)完成加密算法、通信密鑰的協(xié)商以及服務(wù)器的認(rèn)證工作。在此之后應(yīng)用層協(xié)議所傳送的數(shù)據(jù)都會(huì)被加密，從而保證通信的安全性。

4）SSL協(xié)議使用通信雙方的客戶證書以及CA根證書，允許客戶/服務(wù)器應(yīng)用以一種不能被偷聽的方式通信，在通信雙方間建立起了一條安全的、可信任的通信通道。

5）該協(xié)議使用密鑰對傳送數(shù)據(jù)加密，許多網(wǎng)站都是通過這種協(xié)議從客戶端接收信用卡編號等保密信息。常用于交易過程中。

SSL功能

1)客戶對服務(wù)器的身份認(rèn)證:

SSL服務(wù)器允許客戶的瀏覽器使用標(biāo)準(zhǔn)的公鑰加密技術(shù)和一些可靠的認(rèn)證中心（CA）的證書，來確認(rèn)服務(wù)器的合法性。

2)服務(wù)器對客戶的身份認(rèn)證:

也可通過公鑰技術(shù)和證書進(jìn)行認(rèn)證，也可通過用戶名，password來認(rèn)證。

3)建立服務(wù)器與客戶之間安全的數(shù)據(jù)通道:

SSL要求客戶與服務(wù)器之間的所有發(fā)送的數(shù)據(jù)都被發(fā)送端加密、接收端解密，同時(shí)還檢查數(shù)據(jù)的完整性。

SSL協(xié)議工作的基本流程

1）接通階段：客戶機(jī)通過網(wǎng)絡(luò)向服務(wù)器打招呼，服務(wù)器回應(yīng)

2）密碼交換階段：客戶機(jī)與服務(wù)器之間交換雙方認(rèn)可的密碼，一般選用RSA密碼算法

3）會(huì)談密碼階段：客戶機(jī)器與服務(wù)器間產(chǎn)生彼此交談的會(huì)談密碼

4）檢驗(yàn)階段：客戶機(jī)檢驗(yàn)服務(wù)器取得的密碼

5）客戶認(rèn)證階段：服務(wù)器驗(yàn)證客戶機(jī)的可信度

6）結(jié)束階段：客戶機(jī)與服務(wù)器之間相互交換結(jié)束的信息

SSL安全實(shí)現(xiàn)原理

SSL?提供了用于啟動(dòng)?TCP/IP?連接的安全性“信號交換”:

1.??這種信號交換導(dǎo)致客戶和服務(wù)器同意將使用的安全性級別，并履行連接的任何身份驗(yàn)證要求.

2.??通過數(shù)字簽名和數(shù)字證書可實(shí)現(xiàn)瀏覽器和Web服務(wù)器雙方的身份驗(yàn)證。

3.在用數(shù)字證書對雙方的身份驗(yàn)證后，雙方就可以用保密密鑰進(jìn)行安全的會(huì)話了。

SSL協(xié)議說明

SSL協(xié)議具有兩層結(jié)構(gòu):

1)其底層是SSL記錄協(xié)議層（SSL Record Protocol Layer）

2)其高層是SSL握手協(xié)議層（SSL Handshake Protocol Layer）,?主要用來讓客戶端及服務(wù)器確認(rèn)彼此的身分,為了保護(hù)SSL記錄封包中傳送的數(shù)據(jù)，Handshake協(xié)議還能協(xié)助雙方選擇連接時(shí)所會(huì)使用的加密算法、MAC算法、及相關(guān)密鑰。

SSL協(xié)議定義了兩個(gè)通信主體：客戶（client）和服務(wù)器（server）。其中，客戶是協(xié)議的發(fā)起者

在客戶/服務(wù)器結(jié)構(gòu)中，應(yīng)用層從請求服務(wù)和提供服務(wù)的角度定義客戶和服務(wù)器，而SSL協(xié)議則從建立加密參數(shù)的過程中所扮演的角色來定義客戶和服務(wù)器。

SSL握手協(xié)議包含四個(gè)階段:第一個(gè)階段建立安全能力;第二個(gè)階段服務(wù)器鑒別和密鑰交換;第三個(gè)階段客戶鑒別(可選的)和密鑰交換;第四個(gè)階段完成握手協(xié)議。

SSL協(xié)議工作的基本流程

服務(wù)器認(rèn)證階段：1）客戶端向服務(wù)器發(fā)送一個(gè)開始信息“Hello”以便開始一個(gè)新的會(huì)話連接；2）服務(wù)器根據(jù)客戶的信息確定是否需要生成新的主密鑰，如需要?jiǎng)t服務(wù)器在響應(yīng)客戶的“Hello”信息時(shí)將包含生成主密鑰所需的信息；3）客戶根據(jù)收到的服務(wù)器響應(yīng)信息，產(chǎn)生一個(gè)主密鑰，并用服務(wù)器的公開密鑰加密后傳給服務(wù)器；4）服務(wù)器恢復(fù)該主密鑰，并返回給客戶一個(gè)用主密鑰認(rèn)證的信息，以此讓客戶認(rèn)證服務(wù)器。

用戶認(rèn)證階段:

在此之前，服務(wù)器已經(jīng)通過了客戶認(rèn)證，這一階段主要完成對客戶的認(rèn)證。經(jīng)認(rèn)證的服務(wù)器發(fā)送一個(gè)提問給客戶，客戶則返回（數(shù)字）簽名后的提問和其公開密鑰，從而向服務(wù)器提供認(rèn)證。

SSL流程

第一步：身份驗(yàn)證

第二步：發(fā)明密語規(guī)則

第三步：密語規(guī)則共享

第四步：進(jìn)行安全通信

簡要描述

1）客戶端向服務(wù)器發(fā)送一個(gè)開始信息“Hello”以便開始一個(gè)新的會(huì)話連接

2）服務(wù)器根據(jù)客戶的信息確定是否需要生成新的主密鑰，如需要?jiǎng)t服務(wù)器在響應(yīng)客戶的“Hello”信息時(shí)將包含生成主密鑰所需的信息

3）客戶根據(jù)收到的服務(wù)器響應(yīng)信息，產(chǎn)生一個(gè)主密鑰，并用服務(wù)器的公開密鑰加密后傳給服務(wù)器

4）服務(wù)器恢復(fù)該主密鑰，并返回給客戶一個(gè)用主密鑰認(rèn)證的信息，以此讓客戶認(rèn)證服務(wù)器。(以上為服務(wù)端認(rèn)證)

5）服務(wù)器已經(jīng)通過了客戶認(rèn)證，這一階段主要完成對客戶對服務(wù)端的認(rèn)證。經(jīng)認(rèn)證的服務(wù)器發(fā)送一個(gè)提問給客戶，客戶則返回（數(shù)字）簽名后的提問和其公開密鑰，從而向服務(wù)器提供認(rèn)證。（客戶端認(rèn)證）

詳細(xì)描述

SSL?協(xié)議既用到了公鑰加密技術(shù)又用到了對稱加密技術(shù)，對稱加密技術(shù)雖然比公鑰加密技術(shù)的速度快，可是公鑰加密技術(shù)提供了更好的身份認(rèn)證技術(shù)。SSL?的握手協(xié)議非常有效的讓客戶和服務(wù)器之間完成相互之間的身份認(rèn)證，其主要過程如下：

1)客戶端的瀏覽器向服務(wù)器傳送客戶端SSL?協(xié)議的版本號，加密算法的種類，產(chǎn)生的隨機(jī)數(shù)，以及其他服務(wù)器和客戶端之間通訊所需要的各種信息。

2)服務(wù)器向客戶端傳送SSL?協(xié)議的版本號，加密算法的種類，隨機(jī)數(shù)以及其他相關(guān)信息，同時(shí)服務(wù)器還將向客戶端傳送自己的證書。

3)客戶利用服務(wù)器傳過來的信息驗(yàn)證服務(wù)器的合法性，服務(wù)器的合法性包括：證書是否過期，發(fā)行服務(wù)器證書的CA?是否可靠，發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”，服務(wù)器證書上的域名是否和服務(wù)器的實(shí)際域名相匹配。如果合法性驗(yàn)證沒有通過，通訊將斷開；如果合法性驗(yàn)證通過，將繼續(xù)進(jìn)行第四步。

4)用戶端隨機(jī)產(chǎn)生一個(gè)用于后面通訊的“對稱密碼”，然后用服務(wù)器的公鑰（服務(wù)器的公鑰從步驟②中的服務(wù)器的證書中獲得）對其加密，然后將加密后的“預(yù)主密碼”傳給服務(wù)器。?(服務(wù)端驗(yàn)證成功)

5)如果服務(wù)器要求客戶的身份認(rèn)證（在握手過程中為可選），用戶可以建立一個(gè)隨機(jī)數(shù)然后對其進(jìn)行數(shù)據(jù)簽名，將這個(gè)含有簽名的隨機(jī)數(shù)和客戶自己的證書以及加密過的“預(yù)主密碼”一起傳給服務(wù)器。

6)如果服務(wù)器要求客戶的身份認(rèn)證，服務(wù)器必須檢驗(yàn)客戶證書和簽名隨機(jī)數(shù)的合法性，具體的合法性驗(yàn)證過程包括：客戶的證書使用日期是否有效，為客戶提供證書的CA?是否可靠，發(fā)行CA?的公鑰能否正確解開客戶證書的發(fā)行CA?的數(shù)字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗(yàn)如果沒有通過，通訊立刻中斷；如果驗(yàn)證通過，服務(wù)器將用自己的私鑰解開加密的“預(yù)主密碼”，然后執(zhí)行一系列步驟來產(chǎn)生主通訊密碼（客戶端也將通過同樣的方法產(chǎn)生相同的主通訊密碼）。

7)服務(wù)器和客戶端用相同的主密碼即“通話密碼”，一個(gè)對稱密鑰用于SSL?協(xié)議的安全數(shù)據(jù)通訊的加解密通訊。同時(shí)在SSL?通訊過程中還要完成數(shù)據(jù)通訊的完整性，防止數(shù)據(jù)通訊中的任何變化。

8)客戶端向服務(wù)器端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟7中的主密碼為對稱密鑰，同時(shí)通知服務(wù)器客戶端的握手過程結(jié)束。

9)服務(wù)器向客戶端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟7中的主密碼為對稱密鑰，同時(shí)通知客戶端服務(wù)器端的握手過程結(jié)束。

10)SSL?的握手部分結(jié)束，SSL?安全通道的數(shù)據(jù)通訊開始，客戶和服務(wù)器開始使用相同的對稱密鑰進(jìn)行數(shù)據(jù)通訊，同時(shí)進(jìn)行通訊完整性的檢驗(yàn)。

SSL缺點(diǎn)

1）SSL協(xié)議需要在握手之前建立TCP連接，因此不能對UDP應(yīng)用進(jìn)行保護(hù)。

2）為了不致于由于安全協(xié)議的使用而導(dǎo)致網(wǎng)絡(luò)性能大幅下降SSL協(xié)議并不是默認(rèn)地要求進(jìn)行客戶鑒別

用AFN框架實(shí)現(xiàn)https注意事項(xiàng)：(http://my.oschina.net/non6/blog/290175)

友情提示：本文使用的AFNetworking是最新Gitpull的2.3.1版本，如果想確認(rèn)你機(jī)器上的AFNetworking版本，請打git tag命令查看。

絕大部分iOS程序的后臺(tái)服務(wù)都是基于RESTful或者WebService的，不論在任何時(shí)候，你都應(yīng)該將服務(wù)置于HTTPS上，因?yàn)樗梢员苊庵虚g人攻擊的問題，還自帶了基于非對稱密鑰的加密通道！現(xiàn)實(shí)是這些年涌現(xiàn)了大量速成的移動(dòng)端開發(fā)人員，這些人往往基礎(chǔ)很差，完全不了解加解密為何物，使用HTTPS后，可以省去教育他們各種加解密技術(shù)，生活輕松多了。

使用HTTPS有個(gè)問題，就是CA證書。缺省情況下，iOS要求連接的HTTPS站點(diǎn)必須為CA簽名過的合法證書，AFNetworking是個(gè)iOS上常用的HTTP訪問庫，由于它是基于iOS的HTTP網(wǎng)絡(luò)通訊庫，自然證書方面的要求和系統(tǒng)是一致的，也就是你需要有一張合法的站點(diǎn)證書。

正式的CA證書非常昂貴，很多人都知道，AFNetworking2只要通過下面的代碼，你就可以使用（方法1：自簽證書）來訪問HTTPS

?

1

2

AFSecurityPolicy?*securityPolicy?=?[AFSecurityPolicy?defaultPolicy];

securityPolicy.allowInvalidCertificates?=?YES;

這么做有個(gè)問題，就是你無法驗(yàn)證證書是否是你的服務(wù)器后端的證書，給中間人攻擊，即通過重定向路由來分析偽造你的服務(wù)器端打開了大門。

解決方法。AFNetworking2是允許（方法2：內(nèi)嵌證書）的，通過內(nèi)嵌證書，AFNetworking2就通過比對服務(wù)器端證書、內(nèi)嵌的證書、站點(diǎn)域名是否一致來驗(yàn)證連接的服務(wù)器是否正確。由于CA證書驗(yàn)證是通過站點(diǎn)域名進(jìn)行驗(yàn)證的，如果你的服務(wù)器后端有綁定的域名，這是最方便的。將你的服務(wù)器端證書，如果是pem格式的，用下面的命令轉(zhuǎn)成cer格式

?

1

openssl?x509?-in<你的服務(wù)器證書>.pem?-outform?der?-out?server.cer

然后將生成的server.cer文件，如果有自建ca，再加上ca的cer格式證書，引入到app的bundle里，AFNetworking2在

?

1

2

3

4

AFSecurityPolicy?*securityPolicy?=?[AFSecurityPolicy?AFSSLPinningModeCertificate];

或者

AFSecurityPolicy?*securityPolicy?=?[AFSecurityPolicy?AFSSLPinningModePublicKey];

securityPolicy.allowInvalidCertificates?=?YES;//還是必須設(shè)成YES

情況下，會(huì)自動(dòng)掃描bundle中.cer的文件，并引入，這樣就可以通過自簽證書來驗(yàn)證服務(wù)器唯一性了。

我前面說過，驗(yàn)證站點(diǎn)證書，是通過域名的，如果服務(wù)器端站點(diǎn)沒有綁定域名（萬惡的備案），僅靠IP地址上面的方法是絕對不行的。怎么辦？答案是想通過設(shè)置是不可以的，你只能修改AFNetworking2的源代碼！打開AFSecurityPolicy.m文件，找到方法：

?

1

2

-?(BOOL)evaluateServerTrust:(SecTrustRef)serverTrust

forDomain:(NSString?*)domain

將下面這部分注釋掉

?

1

2

3

4

5

6

7

8

9

//????????????SecTrustSetAnchorCertificates(serverTrust,?(__bridge?CFArrayRef)pinnedCertificates);

//

//????????????if?(!AFServerTrustIsValid(serverTrust))?{

//????????????????return?NO;

//????????????}

//

//????????????if?(!self.validatesCertificateChain)?{

//????????????????return?YES;

//????????????}

這樣，AFSecurityPolicy就只會(huì)比對服務(wù)器證書和內(nèi)嵌證書是否一致，不會(huì)再驗(yàn)證證書是否和站點(diǎn)域名一致了。

這么做為什么是安全的？了解HTTPS的人都知道，整個(gè)驗(yàn)證體系中，最核心的實(shí)際上是服務(wù)器的私鑰。私鑰永遠(yuǎn)，永遠(yuǎn)也不會(huì)離開服務(wù)器，或者以任何形式向外傳輸。私鑰和公鑰是配對的，如果事先在客戶端預(yù)留了公鑰，只要服務(wù)器端的公鑰和預(yù)留的公鑰一致，實(shí)際上就已經(jīng)可以排除中間人攻擊了。

用AFN框架實(shí)現(xiàn)https注意事項(xiàng)：(http://www.cnblogs.com/canghaixiaoyuer/p/4738453.html)

本篇說說安全相關(guān)的AFSecurityPolicy模塊，AFSecurityPolicy用于驗(yàn)證HTTPS請求的證書，先來看看HTTPS的原理和證書相關(guān)的幾個(gè)問題。

HTTPS

HTTPS 連接建立過程大致是，客戶端和服務(wù)端建立一個(gè)連接，服務(wù)端返回一個(gè)證書，客戶端里存有各個(gè)受信任的證書機(jī)構(gòu)根證書，用這些根證書對服務(wù)端 返回的證書進(jìn)行驗(yàn)證，經(jīng)驗(yàn)證如果證書是可信任的，就生成一個(gè)pre-master ?secret，用這個(gè)證書的公鑰加密后發(fā)送給服務(wù)端，服務(wù)端用私鑰解密后得到pre-master secret，再根據(jù)某種算法生成master ?secret，客戶端也同樣根據(jù)這種算法從pre-master secret生成master secret，隨后雙方的通信都用這個(gè)master ?secret（客戶端和服務(wù)端生成的一樣，）對傳輸數(shù)據(jù)進(jìn)行加密解密（對稱加密）。

以上是簡單過程，中間還有很多細(xì)節(jié)，詳細(xì)過程和原理已經(jīng)有很多文章闡述得很好，就不再復(fù)述，推薦一些相關(guān)文章：

關(guān)于非對稱加密算法的原理：RSA算法原理<一>、<二>

關(guān)于整個(gè)流程：HTTPS那些事<一>、<二>、<三>

關(guān)于數(shù)字證書：淺析數(shù)字證書

這里說下一開始我比較費(fèi)解的兩個(gè)問題：

1.證書是怎樣驗(yàn)證的？怎樣保證中間人不能偽造證書？

首先要知道非對稱加密算法的特點(diǎn)，非對稱加密有一對公鑰私鑰，用公鑰加密的數(shù)據(jù)只能通過對應(yīng)的私鑰解密，用私鑰加密的數(shù)據(jù)只能通過對應(yīng)的公鑰解密。

我們來看最簡單的情況：一個(gè)證書頒發(fā)機(jī)構(gòu)(CA)，頒發(fā)了一個(gè)證書A，服務(wù)器用這個(gè)證書建立https連接?？蛻舳嗽谛湃瘟斜砝镉羞@個(gè)CA機(jī)構(gòu)的根證書。

首先CA機(jī)構(gòu)頒發(fā)的證書A里包含有證書內(nèi)容F，以及證書加密內(nèi)容F1，加密內(nèi)容F1就是用這個(gè)證書機(jī)構(gòu)的私鑰對內(nèi)容F加密的結(jié)果。（這中間還有一次hash算法，略過。）

建 立https連接時(shí)，服務(wù)端返回證書A給客戶端，客戶端的系統(tǒng)里的CA機(jī)構(gòu)根證書有這個(gè)CA機(jī)構(gòu)的公鑰，用這個(gè)公鑰對證書A的加密內(nèi)容F1解密得 到F2，跟證書A里內(nèi)容F對比，若相等就通過驗(yàn)證。整個(gè)流程大致是：F->CA私鑰加密->F1->客戶端CA公鑰解密->F。 因?yàn)橹虚g人不會(huì)有CA機(jī)構(gòu)的私鑰，客戶端無法通過CA公鑰解密，所以偽造的證書肯定無法通過驗(yàn)證。

2.什么是SSL Pinning？

可以理解為證書綁定，是指客戶端直接保存服務(wù)端的證書，建立https連接時(shí)直接對比服務(wù)端返回的和客戶端保存的兩個(gè)證書是否一樣，一樣就表明證書 是真的，不再去系統(tǒng)的信任證書機(jī)構(gòu)里尋找驗(yàn)證。這適用于非瀏覽器應(yīng)用，因?yàn)闉g覽器跟很多未知服務(wù)端打交道，無法把每個(gè)服務(wù)端的證書都保存到本地，但CS架 構(gòu)的像手機(jī)APP事先已經(jīng)知道要進(jìn)行通信的服務(wù)端，可以直接在客戶端保存這個(gè)服務(wù)端的證書用于校驗(yàn)。

為什么直接對比就能保證證書沒問題？ 如果中間人從客戶端取出證書，再偽裝成服務(wù)端跟其他客戶端通信，它發(fā)送給客戶端的這個(gè)證書不就能通過驗(yàn)證嗎？確 實(shí)可以通過驗(yàn)證，但后續(xù)的流程走不下去，因?yàn)橄乱徊娇蛻舳藭?huì)用證書里的公鑰加密，中間人沒有這個(gè)證書的私鑰就解不出內(nèi)容，也就截獲不到數(shù)據(jù)，這個(gè)證書的私 鑰只有真正的服務(wù)端有，中間人偽造證書主要偽造的是公鑰。

為什么要用SSL ?Pinning？正常的驗(yàn)證方式不夠嗎？如果服務(wù)端的證書是從受信任的的CA機(jī)構(gòu)頒發(fā)的，驗(yàn)證是沒問題的，但CA機(jī)構(gòu)頒發(fā)證書比較昂貴，小企業(yè)或個(gè)人用 戶 可能會(huì)選擇自己頒發(fā)證書，這樣就無法通過系統(tǒng)受信任的CA機(jī)構(gòu)列表驗(yàn)證這個(gè)證書的真?zhèn)瘟耍孕枰猄SL Pinning這樣的方式去驗(yàn)證。

AFSecurityPolicy

NSURLConnection 已經(jīng)封裝了https連接的建立、數(shù)據(jù)的加密解密功能，我們直接使用NSURLConnection是可以訪問 https網(wǎng)站的，但NSURLConnection并沒有驗(yàn)證證書是否合法，無法避免中間人攻擊。要做到真正安全通訊，需要我們手動(dòng)去驗(yàn)證服務(wù)端返回的 證書，AFSecurityPolicy封裝了證書驗(yàn)證的過程，讓用戶可以輕易使用，除了去系統(tǒng)信任CA機(jī)構(gòu)列表驗(yàn)證，還支持SSL ?Pinning方式的驗(yàn)證。使用方法：

1

2

3

4

5

6

7//把服務(wù)端證書(需要轉(zhuǎn)換成cer格式)放到APP項(xiàng)目資源里，AFSecurityPolicy會(huì)自動(dòng)尋找根目錄下所有cer文件

AFSecurityPolicy?*securityPolicy?=?[AFSecurityPolicy?policyWithPinningMode:AFSSLPinningModePublicKey];

securityPolicy.allowInvalidCertificates?=?YES;

[AFHTTPRequestOperationManager?manager].securityPolicy?=?securityPolicy;

[manager?GET:@"https://example.com/"parameters:nil?success:^(AFHTTPRequestOperation?*operation,?id?responseObject)?{

}?failure:^(AFHTTPRequestOperation?*operation,?NSError?*error)?{

}];

AFSecurityPolicy分三種驗(yàn)證模式：

AFSSLPinningModeNone

這個(gè)模式表示不做SSL pinning，只跟瀏覽器一樣在系統(tǒng)的信任機(jī)構(gòu)列表里驗(yàn)證服務(wù)端返回的證書。若證書是信任機(jī)構(gòu)簽發(fā)的就會(huì)通過，若是自己服務(wù)器生成的證書，這里是不會(huì)通過的。

AFSSLPinningModeCertificate

這個(gè)模式表示用證書綁定方式驗(yàn)證證書，需要客戶端保存有服務(wù)端的證書拷貝，這里驗(yàn)證分兩步，第一步驗(yàn)證證書的域名/有效期等信息，第二步是對比服務(wù)端返回的證書跟客戶端返回的是否一致。

這里還沒弄明白第一步的驗(yàn)證是怎么進(jìn)行的，代碼上跟去系統(tǒng)信任機(jī)構(gòu)列表里驗(yàn)證一樣調(diào)用了SecTrustEvaluate，只是這里的列表換成了客戶端保存的那些證書列表。若要驗(yàn)證這個(gè)，是否應(yīng)該把服務(wù)端證書的頒發(fā)機(jī)構(gòu)根證書也放到客戶端里？

AFSSLPinningModePublicKey

這個(gè)模式同樣是用證書綁定方式驗(yàn)證，客戶端要有服務(wù)端的證書拷貝，只是驗(yàn)證時(shí)只驗(yàn)證證書里的公鑰，不驗(yàn)證證書的有效期等信息。只要公鑰是正確的，就能保證通信不會(huì)被竊聽，因?yàn)橹虚g人沒有私鑰，無法解開通過公鑰加密的數(shù)據(jù)。

整個(gè)AFSecurityPolicy就是實(shí)現(xiàn)這這幾種驗(yàn)證方式，剩下的就是實(shí)現(xiàn)細(xì)節(jié)了，詳見源碼。（AFSecurity.m）

具體代碼:(http://blog.csdn.net/woaifen3344/article/details/41145729)

下面說明一下使用AFNetworking網(wǎng)絡(luò)庫訪問的方式：

[objc]view plaincopy

-?(void)testClientCertificate?{

SecIdentityRef?identity?=NULL;

SecTrustRef?trust?=NULL;

NSString*p12?=?[[NSBundlemainBundle]pathForResource:@"testClient"ofType:@"p12"];

NSData*PKCS12Data?=?[NSDatadataWithContentsOfFile:p12];

[[selfclass]extractIdentity:&identityandTrust:&trustfromPKCS12Data:PKCS12Data];

NSString*url?=@"https://218.244.131.231/ManicureShop/api/order/pay/%@";

NSDictionary*dic?=?@{@"request":?@{

@"orderNo":@"1409282102222110030643",

@"type":?@(2)

}

};

_signString?=nil;

NSData*postData?=?[NSJSONSerializationdataWithJSONObject:dicoptions:NSJSONWritingPrettyPrintederror:nil];

NSString*sign?=?[selfsignWithSignKey:@"test"params:dic];

NSMutableData*body?=?[postDatamutableCopy];

NSLog(@"%@",?[[NSStringalloc]initWithData:bodyencoding:NSUTF8StringEncoding]);

url?=?[NSStringstringWithFormat:url,sign];

AFHTTPRequestOperationManager*manager?=?[AFHTTPRequestOperationManagermanager];

manager.requestSerializer?=?[AFJSONRequestSerializerserializer];

manager.responseSerializer?=?[AFJSONResponseSerializerserializer];

[manager.requestSerializersetValue:@"application/json"forHTTPHeaderField:@"Accept"];

[manager.requestSerializersetValue:@"application/json"forHTTPHeaderField:@"Content-Type"];

manager.responseSerializer.acceptableContentTypes?=?[NSSetsetWithArray:@[@"application/json",@"text/plain"]];

manager.securityPolicy?=?[selfcustomSecurityPolicy];

[managerPOST:urlparameters:dicsuccess:^(AFHTTPRequestOperation*operation,idresponseObject)?{

NSLog(@"JSON:?%@",?responseObject);

}failure:^(AFHTTPRequestOperation*operation,NSError*error)?{

NSLog(@"Error:?%@",?error);

}];

}

下面這段代碼是處理SSL安全性問題的:

[objc]view plaincopy

/****?SSL?Pinning?****/

-?(AFSecurityPolicy*)customSecurityPolicy?{

NSString*cerPath?=?[[NSBundlemainBundle]pathForResource:@"testClient"ofType:@"cer"];

NSData*certData?=?[NSDatadataWithContentsOfFile:cerPath];

AFSecurityPolicy*securityPolicy?=?[AFSecurityPolicydefaultPolicy];

[securityPolicysetAllowInvalidCertificates:YES];

[securityPolicysetPinnedCertificates:@[certData]];

[securityPolicysetSSLPinningMode:AFSSLPinningModeCertificate];

/****?SSL?Pinning?****/

returnsecurityPolicy;

}

用SSL Pinning報(bào)錯(cuò):

Error Domain=NSURLErrorDomain Code=-1012 "The operation couldn’t be completed. (NSURLErrorDomain error -1012.)" UserInfo=0x14dc29e0 {NSErrorFailingURLKey=https://user.nowifi.cn/app/reg?action=send, NSErrorFailingURLStringKey=https://user.nowifi.cn/app/reg?action=send}

解決辦法：