一区二区三区欧美日韩-一区二区三区欧美-一区二区三区免费在线视频-一区二区三区免费在线观看-久久精品店-久久精品第一页

企業(yè)建站知識推廣知識小程序微信營銷 APP開發(fā) 前端設計 MindManager 開發(fā)語言自媒體

iOS https

發(fā)表日期：2017-03 文章編輯：小燈瀏覽次數(shù)：1974

HTTPS協(xié)議

1.作用

學名SSL/ TLS 協(xié)議，不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文傳播，帶來了三大風險。

（1） 竊聽風險（eavesdropping）：第三方可以獲知通信內容。 （2） 篡改風險（tampering）：第三方可以修改通信內容。 （3） 冒充風險（pretending）：第三方可以冒充他人身份參與通信。

SSL/TLS協(xié)議是為了解決這三大風險而設計的，希望達到：

（1） 所有信息都是加密傳播，第三方無法竊聽。 （2） 具有校驗機制，一旦被篡改，通信雙方會立刻發(fā)現(xiàn)。 （3） 配備身份證書，防止身份被冒充。

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

2.歷史

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

1994年，NetScape公司設計了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布。 1995年，NetScape公司發(fā)布SSL 2.0版，很快發(fā)現(xiàn)有嚴重漏洞。 1996年，SSL 3.0版問世，得到大規(guī)模應用。 1999年，互聯(lián)網標準化組織ISOC接替NetScape公司，發(fā)布了SSL的升級版[TLS] 1.0版。 2006年和2008年，TLS進行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的[修訂版]。

3.基本的運行過程

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

但是，這里有兩個問題。
（1）如何保證公鑰不被篡改？
解決方法：將公鑰放在數(shù)字證書中。只要證書是可信的，公鑰就是可信的。
（2）公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。由于"對話密鑰"是對稱加密，所以運算速度非常快，而服務器公鑰只用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。

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

（1） 客戶端向服務器端索要并驗證公鑰。 （2） 雙方協(xié)商生成"對話密鑰"。 （3） 雙方采用"對話密鑰"進行加密通信。

4.握手階段的詳細過程

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

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

首先，客戶端（通常是瀏覽器）先向服務器發(fā)出加密通信的請求，這被叫做ClientHello請求。
在這一步，客戶端主要向服務器提供以下信息。

（1） 支持的協(xié)議版本，比如TLS 1.0版。 （2） 一個客戶端生成的隨機數(shù)，稍后用于生成"對話密鑰"。 （3） 支持的加密方法，比如RSA公鑰加密。 （4） 支持的壓縮方法。

這里需要注意的是，客戶端發(fā)送的信息之中不包括服務器的域名。也就是說，理論上服務器只能包含一個網站，否則會分不清應該向客戶端提供哪一個網站的數(shù)字證書。這就是為什么通常一臺服務器只能有一張數(shù)字證書的原因。
對于虛擬主機的用戶來說，這當然很不方便。2006年，TLS協(xié)議加入了一個Server Name Indication擴展，允許客戶端向服務器提供它所請求的域名。

4.2 服務器回應（SeverHello）

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

（1） 確認使用的加密通信協(xié)議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。 （2） 一個服務器生成的隨機數(shù)，稍后用于生成"對話密鑰"。 （3） 確認使用的加密方法，比如RSA公鑰加密。 （4） 服務器證書。

除了上面這些信息，如果服務器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。比如，金融機構往往只允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。

4.3 客戶端回應

客戶端收到服務器回應以后，首先驗證服務器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續(xù)通信。
如果證書沒有問題，客戶端就會從證書中取出服務器的公鑰。然后，向服務器發(fā)送下面三項信息。

（1） 一個隨機數(shù)。該隨機數(shù)用服務器公鑰加密，防止被竊聽。 （2） 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。 （3） 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發(fā)送的所有內容的hash值，用來供服務器校驗。

上面第一項的隨機數(shù)，是整個握手階段出現(xiàn)的第三個隨機數(shù)，又稱"pre-master key"。有了它以后，客戶端和服務器就同時有了三個隨機數(shù)，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。
至于為什么一定要用三個隨機數(shù)，來生成"會話密鑰"，dog250解釋得很好：

"不管是客戶端還是服務器，都需要隨機數(shù)，這樣生成的密鑰才不會每次都一樣。由于SSL協(xié)議中證書是靜態(tài)的，因此十分有必要引入一種隨機因素來保證協(xié)商出來的密鑰的隨機性。 對于RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數(shù)，再加上hello消息中的隨機，三個隨機數(shù)通過一個密鑰導出器最終導出一個對稱密鑰。 pre master的存在在于SSL協(xié)議不信任每個主機都能產生完全隨機的隨機數(shù)，如果隨機數(shù)不隨機，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了， 因此必須引入新的隨機因素，那么客戶端和服務器加上pre master secret三個隨機數(shù)一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。"

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

4.4 服務器的最后回應

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

（1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。 （2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發(fā)送的所有內容的hash值，用來供客戶端校驗。

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

整個過程可以用下面這張圖來總結：

HTTPS四次握手

iOS ATS

