發個廣告：ios開發兩年了，一步步走來 關注公衆號一起進步
發現一篇好文章，小小修改記錄下 原文地址：http://www.jianshu.com/p/b03ae4a1a2d3
關於https的簡介和說明我都是參考下面的文章：(謝謝文章作者)
1.http://my.oschina.net/vimfung/blog/494687
2.http://oncenote.com/2014/10/21/Security-1-HTTPS/
3.http://blog.csdn.net/dachao_me/article/details/48624685?ref=myread
最新消息：蘋果關於接入https的截止時間被延期了，具體截止時間尚未定，蘋果推遲https接入截止時間，小夥伴們！別太着急了！
https的說明我就不多說了，想要了解詳細內容查看上面的鏈接，很多專業名詞我也不是很明白，只後悔大學的時候關於網絡工程等一些課程沒有好好聽吧！我寫這篇文章主要是爲了iOS工程中http轉化爲https的教程。
1.修改info.plist中不安全的http兼容配置
目前絕大多數工作爲了解決https的問題，直接在info.plist中添加配置使得系統的請求類NSURLSession(NSURLConnection)默認的請求方式從https轉化爲http,
注意：加了這個配置後，http和https都是兼容的，如果是https請求，會繼續走https，是http請求會繼續走http
配置如下：
這種方法只能說治標不治本，再說蘋果公司也做出了規定2017年上架的app必須使用https不然可能無法通過審覈，所以爲了適配https的第一步就是刪除這個配置，講默認請求方式設置成https。刪除後再次啓動程序會發現請求全部失敗，這個錯誤相信大家都很熟悉，沒錯就是因爲服務器不支持https導致的。
2.使用系統的NSURLSession(NSURLConnection)或者第三方的請求框架(AFNetworking)實現https適配
我項目中使用的是AFNetworking 3.1，所以我先利用AFNetworking做適配(其實AFNetworking的https適配還是利用NSURLSession(NSURLConnection)做的適配，只不過NSURLSession(NSURLConnection)適配有點麻煩，AFNetworking的適配更加簡單)，原本的manager初始化不變，只不過需要爲manager的securityPolicy設置值(不好意思哦！不知道怎麼樣才能添加規範的代碼，只能用截圖來代替了)。
添加完成之後還是出現上面的問題：
檢查後發現請求的路徑不對，之前都是http，忘記改成https了(請求的路徑一定要跟服務器開發人員確定好了)，修改完成後還是報錯，抓狂！！還是很奇葩的錯誤，請求被取消了，錯誤碼－999，
找了很多資料才發現還需要站點證書，上面請求失敗可能是因爲ssl第一次握手的時候驗證沒通過，然後就直接被取消了。所以這時候就需要獲取站點的證書，獲取的方法有兩種：
1.通過openssl命令獲取，命令如下(以百度爲例)：
openssl s_client -connect www.baidu.com:443 </dev/null 2>/dev/null | openssl x509 -outform DER > https1.cer
這個命令的目的就是直接在你的終端打開的當前目錄下面下載某一站點的證書，但是我怎麼都獲取不到下載的證書都是空的，而且終端還報錯，找不到錯誤的原因，沒辦法只能用第二種辦法了
2.直接在瀏覽器中打開項目的任意一個接口的完整路徑，如果你服務器支持https的話會在鏈接的前面出現一個小鎖的圖標(我使用的是safair瀏覽器)，點擊小鎖會出現提示點擊顯示證書就會出現站點證書的信息了(以百度爲例)，點擊證書的圖標到桌面上就可以把證書下載到桌面上了，這樣就獲取到站點證書了(這種方式不知道會不會存在啥問題，但是到目前爲止我沒遇到啥問題)
獲取到證書後把證書放到項目的mainbundle中，並用代碼獲取
這時候再跑起來，接口都能獲取到數據了，成功了，不過到這裏大家不知道會不會存在疑問，證書這麼容易獲取到，那別人獲取了怎麼辦？就算用抓包工具攔截了請求裏面的內容都是加密的，但是別人可以利用證書向我們服務器發請求的，是不是也存在點問題呢？這個問題我到現在還不是很明白，有的資料說這樣獲取的證書是公鑰，沒有私鑰的話也是白費力氣。
3.由於iOS做https適配的時候對服務器是有要求的(一個符合 ATS 要求的 HTTPS)，所以出了問題也不一定是客戶端的問題
其實上面成功了，但是還有很多概念不是很清楚，例如啥叫ATS(App Transport Security)，它跟https有啥關係呢？
App Transport Security（簡稱ATS）特性, 主要使到原來請求的時候用到的HTTP，都轉向TLS1.2協議進行傳輸。這也意味着所有的HTTP協議都強制使用了HTTPS協議進行傳輸，ATS是在iOS 9.0 和 OS X v10.11版本中增加的特性，使用iOS 9.0或者OS X v10.11的SDK版本（或更新的SDK）進行編譯應用時會默認啓動ATS。則需要對ATS進行配置。如果使用iOS 9.0或者OS X v10.11之前的SDK版本編譯的應用默認是禁止ATS的，因此不會影響應用的網絡連接方面的功能（即使在iOS
9.0的機子上跑也是不影響的）。其實ATS並不單單針對HTTP進行了限制，對HTTPS也有一定的要求：
首先頒發給服務器證書的證書機構（CA）的根證書必須是內置於操作系統（哪些根證書被信任可以查看https://support.apple.com/zh-cn/HT205205，或者在你的機子的設置－通用－關於本機最下面的“進一步瞭解被信任的證書”中查看，百度的CA根證書：）或者受用戶或者系統管理員信任並安裝到操作系統上的。而且必須要基於TLS 1.2版本協議(以百度爲例，最好使用chrome瀏覽器，其他的瀏覽器我沒找到查看TSL協議的版本號)。再來就是連接的加密方式要提供Forward Secrecy(FS正向保密，感興趣的筒子可以看看這個https://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html，－－！已經打不開了，支持Forward Secrecy的加密方式
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
)，文檔中羅列出了支持的加密算法（上面的原文中有說明，我把它獨立抽出來放到下面表格中查看）。最後就是證書至少要使用一個SHA256的指紋與任一個2048位或者更高位的RSA密鑰，或者是256位或者更高位的ECC密鑰。如果不符合其中一項，請求將被中斷並返回nil，簡單的說就是下面幾個要求：
1.Transport Layer Security協議版本要求TLS1.2以上
2.服務的Ciphers配置要求支持Forward Secrecy等
3.證書籤名算法符合ATS要求等
以上就是一次排查服務器的https是否符合ATS規格的方法，當然也可以使用下面的命令行一次性查詢：輸出結果都是pass的話就說明鏈接是支持ATS的。
nscurl --ats-diagnostics --verbose https://www.baidu.com
4.由於很多第三方的請求尚未適配https，所以iOS的ATS規格又分爲四大類
1.HTTPS Only （只有HTTPS，所有情況下都使用ATS）
顧名思義，這種情況不需要針對某一個域名或者站點做特殊處理，只要服務器的https符合ATS規格就可以了
2.Mix & Match（混合）
這種類型主要某些第三方的請求不支持https或者支持的https不符合ATS的情況：
2.1 在info.plist中添加這個配置項後，ATS當與這個子域交互的時候撤銷了必須使用HTTPS的要求(以友盟爲例)
2.2 當你請求的第三方服務器支持了https，但是不符合ATS規格，例如SSL版本低於1.2或者FS加密不符合要求的時候，可以做如下配置:
2.3 NSIncludesSubdomains 關鍵字告訴 App Transport Security 這個“例外”（Exception）適用於這個特定域名的所有子域。這個“例外”（Exception）還進一步通過擴展可接受的密碼列表來定義這個域名可以使用不支持forward secrecy( NSExceptionRequiresForwardSecrecy ) 協議的密碼。想了解更多關於forward secrecy的信息，推薦去看官方文檔 Apple's tech note
3. Opt Out（禁用ATS）
這個也是目前做法最廣泛的一種方式，把默認的請求的請求方式變成不安全的http，方法上面已經說過了。
4. Opt Out With Exceptions（除特殊情況外，都不使用ATS）
當你的應用撤消了App Transport Security,，但同時定義了一些“例外”(Exception)，指定了一個或多個“例外”（Exception）來表明哪些是必須要求 App Transport Security的。
