一、作用
不使用SSL/TLS的HTTP通信，就是不加密的通信磕诊。所有信息明文傳播，帶來(lái)了三大風(fēng)險(xiǎn)。
（1）竊聽(tīng)風(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） 所有信息都是加密傳播击困，第三方無(wú)法竊聽(tīng)。
（2） 具有校驗(yàn)機(jī)制广凸，一旦被篡改阅茶，通信雙方會(huì)立刻發(fā)現(xiàn)。
（3） 配備身份證書(shū)谅海，防止身份被冒充脸哀。
互聯(lián)網(wǎng)是開(kāi)放環(huán)境，通信雙方都是未知身份胁赢，這為協(xié)議的設(shè)計(jì)帶來(lái)了很大的難度企蹭。而且，協(xié)議還必須能夠經(jīng)受所有匪夷所思的攻擊智末，這使得SSL/TLS協(xié)議變得異常復(fù)雜谅摄。
二、歷史
互聯(lián)網(wǎng)加密通信協(xié)議的歷史系馆，幾乎與互聯(lián)網(wǎng)一樣長(zhǎ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版問(wèn)世裳擎，得到大規(guī)模應(yīng)用涎永。
1999年，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司鹿响，發(fā)布了SSL的升級(jí)版TLS1.0版羡微。
2006年和2008年，TLS進(jìn)行了兩次升級(jí)惶我，分別為TLS 1.1版和TLS 1.2版妈倔。最新的變動(dòng)是2011年TLS 1.2的修訂版。
目前绸贡，應(yīng)用最廣泛的是TLS 1.0盯蝴，接下來(lái)是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)行過(guò)程
SSL/TLS協(xié)議的基本思路是采用公鑰加密法筷厘，也就是說(shuō)鸣峭，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息酥艳，服務(wù)器收到密文后摊溶，用自己的私鑰解密。
但是充石，這里有兩個(gè)問(wèn)題莫换。
（1）如何保證公鑰不被篡改？
解決方法：將公鑰放在數(shù)字證書(shū)中骤铃。只要證書(shū)是可信的拉岁，公鑰就是可信的。
（2）公鑰加密計(jì)算量太大惰爬，如何減少耗用的時(shí)間喊暖？
解決方法：每一次對(duì)話（session），客戶端和服務(wù)器端都生成一個(gè)"對(duì)話密鑰"（session key）撕瞧，用它來(lái)加密信息陵叽。由于"對(duì)話密鑰"是對(duì)稱加密，所以運(yùn)算速度非炒园妫快巩掺，而服務(wù)器公鑰(非對(duì)稱加密)只用于加密"對(duì)話密鑰"本身，這樣就減少了加密運(yùn)算的消耗時(shí)間页畦。
因此胖替，SSL/TLS協(xié)議的基本過(guò)程是這樣的：
（1） 客戶端向服務(wù)器端索要并驗(yàn)證公鑰。
（2） 雙方協(xié)商生成"對(duì)話密鑰"寇漫。
（3） 雙方采用"對(duì)話密鑰"進(jìn)行加密通信刊殉。
上面過(guò)程的前兩步，又稱為"握手階段"（handshake）州胳。
四记焊、握手階段的詳細(xì)過(guò)程
"握手階段"涉及四次通信，我們一個(gè)個(gè)來(lái)看栓撞。需要注意的是遍膜，"握手階段"的所有通信都是明文的碗硬。
4.1 客戶端發(fā)出請(qǐng)求（ClientHello）
首先，客戶端（通常是瀏覽器）先向服務(wù)器發(fā)出加密通信的請(qǐng)求瓢颅，這被叫做ClientHello請(qǐng)求恩尾。
在這一步，客戶端主要向服務(wù)器提供以下信息挽懦。
（1） 支持的協(xié)議版本翰意，比如TLS 1.0版。
（2） 一個(gè)客戶端生成的隨機(jī)數(shù)信柿，稍后用于生成"對(duì)話密鑰"冀偶。
（3） 支持的加密方法，比如RSA公鑰加密渔嚷。
（4） 支持的壓縮方法进鸠。
這里需要注意的是，客戶端發(fā)送的信息之中不包括服務(wù)器的域名形病。也就是說(shuō)客年，理論上服務(wù)器只能包含一個(gè)網(wǎng)站，否則會(huì)分不清應(yīng)該向客戶端提供哪一個(gè)網(wǎng)站的數(shù)字證書(shū)漠吻。這就是為什么通常一臺(tái)服務(wù)器只能有一張數(shù)字證書(shū)的原因量瓜。
對(duì)于虛擬主機(jī)的用戶來(lái)說(shuō)，這當(dāng)然很不方便侥猩。2006年榔至，TLS協(xié)議加入了一個(gè)Server Name Indication擴(kuò)展，允許客戶端向服務(wù)器提供它所請(qǐng)求的域名欺劳。
4.2 服務(wù)器回應(yīng)（SeverHello）
服務(wù)器收到客戶端請(qǐng)求后唧取，向客戶端發(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ù)伊履，稍后用于生成"對(duì)話密鑰"韩容。
（3） 確認(rèn)使用的加密方法，比如RSA公鑰加密唐瀑。
（4） 服務(wù)器證書(shū)群凶。
除了上面這些信息，如果服務(wù)器需要確認(rèn)客戶端的身份哄辣，就會(huì)再包含一項(xiàng)請(qǐng)求请梢，要求客戶端提供"客戶端證書(shū)"赠尾。比如，金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)毅弧，就會(huì)向正式客戶提供USB密鑰气嫁，里面就包含了一張客戶端證書(shū)。
4.3 客戶端回應(yīng)
客戶端收到服務(wù)器回應(yīng)以后够坐，首先驗(yàn)證服務(wù)器證書(shū)寸宵。如果證書(shū)不是可信機(jī)構(gòu)頒布、或者證書(shū)中的域名與實(shí)際域名不一致咆霜、或者證書(shū)已經(jīng)過(guò)期邓馒，就會(huì)向訪問(wèn)者顯示一個(gè)警告嘶朱，由其選擇是否還要繼續(xù)通信蛾坯。
如果證書(shū)沒(méi)有問(wèn)題，客戶端就會(huì)從證書(shū)中取出服務(wù)器的公鑰疏遏。然后脉课，向服務(wù)器發(fā)送下面三項(xiàng)信息。
（1） 一個(gè)隨機(jī)數(shù)财异。該隨機(jī)數(shù)用服務(wù)器公鑰加密倘零，防止被竊聽(tīng)。
（2） 編碼改變通知戳寸，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送呈驶。
（3） 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束疫鹊。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值袖瞻，用來(lái)供服務(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ù)牺堰，來(lái)生成"會(huì)話密鑰"，dog250解釋得很好：
"不管是客戶端還是服務(wù)器颅围，都需要隨機(jī)數(shù)伟葫，這樣生成的密鑰才不會(huì)每次都一樣。由于SSL協(xié)議中證書(shū)是靜態(tài)的谷浅，因此十分有必要引入一種隨機(jī)因素來(lái)保證協(xié)商出來(lái)的密鑰的隨機(jī)性扒俯。
對(duì)于RSA密鑰交換算法來(lái)說(shuō)奶卓，pre-master-key本身就是一個(gè)隨機(jī)數(shù)，再加上hello消息中的隨機(jī)撼玄，三個(gè)隨機(jī)數(shù)通過(guò)一個(gè)密鑰導(dǎo)出器最終導(dǎo)出一個(gè)對(duì)稱密鑰夺姑。
pre master的存在在于SSL協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)，如果隨機(jī)數(shù)不隨機(jī)掌猛，那么pre master secret就有可能被猜出來(lái)盏浙，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機(jī)因素荔茬，那么客戶端和服務(wù)器加上pre master secret三個(gè)隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了废膘，一個(gè)偽隨機(jī)可能完全不隨機(jī)，可是是三個(gè)偽隨機(jī)就十分接近隨機(jī)了慕蔚，每增加一個(gè)自由度丐黄，隨機(jī)性增加的可不是一。"
此外孔飒，如果前一步灌闺，服務(wù)器要求客戶端證書(shū)，客戶端會(huì)在這一步發(fā)送證書(shū)及相關(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值睦柴，用來(lái)供客戶端校驗(yàn)诽凌。
至此，整個(gè)握手階段全部結(jié)束坦敌。接下來(lái)侣诵，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議狱窘，只不過(guò)用"會(huì)話密鑰"加密內(nèi)容杜顺。
網(wǎng)址2：http://blog.163.com/magicc_love/blog/static/185853662201321423527263/
HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道蘸炸，簡(jiǎn)單講是HTTP的安全版躬络。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL搭儒，因此加密的詳細(xì)內(nèi)容就需要SSL穷当。 它是一個(gè)URI scheme（抽象標(biāo)識(shí)符體系）提茁，句法類同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àn)維網(wǎng)上安全敏感的通訊，例如交易支付方面
一智嚷、https協(xié)議需要到ca申請(qǐng)證書(shū)卖丸，一般免費(fèi)證書(shū)很少，需要交費(fèi)盏道。
二稍浆、http是超文本傳輸協(xié)議，信息是明文傳輸摇天，https?則是具有安全性的ssl加密傳輸協(xié)議粹湃。
三、http和https使用的是完全不同的連接方式泉坐，用的端口也不一樣，前者是80裳仆，后者是443腕让。
四、http的連接很簡(jiǎn)單歧斟，是無(wú)狀態(tài)的纯丸；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議静袖，比http協(xié)議安全觉鼻。
1)對(duì)稱加密：密鑰只有一個(gè)，加密解密為同一個(gè)密碼队橙，且加解密速度快坠陈，典型的對(duì)稱加密算法有DES、AES等捐康；
2)非對(duì)稱加密：密鑰成對(duì)出現(xiàn)（且根據(jù)公鑰無(wú)法推知私鑰仇矾，根據(jù)私鑰也無(wú)法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密解总，私鑰加密需要公鑰解密）贮匕，相對(duì)對(duì)稱加密速度較慢，典型的非對(duì)稱加密算法有RSA花枫、DSA等刻盐。
圖2.1 https的通信過(guò)程
1）客戶端產(chǎn)生的密鑰只有客戶端和服務(wù)器端能得到掏膏；
2）加密的數(shù)據(jù)只有客戶端和服務(wù)器端才能得到明文；
3）客戶端到服務(wù)端的通信是安全的敦锌。
采用https的服務(wù)器必須從CA?（Certificate Authority）申請(qǐng)一個(gè)用于證明服務(wù)器用途類型的證書(shū)。該證書(shū)只有用于對(duì)應(yīng)的服務(wù)器的時(shí)候供屉，客戶端才信任此主機(jī)行冰。所以目前所有的銀行系統(tǒng)網(wǎng)站，關(guān)鍵部分應(yīng)用都是https?的伶丐〉孔觯客戶通過(guò)信任該證書(shū)，從而信任了該主機(jī)哗魂。其實(shí)這樣做效率很低肛走，但是銀行更側(cè)重安全。這一點(diǎn)對(duì)我們沒(méi)有任何意義录别，我們的服務(wù)器朽色，采用的證書(shū)不管是自己發(fā)布的還是從公眾的地方發(fā)布的，其客戶端都是自己人组题，所以我們也就肯定信任該服務(wù)器葫男。
二、通訊過(guò)程中的數(shù)據(jù)的泄密和被篡改
1． 一般意義上的https崔列，就是服務(wù)器有一個(gè)證書(shū)梢褐。
a)?主要目的是保證服務(wù)器就是他聲稱的服務(wù)器，這個(gè)跟第一點(diǎn)一樣赵讯。
b)?服務(wù)端和客戶端之間的所有通訊盈咳，都是加密的。
i.?具體講边翼，是客戶端產(chǎn)生一個(gè)對(duì)稱的密鑰鱼响，通過(guò)服務(wù)器的證書(shū)來(lái)交換密鑰，即一般意義上的握手過(guò)程组底。
ii.?接下來(lái)所有的信息往來(lái)就都是加密的丈积。第三方即使截獲，也沒(méi)有任何意義斤寇，因?yàn)樗麤](méi)有密鑰桶癣，當(dāng)然篡改也就沒(méi)有什么意義了。
2． 少許對(duì)客戶端有要求的情況下娘锁，會(huì)要求客戶端也必須有一個(gè)證書(shū)牙寞。
a)?這里客戶端證書(shū)，其實(shí)就類似表示個(gè)人信息的時(shí)候，除了用戶名/密碼间雀，還有一個(gè)CA?認(rèn)證過(guò)的身份悔详。因?yàn)閭€(gè)人證書(shū)一般來(lái)說(shuō)是別人無(wú)法模擬的，所有這樣能夠更深的確認(rèn)自己的身份惹挟。
b)?目前少數(shù)個(gè)人銀行的專業(yè)版是這種做法茄螃，具體證書(shū)可能是拿U盤（即U盾）作為一個(gè)備份的載體
它的安全保護(hù)依賴瀏覽器的正確實(shí)現(xiàn)以及服務(wù)器軟件、實(shí)際加密算法的支持.
一種常見(jiàn)的誤解是“銀行用戶在線使用https:就能充分徹底保障他們的銀行卡號(hào)不被偷竊连锯」椴裕”實(shí)際上，與服務(wù)器的加密連接中能保護(hù)銀行卡號(hào)的部分运怖，只有用戶到服務(wù)器之間的連接及服務(wù)器自身拼弃。并不能絕對(duì)確保服務(wù)器自己是安全的，這點(diǎn)甚至已被攻擊者利用摇展，常見(jiàn)例子是模仿銀行域名的釣魚(yú)攻擊吻氧。少數(shù)罕見(jiàn)攻擊在網(wǎng)站傳輸客戶數(shù)據(jù)時(shí)發(fā)生，攻擊者會(huì)嘗試竊聽(tīng)傳輸中的數(shù)據(jù)咏连。
商業(yè)網(wǎng)站被人們期望迅速盡早引入新的特殊處理程序到金融網(wǎng)關(guān)盯孙，僅保留傳輸碼(transaction number)。不過(guò)他們常常存儲(chǔ)銀行卡號(hào)在同一個(gè)數(shù)據(jù)庫(kù)里祟滴。那些數(shù)據(jù)庫(kù)和服務(wù)器少數(shù)情況有可能被未授權(quán)用戶攻擊和損害振惰。
SSL安全套接層協(xié)議(Secure Socket Layer)
為Netscape所研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸之安全踱启，利用數(shù)據(jù)加密(Encryption)技術(shù)报账，可確保數(shù)據(jù)在網(wǎng)絡(luò)上之傳輸過(guò)程中不會(huì)被截取及竊聽(tīng)。目前一般通用之規(guī)格為40 bit之安全標(biāo)準(zhǔn)埠偿，美國(guó)則已推出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é)議之間抖剿，是一種國(guó)際標(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ù)傳輸開(kāi)始前，通訊雙方進(jìn)行身份認(rèn)證锻煌、協(xié)商加密算法妓布、交換加密密鑰等。
1）SSL協(xié)議可用于保護(hù)正常運(yùn)行于TCP之上的任何應(yīng)用協(xié)議宋梧，如HTTP匣沼、FTP、SMTP或Telnet的通信捂龄，最常見(jiàn)的是用SSL來(lái)保護(hù)HTTP的通信释涛。
2）SSL協(xié)議的優(yōu)點(diǎn)在于它是與應(yīng)用層協(xié)議無(wú)關(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é)議使用通信雙方的客戶證書(shū)以及CA根證書(shū)耀态，允許客戶/服務(wù)器應(yīng)用以一種不能被偷聽(tīng)的方式通信，在通信雙方間建立起了一條安全的暂雹、可信任的通信通道首装。
5）該協(xié)議使用密鑰對(duì)傳送數(shù)據(jù)加密，許多網(wǎng)站都是通過(guò)這種協(xié)議從客戶端接收信用卡編號(hào)等保密信息杭跪。常用于交易過(guò)程中仙逻。
1)客戶對(duì)服務(wù)器的身份認(rèn)證:
SSL服務(wù)器允許客戶的瀏覽器使用標(biāo)準(zhǔn)的公鑰加密技術(shù)和一些可靠的認(rèn)證中心（CA）的證書(shū)，來(lái)確認(rèn)服務(wù)器的合法性涧尿。
2)服務(wù)器對(duì)客戶的身份認(rèn)證:
也可通過(guò)公鑰技術(shù)和證書(shū)進(jìn)行認(rèn)證系奉，也可通過(guò)用戶名，password來(lái)認(rèn)證姑廉。
3)建立服務(wù)器與客戶之間安全的數(shù)據(jù)通道:
SSL要求客戶與服務(wù)器之間的所有發(fā)送的數(shù)據(jù)都被發(fā)送端加密缺亮、接收端解密，同時(shí)還檢查數(shù)據(jù)的完整性桥言。
1）接通階段：客戶機(jī)通過(guò)網(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?提供了用于啟動(dòng)?TCP/IP?連接的安全性“信號(hào)交換”:
1.??這種信號(hào)交換導(dǎo)致客戶和服務(wù)器同意將使用的安全性級(jí)別号阿，并履行連接的任何身份驗(yàn)證要求.
2.??通過(guò)數(shù)字簽名和數(shù)字證書(shū)可實(shí)現(xiàn)瀏覽器和Web服務(wù)器雙方的身份驗(yàn)證并鸵。
3.在用數(shù)字證書(shū)對(duì)雙方的身份驗(yàn)證后绅你，雙方就可以用保密密鑰進(jìn)行安全的會(huì)話了舀瓢。
SSL協(xié)議具有兩層結(jié)構(gòu):
1)其底層是SSL記錄協(xié)議層（SSL Record Protocol Layer）
2)其高層是SSL握手協(xié)議層（SSL Handshake Protocol Layer）,?主要用來(lái)讓客戶端及服務(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)用層從請(qǐng)求服務(wù)和提供服務(wù)的角度定義客戶和服務(wù)器程剥，而SSL協(xié)議則從建立加密參數(shù)的過(guò)程中所扮演的角色來(lái)定義客戶和服務(wù)器。
SSL握手協(xié)議包含四個(gè)階段:第一個(gè)階段建立安全能力;第二個(gè)階段服務(wù)器鑒別和密鑰交換;第三個(gè)階段客戶鑒別(可選的)和密鑰交換;第四個(gè)階段完成握手協(xié)議汤踏。
服務(wù)器認(rèn)證階段：1）客戶端向服務(wù)器發(fā)送一個(gè)開(kāi)始信息“Hello”以便開(kāi)始一個(gè)新的會(huì)話連接织鲸；2）服務(wù)器根據(jù)客戶的信息確定是否需要生成新的主密鑰，如需要?jiǎng)t服務(wù)器在響應(yīng)客戶的“Hello”信息時(shí)將包含生成主密鑰所需的信息溪胶；3）客戶根據(jù)收到的服務(wù)器響應(yīng)信息搂擦，產(chǎn)生一個(gè)主密鑰，并用服務(wù)器的公開(kāi)密鑰加密后傳給服務(wù)器哗脖；4）服務(wù)器恢復(fù)該主密鑰瀑踢，并返回給客戶一個(gè)用主密鑰認(rèn)證的信息，以此讓客戶認(rèn)證服務(wù)器才避。
在此之前橱夭，服務(wù)器已經(jīng)通過(guò)了客戶認(rèn)證，這一階段主要完成對(duì)客戶的認(rèn)證桑逝。經(jīng)認(rèn)證的服務(wù)器發(fā)送一個(gè)提問(wèn)給客戶棘劣，客戶則返回（數(shù)字）簽名后的提問(wèn)和其公開(kāi)密鑰，從而向服務(wù)器提供認(rèn)證楞遏。
第一步：身份驗(yàn)證
第二步：發(fā)明密語(yǔ)規(guī)則
第三步：密語(yǔ)規(guī)則共享
第四步：進(jìn)行安全通信
簡(jiǎn)要描述
1）客戶端向服務(wù)器發(fā)送一個(gè)開(kāi)始信息“Hello”以便開(kāi)始一個(gè)新的會(huì)話連接
2）服務(wù)器根據(jù)客戶的信息確定是否需要生成新的主密鑰茬暇，如需要?jiǎng)t服務(wù)器在響應(yīng)客戶的“Hello”信息時(shí)將包含生成主密鑰所需的信息
3）客戶根據(jù)收到的服務(wù)器響應(yīng)信息，產(chǎn)生一個(gè)主密鑰寡喝，并用服務(wù)器的公開(kāi)密鑰加密后傳給服務(wù)器
4）服務(wù)器恢復(fù)該主密鑰糙俗，并返回給客戶一個(gè)用主密鑰認(rèn)證的信息，以此讓客戶認(rèn)證服務(wù)器预鬓。(以上為服務(wù)端認(rèn)證)
5）服務(wù)器已經(jīng)通過(guò)了客戶認(rèn)證臼节，這一階段主要完成對(duì)客戶對(duì)服務(wù)端的認(rèn)證。經(jīng)認(rèn)證的服務(wù)器發(fā)送一個(gè)提問(wèn)給客戶珊皿，客戶則返回（數(shù)字）簽名后的提問(wèn)和其公開(kāi)密鑰，從而向服務(wù)器提供認(rèn)證巨税。（客戶端認(rèn)證）
詳細(xì)描述
SSL?協(xié)議既用到了公鑰加密技術(shù)又用到了對(duì)稱加密技術(shù)蟋定，對(duì)稱加密技術(shù)雖然比公鑰加密技術(shù)的速度快，可是公鑰加密技術(shù)提供了更好的身份認(rèn)證技術(shù)草添。SSL?的握手協(xié)議非常有效的讓客戶和服務(wù)器之間完成相互之間的身份認(rèn)證驶兜，其主要過(guò)程如下：
1)客戶端的瀏覽器向服務(wù)器傳送客戶端SSL?協(xié)議的版本號(hào)，加密算法的種類，產(chǎn)生的隨機(jī)數(shù)抄淑，以及其他服務(wù)器和客戶端之間通訊所需要的各種信息屠凶。
2)服務(wù)器向客戶端傳送SSL?協(xié)議的版本號(hào)，加密算法的種類肆资，隨機(jī)數(shù)以及其他相關(guān)信息矗愧，同時(shí)服務(wù)器還將向客戶端傳送自己的證書(shū)。
3)客戶利用服務(wù)器傳過(guò)來(lái)的信息驗(yàn)證服務(wù)器的合法性郑原，服務(wù)器的合法性包括：證書(shū)是否過(guò)期唉韭，發(fā)行服務(wù)器證書(shū)的CA?是否可靠，發(fā)行者證書(shū)的公鑰能否正確解開(kāi)服務(wù)器證書(shū)的“發(fā)行者的數(shù)字簽名”犯犁，服務(wù)器證書(shū)上的域名是否和服務(wù)器的實(shí)際域名相匹配属愤。如果合法性驗(yàn)證沒(méi)有通過(guò)，通訊將斷開(kāi)酸役；如果合法性驗(yàn)證通過(guò)住诸，將繼續(xù)進(jìn)行第四步。
4)用戶端隨機(jī)產(chǎn)生一個(gè)用于后面通訊的“對(duì)稱密碼”涣澡，然后用服務(wù)器的公鑰（服務(wù)器的公鑰從步驟②中的服務(wù)器的證書(shū)中獲得）對(duì)其加密贱呐，然后將加密后的“預(yù)主密碼”傳給服務(wù)器。?(服務(wù)端驗(yàn)證成功)
5)如果服務(wù)器要求客戶的身份認(rèn)證（在握手過(guò)程中為可選）暑塑，用戶可以建立一個(gè)隨機(jī)數(shù)然后對(duì)其進(jìn)行數(shù)據(jù)簽名吼句，將這個(gè)含有簽名的隨機(jī)數(shù)和客戶自己的證書(shū)以及加密過(guò)的“預(yù)主密碼”一起傳給服務(wù)器。
6)如果服務(wù)器要求客戶的身份認(rèn)證事格，服務(wù)器必須檢驗(yàn)客戶證書(shū)和簽名隨機(jī)數(shù)的合法性惕艳，具體的合法性驗(yàn)證過(guò)程包括：客戶的證書(shū)使用日期是否有效，為客戶提供證書(shū)的CA?是否可靠驹愚，發(fā)行CA?的公鑰能否正確解開(kāi)客戶證書(shū)的發(fā)行CA?的數(shù)字簽名远搪，檢查客戶的證書(shū)是否在證書(shū)廢止列表（CRL）中。檢驗(yàn)如果沒(méi)有通過(guò)逢捺，通訊立刻中斷谁鳍；如果驗(yàn)證通過(guò)，服務(wù)器將用自己的私鑰解開(kāi)加密的“預(yù)主密碼”劫瞳，然后執(zhí)行一系列步驟來(lái)產(chǎn)生主通訊密碼（客戶端也將通過(guò)同樣的方法產(chǎn)生相同的主通訊密碼）倘潜。
7)服務(wù)器和客戶端用相同的主密碼即“通話密碼”，一個(gè)對(duì)稱密鑰用于SSL?協(xié)議的安全數(shù)據(jù)通訊的加解密通訊志于。同時(shí)在SSL?通訊過(guò)程中還要完成數(shù)據(jù)通訊的完整性涮因，防止數(shù)據(jù)通訊中的任何變化。
8)客戶端向服務(wù)器端發(fā)出信息伺绽，指明后面的數(shù)據(jù)通訊將使用的步驟7中的主密碼為對(duì)稱密鑰养泡，同時(shí)通知服務(wù)器客戶端的握手過(guò)程結(jié)束嗜湃。
9)服務(wù)器向客戶端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟7中的主密碼為對(duì)稱密鑰澜掩，同時(shí)通知客戶端服務(wù)器端的握手過(guò)程結(jié)束购披。
10)SSL?的握手部分結(jié)束，SSL?安全通道的數(shù)據(jù)通訊開(kāi)始肩榕，客戶和服務(wù)器開(kāi)始使用相同的對(duì)稱密鑰進(jìn)行數(shù)據(jù)通訊刚陡，同時(shí)進(jìn)行通訊完整性的檢驗(yàn)。
1）SSL協(xié)議需要在握手之前建立TCP連接点把，因此不能對(duì)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版本郎逃，請(qǐng)打git tag命令查看哥童。
絕大部分iOS程序的后臺(tái)服務(wù)都是基于RESTful或者WebService的，不論在任何時(shí)候褒翰，你都應(yīng)該將服務(wù)置于HTTPS上贮懈，因?yàn)樗梢员苊庵虚g人攻擊的問(wèn)題，還自帶了基于非對(duì)稱密鑰的加密通道优训！現(xiàn)實(shí)是這些年涌現(xiàn)了大量速成的移動(dòng)端開(kāi)發(fā)人員朵你，這些人往往基礎(chǔ)很差，完全不了解加解密為何物揣非，使用HTTPS后抡医，可以省去教育他們各種加解密技術(shù)，生活輕松多了早敬。
使用HTTPS有個(gè)問(wèn)題忌傻，就是CA證書(shū)。缺省情況下搞监，iOS要求連接的HTTPS站點(diǎn)必須為CA簽名過(guò)的合法證書(shū)水孩，AFNetworking是個(gè)iOS上常用的HTTP訪問(wèn)庫(kù)，由于它是基于iOS的HTTP網(wǎng)絡(luò)通訊庫(kù)琐驴，自然證書(shū)方面的要求和系統(tǒng)是一致的俘种，也就是你需要有一張合法的站點(diǎn)證書(shū)。
正式的CA證書(shū)非常昂貴绝淡，很多人都知道宙刘，AFNetworking2只要通過(guò)下面的代碼，你就可以使用（方法1：自簽證書(shū)）來(lái)訪問(wèn)HTTPS
1
2AFSecurityPolicy?*securityPolicy?=?[AFSecurityPolicy?defaultPolicy];
securityPolicy.allowInvalidCertificates?=?YES;
這么做有個(gè)問(wèn)題牢酵，就是你無(wú)法驗(yàn)證證書(shū)是否是你的服務(wù)器后端的證書(shū)荐类，給中間人攻擊，即通過(guò)重定向路由來(lái)分析偽造你的服務(wù)器端打開(kāi)了大門茁帽。
解決方法玉罐。AFNetworking2是允許（方法2：內(nèi)嵌證書(shū)）的，通過(guò)內(nèi)嵌證書(shū)潘拨，AFNetworking2就通過(guò)比對(duì)服務(wù)器端證書(shū)吊输、內(nèi)嵌的證書(shū)、站點(diǎn)域名是否一致來(lái)驗(yàn)證連接的服務(wù)器是否正確铁追。由于CA證書(shū)驗(yàn)證是通過(guò)站點(diǎn)域名進(jìn)行驗(yàn)證的季蚂，如果你的服務(wù)器后端有綁定的域名，這是最方便的琅束。將你的服務(wù)器端證書(shū)扭屁，如果是pem格式的，用下面的命令轉(zhuǎn)成cer格式
1
openssl?x509?-in<你的服務(wù)器證書(shū)>.pem?-outform?der?-out?server.cer
然后將生成的server.cer文件涩禀，如果有自建ca料滥，再加上ca的cer格式證書(shū)，引入到app的bundle里艾船，AFNetworking2在
1
2
3
4AFSecurityPolicy?*securityPolicy?=?[AFSecurityPolicy?AFSSLPinningModeCertificate];
或者
AFSecurityPolicy?*securityPolicy?=?[AFSecurityPolicy?AFSSLPinningModePublicKey];
securityPolicy.allowInvalidCertificates?=?YES;//還是必須設(shè)成YES
情況下葵腹，會(huì)自動(dòng)掃描bundle中.cer的文件，并引入屿岂，這樣就可以通過(guò)自簽證書(shū)來(lái)驗(yàn)證服務(wù)器唯一性了践宴。
我前面說(shuō)過(guò)，驗(yàn)證站點(diǎn)證書(shū)爷怀，是通過(guò)域名的阻肩，如果服務(wù)器端站點(diǎn)沒(méi)有綁定域名（萬(wàn)惡的備案），僅靠IP地址上面的方法是絕對(duì)不行的运授。怎么辦烤惊？答案是想通過(guò)設(shè)置是不可以的，你只能修改AFNetworking2的源代碼徒坡！打開(kāi)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ì)比對(duì)服務(wù)器證書(shū)和內(nèi)嵌證書(shū)是否一致喇完，不會(huì)再驗(yàn)證證書(shū)是否和站點(diǎn)域名一致了伦泥。
這么做為什么是安全的？了解HTTPS的人都知道锦溪，整個(gè)驗(yàn)證體系中不脯，最核心的實(shí)際上是服務(wù)器的私鑰。私鑰永遠(yuǎn)刻诊，永遠(yuǎn)也不會(huì)離開(kāi)服務(wù)器防楷，或者以任何形式向外傳輸。私鑰和公鑰是配對(duì)的则涯，如果事先在客戶端預(yù)留了公鑰复局，只要服務(wù)器端的公鑰和預(yù)留的公鑰一致冲簿，實(shí)際上就已經(jīng)可以排除中間人攻擊了。
用AFN框架實(shí)現(xiàn)https注意事項(xiàng)：(http://www.cnblogs.com/canghaixiaoyuer/p/4738453.html)
本篇說(shuō)說(shuō)安全相關(guān)的AFSecurityPolicy模塊亿昏，AFSecurityPolicy用于驗(yàn)證HTTPS請(qǐng)求的證書(shū)峦剔，先來(lái)看看HTTPS的原理和證書(shū)相關(guān)的幾個(gè)問(wèn)題。
HTTPS 連接建立過(guò)程大致是角钩，客戶端和服務(wù)端建立一個(gè)連接吝沫，服務(wù)端返回一個(gè)證書(shū)，客戶端里存有各個(gè)受信任的證書(shū)機(jī)構(gòu)根證書(shū)递礼，用這些根證書(shū)對(duì)服務(wù)端 返回的證書(shū)進(jìn)行驗(yàn)證惨险，經(jīng)驗(yàn)證如果證書(shū)是可信任的，就生成一個(gè)pre-master ?secret脊髓，用這個(gè)證書(shū)的公鑰加密后發(fā)送給服務(wù)端辫愉，服務(wù)端用私鑰解密后得到pre-master secret，再根據(jù)某種算法生成master ?secret供炼，客戶端也同樣根據(jù)這種算法從pre-master secret生成master secret一屋，隨后雙方的通信都用這個(gè)master ?secret（客戶端和服務(wù)端生成的一樣，）對(duì)傳輸數(shù)據(jù)進(jìn)行加密解密（對(duì)稱加密）袋哼。
以上是簡(jiǎn)單過(guò)程冀墨，中間還有很多細(xì)節(jié)，詳細(xì)過(guò)程和原理已經(jīng)有很多文章闡述得很好涛贯，就不再?gòu)?fù)述诽嘉，推薦一些相關(guān)文章：
關(guān)于非對(duì)稱加密算法的原理：RSA算法原理<一>、<二>
關(guān)于整個(gè)流程：HTTPS那些事<一>弟翘、<二>虫腋、<三>
關(guān)于數(shù)字證書(shū)：淺析數(shù)字證書(shū)
這里說(shuō)下一開(kāi)始我比較費(fèi)解的兩個(gè)問(wèn)題：
1.證書(shū)是怎樣驗(yàn)證的？怎樣保證中間人不能偽造證書(shū)稀余？
首先要知道非對(duì)稱加密算法的特點(diǎn)悦冀，非對(duì)稱加密有一對(duì)公鑰私鑰，用公鑰加密的數(shù)據(jù)只能通過(guò)對(duì)應(yīng)的私鑰解密睛琳，用私鑰加密的數(shù)據(jù)只能通過(guò)對(duì)應(yīng)的公鑰解密盒蟆。
我們來(lái)看最簡(jiǎn)單的情況：一個(gè)證書(shū)頒發(fā)機(jī)構(gòu)(CA)，頒發(fā)了一個(gè)證書(shū)A师骗，服務(wù)器用這個(gè)證書(shū)建立https連接历等。客戶端在信任列表里有這個(gè)CA機(jī)構(gòu)的根證書(shū)辟癌。
首先CA機(jī)構(gòu)頒發(fā)的證書(shū)A里包含有證書(shū)內(nèi)容F寒屯，以及證書(shū)加密內(nèi)容F1，加密內(nèi)容F1就是用這個(gè)證書(shū)機(jī)構(gòu)的私鑰對(duì)內(nèi)容F加密的結(jié)果黍少。（這中間還有一次hash算法寡夹，略過(guò)处面。）
建 立https連接時(shí)，服務(wù)端返回證書(shū)A給客戶端要出，客戶端的系統(tǒng)里的CA機(jī)構(gòu)根證書(shū)有這個(gè)CA機(jī)構(gòu)的公鑰鸳君，用這個(gè)公鑰對(duì)證書(shū)A的加密內(nèi)容F1解密得 到F2，跟證書(shū)A里內(nèi)容F對(duì)比患蹂，若相等就通過(guò)驗(yàn)證。整個(gè)流程大致是：F->CA私鑰加密->F1->客戶端CA公鑰解密->F砸紊。 因?yàn)橹虚g人不會(huì)有CA機(jī)構(gòu)的私鑰传于，客戶端無(wú)法通過(guò)CA公鑰解密，所以偽造的證書(shū)肯定無(wú)法通過(guò)驗(yàn)證醉顽。
2.什么是SSL Pinning沼溜？
可以理解為證書(shū)綁定，是指客戶端直接保存服務(wù)端的證書(shū)游添，建立https連接時(shí)直接對(duì)比服務(wù)端返回的和客戶端保存的兩個(gè)證書(shū)是否一樣系草，一樣就表明證書(shū) 是真的，不再去系統(tǒng)的信任證書(shū)機(jī)構(gòu)里尋找驗(yàn)證唆涝。這適用于非瀏覽器應(yīng)用找都，因?yàn)闉g覽器跟很多未知服務(wù)端打交道，無(wú)法把每個(gè)服務(wù)端的證書(shū)都保存到本地廊酣，但CS架 構(gòu)的像手機(jī)APP事先已經(jīng)知道要進(jìn)行通信的服務(wù)端能耻，可以直接在客戶端保存這個(gè)服務(wù)端的證書(shū)用于校驗(yàn)。
為什么直接對(duì)比就能保證證書(shū)沒(méi)問(wèn)題亡驰？ 如果中間人從客戶端取出證書(shū)晓猛，再偽裝成服務(wù)端跟其他客戶端通信，它發(fā)送給客戶端的這個(gè)證書(shū)不就能通過(guò)驗(yàn)證嗎凡辱？確 實(shí)可以通過(guò)驗(yàn)證戒职，但后續(xù)的流程走不下去，因?yàn)橄乱徊娇蛻舳藭?huì)用證書(shū)里的公鑰加密透乾，中間人沒(méi)有這個(gè)證書(shū)的私鑰就解不出內(nèi)容洪燥，也就截獲不到數(shù)據(jù)，這個(gè)證書(shū)的私 鑰只有真正的服務(wù)端有续徽，中間人偽造證書(shū)主要偽造的是公鑰蚓曼。
為什么要用SSL ?Pinning？正常的驗(yàn)證方式不夠嗎钦扭？如果服務(wù)端的證書(shū)是從受信任的的CA機(jī)構(gòu)頒發(fā)的纫版，驗(yàn)證是沒(méi)問(wèn)題的，但CA機(jī)構(gòu)頒發(fā)證書(shū)比較昂貴客情，小企業(yè)或個(gè)人用 戶 可能會(huì)選擇自己頒發(fā)證書(shū)其弊，這樣就無(wú)法通過(guò)系統(tǒng)受信任的CA機(jī)構(gòu)列表驗(yàn)證這個(gè)證書(shū)的真?zhèn)瘟笋海孕枰猄SL Pinning這樣的方式去驗(yàn)證。
NSURLConnection 已經(jīng)封裝了https連接的建立梭伐、數(shù)據(jù)的加密解密功能痹雅，我們直接使用NSURLConnection是可以訪問(wèn) https網(wǎng)站的，但NSURLConnection并沒(méi)有驗(yàn)證證書(shū)是否合法糊识，無(wú)法避免中間人攻擊绩社。要做到真正安全通訊，需要我們手動(dòng)去驗(yàn)證服務(wù)端返回的 證書(shū)赂苗，AFSecurityPolicy封裝了證書(shū)驗(yàn)證的過(guò)程愉耙，讓用戶可以輕易使用，除了去系統(tǒng)信任CA機(jī)構(gòu)列表驗(yàn)證拌滋，還支持SSL ?Pinning方式的驗(yàn)證朴沿。使用方法：
1
2
3
4
5
6
7//把服務(wù)端證書(shū)(需要轉(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ù)端返回的證書(shū)赌渣。若證書(shū)是信任機(jī)構(gòu)簽發(fā)的就會(huì)通過(guò)，若是自己服務(wù)器生成的證書(shū)昌犹，這里是不會(huì)通過(guò)的坚芜。
AFSSLPinningModeCertificate
這個(gè)模式表示用證書(shū)綁定方式驗(yàn)證證書(shū)，需要客戶端保存有服務(wù)端的證書(shū)拷貝祭隔，這里驗(yàn)證分兩步货岭，第一步驗(yàn)證證書(shū)的域名/有效期等信息，第二步是對(duì)比服務(wù)端返回的證書(shū)跟客戶端返回的是否一致疾渴。
這里還沒(méi)弄明白第一步的驗(yàn)證是怎么進(jìn)行的千贯，代碼上跟去系統(tǒng)信任機(jī)構(gòu)列表里驗(yàn)證一樣調(diào)用了SecTrustEvaluate，只是這里的列表?yè)Q成了客戶端保存的那些證書(shū)列表搞坝。若要驗(yàn)證這個(gè)搔谴，是否應(yīng)該把服務(wù)端證書(shū)的頒發(fā)機(jī)構(gòu)根證書(shū)也放到客戶端里？
AFSSLPinningModePublicKey
這個(gè)模式同樣是用證書(shū)綁定方式驗(yàn)證桩撮，客戶端要有服務(wù)端的證書(shū)拷貝敦第，只是驗(yàn)證時(shí)只驗(yàn)證證書(shū)里的公鑰，不驗(yàn)證證書(shū)的有效期等信息店量。只要公鑰是正確的芜果，就能保證通信不會(huì)被竊聽(tīng)，因?yàn)橹虚g人沒(méi)有私鑰融师，無(wú)法解開(kāi)通過(guò)公鑰加密的數(shù)據(jù)右钾。
整個(gè)AFSecurityPolicy就是實(shí)現(xiàn)這這幾種驗(yàn)證方式，剩下的就是實(shí)現(xiàn)細(xì)節(jié)了，詳見(jiàn)源碼舀射。（AFSecurity.m）
具體代碼:(http://blog.csdn.net/woaifen3344/article/details/41145729)
下面說(shuō)明一下使用AFNetworking網(wǎng)絡(luò)庫(kù)訪問(wèn)的方式：
[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安全性問(wèn)題的:
[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}
解決辦法：
頂
1