2016年12月21日蘋果更新了截止日期，宣布延期執(zhí)行ATS支持要求Supporting App Transport Security。
此舉為開發(fā)者提供了更多時間來做適配和支持。然而，對于iOS開發(fā)者來說，盡早解決HTTPS請求的問題仍為上策。
蘋果ATS對HTTPS證書的要求
啟用ATS必須符合以下標準，不滿足條件的HTTPS證書，ATS都會拒絕連接：

服務器所有的連接使用TLS1.2以上版本
HTTPS證書必須使用SHA256以上哈希算法簽名
HTTPS證書必須使用RSA 2048位或ECC 256位以上公鑰算法
使用前向加密技術

此外，蘋果ATS支持CT證書透明，要求開發(fā)者使用支持CT證書透明度的SSL證書，確保SSL證書合法透明，防止中間人攻擊。

發(fā)送HTTPS請求信任SSL證書，分為兩種情況：

如果你的app服務端安裝的是SSL權威機構頒發(fā)的CA證書，可以使用系統(tǒng)方法直接實現(xiàn)信任SSL證書，關于Apple對SSL證書的要求請參考：蘋果官方文檔CertKeyTrustProgGuide
這種方式不需要在Bundle中引入CA文件，可以交給系統(tǒng)去判斷服務器端的證書是不是SSL證書，驗證過程也不需要我們去具體實現(xiàn)，網絡請求部分的代碼無需做修改即可。

基于AFNetWorking的SSL自制服務器證書信任處理，重寫AFNetWorking的customSecurityPolicy方法,這里創(chuàng)建了一個MMDBaseHandle類，分別對GET和POST方法進行了封裝：

- (void)requestWithURL:(NSString * _Nonnull) URLString method:(HTTPMethod)method params:(id _Nullable)params block:(nonnull void (^)(MMDResponse * _Nonnull response))block {NSString *token = [MMDCommonUserModel instance].accessToken; NSLog(@"********HTTP REQUEST ACCESSTOKEN:%@", token); if (![StringUtils isNullOrEmpty:token]) { [self.requestSerializer setValue:token forHTTPHeaderField:@"mmTicket"]; }// 加上這行代碼，https ssl 驗證。 if(openHttpsSSL) { [mgr setSecurityPolicy:[self customSecurityPolicy]]; }NSLog(@"********HTTP REQUEST URL: %@%@", self.baseURL.absoluteString, URLString); NSLog(@"********HTTP REQUEST PARAMS: %@", params);switch (method) { case GET: { NSLog(@"暫時還不支持GET請求方式，請用POST請求"); break; } case POST: { [self POST:URLString parameters:params progress:nil success:^(NSURLSessionDataTask * _Nonnull task, id _Nullable responseObject) { [self publicHandleResponse:responseObject reqURL:URLString error:nil block:block]; } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) { [self publicHandleResponse:nil reqURL:URLString error:error block:block]; }]; break; } case PUT: { NSLog(@"暫時還不支持PUT請求方式，請用POST請求"); break; } case DELETE: { NSLog(@"暫時還不支持DELETE請求方式，請用POST請求"); break; } } }+ (AFSecurityPolicy*)customSecurityPolicy { // /先導入證書 NSString *cerPath = [[NSBundle mainBundle] pathForResource:certificate ofType:@"cer"];//證書的路徑 NSData *certData = [NSData dataWithContentsOfFile:cerPath];// AFSSLPinningModeCertificate 使用證書驗證模式 AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];// allowInvalidCertificates 是否允許無效證書（也就是自建的證書），默認為NO // 如果是需要驗證自建證書，需要設置為YES securityPolicy.allowInvalidCertificates = YES;//validatesDomainName 是否需要驗證域名，默認為YES； //假如證書的域名與你請求的域名不一致，需把該項設置為NO；如設成NO的話，即服務器使用其他可信任機構頒發(fā)的證書，也可以建立連接，這個非常危險，建議打開。 //置為NO，主要用于這種情況：客戶端請求的是子域名，而證書上的是另外一個域名。因為SSL證書上的域名是獨立的，假如證書上注冊的域名是www.google.com，那么mail.google.com是無法驗證通過的；當然，有錢可以注冊通配符的域名*.google.com，但這個還是比較貴的。 //如置為NO，建議自己添加對應域名的校驗邏輯。 securityPolicy.validatesDomainName = NO;securityPolicy.pinnedCertificates = @[certData];return securityPolicy; }

其中的cerPath就是app bundle中證書路徑，certificate為證書名稱的宏，僅支持cer格式，securityPolicy的相關配置尤為重要，請仔細閱讀customSecurityPolicy方法并根據(jù)實際情況設置其屬性。
這樣，就能夠在AFNetWorking的基礎上使用HTTPS協(xié)議訪問特定服務器，但是不能信任根證書的CA文件，因此這種方式存在風險，讀取pinnedCertificates中的證書數(shù)組的時候有可能失敗，如果證書不符合，certData就會為nil。

本頁內容由塔燈網絡科技有限公司通過網絡收集編輯所得，所有資料僅供用戶學習參考，本站不擁有所有權，如您認為本網頁中由涉嫌抄襲的內容，請及時與我們聯(lián)系，并提供相關證據(jù)，工作人員會在5工作日內聯(lián)系您，一經查實，本站立刻刪除侵權內容。本文鏈接:http://www.junxiaosheng.cn/20485.html

上一篇：<淺談HTTPS（SSL/TLS）原理下一篇：Tomcat 6 服務器證書安裝配置指南>