iOS - HTTPS接口加密和身份认证

为何要使用HTTPS代替HTTP

HTTPS和HTTP的区别

https协议须要到CA申请证书，通常免费证书不多，须要交费。
http是超文本传输协议，信息是明文传输，https则是具备安全性的SSL加密传输协议。
http和https使用的是彻底不一样的链接方式，用的端口也不同，前者是80，后者是443。
http的链接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

 

HTTP为何不安全

http协议没有任何的加密以及身份验证的机制，很是容易遭遇窃听、劫持、篡改，所以会形成我的隐私泄露，恶意的流量劫持等严重的安全问题。

就像寄信同样，我给你寄信，中间可能会通过不少的邮递员，他们能够拆开信读取里面的内容，由于是明文的。若是你的信里涉及到了大家银行帐号等敏感信息，可能就会被窃取。除此以外，邮递员们还能够给你伪造信的内容，致使你遭到欺骗。

 

HTTPS如何保证安全

HTTPS是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，所以加密的详细内容就须要SSL。它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。https:URL代表它使用了HTTPS，但HTTPS存在不一样于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司进行，提供了身份验证与加密通信方法，如今它被普遍用于万维网上安全敏感的通信，例如交易支付方面。

 

HTTPS的加密原理

首先先介绍一些加密过程当中用到的原理：

对称加密

对称加密是指加密和解密使用相同密钥的加密算法。它要求发送方和接收方在安全通讯以前，商定一个密钥。对称算法的安全性依赖于密钥，泄漏密钥就意味着任何人均可以对他们发送或接收的消息解密，因此密钥的保密性对通讯相当重要。

对称加密算法的优、缺点：

优势：算法公开、计算量小、加密速度快、加密效率高。

缺点：

交易双方都使用一样钥匙，安全性得不到保证；
每对用户每次使用对称加密算法时，都须要使用其余人不知道的唯一钥匙，这会使得发收信双方所拥有的钥匙数量呈几何级数增加，密钥管理成为用户的负担。
能提供机密性，可是不能提供验证和不能否认性。

 

非对称加密算法

这种加密或许理解起来比较困难，这种加密指的是能够生成公钥和私钥。凡是公钥加密的数据，公钥自身不能解密，而须要私钥才能解密；凡是私钥加密的数据，私钥不能解密，须要公钥才能解密。这种算法事实上有不少，经常使用的是RSA，其基于的数学原理是两个大素数的乘积很容易算，而拿到这个乘积去算出是哪两个素数相乘就很复杂了，具体原理有兴趣能够自行研究。

非对称加密相比对称加密更加安全，但也存在两个明显缺点：

CPU计算资源消耗很是大。一次彻底TLS握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只至关于非对称加密的0.1%，若是应用层数据也使用非对称加解密，性能开销太大，没法承受。
非对称加密算法对加密内容的长度有限制，不能超过公钥长度。好比如今经常使用的公钥长度是2048位，意味着待加密内容不能超过256个字节。

 

因此公钥加密目前只能用来做密钥交换或者内容签名，不适合用来作应用层传输内容的加解密。

身份认证（CA数字证书）

https协议中身份认证的部分是由数字证书来完成的，证书由公钥、证书主体、数字签名等内容组成，在客户端发起SSL请求后，服务端会将数字证书发给客户端，客户端会对证书进行验证，并获取用于秘钥交换的非对称密钥。

数字证书有两个做用：

身份受权。确保浏览器访问的网站是通过CA验证的可信任的网站。
分发公钥。每一个数字证书都包含了注册者生成的公钥。在SSL握手时会经过certificate消息传输给客户端。

 

申请一个受信任的数字证书一般有以下流程：

终端实体（能够是一个终端硬件或者网站）生成公私钥和证书请求。
RA（证书注册及审核机构）检查实体的合法性。若是我的或者小网站，这一步不是必须的。
CA（证书签发机构）签发证书，发送给申请者。
证书更新到repository（负责数字证书及CRL内容存储和分发），终端后续从repository更新证书，查询证书状态等。

 

数字证书验证：

申请者拿到CA的证书并部署在网站服务器端，那浏览器发起握手接收到证书后，如何确认这个证书就是CA签发的呢？怎样避免第三方伪造这个证书？答案就是数字签名（digital signature）。数字签名是证书的防伪标签，目前使用最普遍的SHA-RSA（SHA用于哈希算法，RSA用于非对称加密算法）数字签名的制做和验证过程以下：

数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，而后使用CA本身的私钥对消息摘要进行加密。
数字签名的校验。使用CA的公钥解密签名，而后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较，若是相同就认为校验成功。

 

 

须要注意的是：

1. 数字签名签发和校验使用的密钥对是CA本身的公私密钥，跟证书申请者提交的公钥没有关系。
2. 数字签名的签发过程跟公钥加密的过程恰好相反，便是用私钥加密，公钥解密。
3. 如今大的CA都会有证书链，证书链的好处一是安全，保持根CA的私钥离线使用。第二个好处是方便部署和撤销，即若是证书出现问题，只须要撤销相应级别的证书，根证书依然安全。
4. 根CA证书都是自签名，即用本身的公钥和私钥完成了签名的制做和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。
5. 怎样获取根CA和多级CA的密钥对？它们是否可信？固然可信，由于这些厂商跟浏览器和操做系统都有合做，它们的公钥都默认装到了浏览器或者操做系统环境里。

加密的详细过程

首先服务器端用非对称加密（RSA）产生公钥和私钥。而后把公钥发给客 户端，路径或许有人会截取，可是没有用，由于用公钥加密的文件只有私钥能够解密，而私钥永远都不会离开服务器的。当公钥到达客户端以后，客户端会用对称加密产生一个秘钥而且用公钥来加密发送给服务器端，这个秘钥就是之后用来通讯的钥匙。这样服务器端收到公钥加密的秘钥时就能够用私钥来解公钥从而得到秘钥。这样的话客户端和服务器端都得到了秘钥，信息交流相对是安全的。流程图以下：

听起来确实是挺安全的，但实际上，还有一种更恶劣的攻击是这种方法无 法防范的，这就是传说中的“中间人攻击”。在身份认证的过程当中，出现了一个“中间人”拦截咱们的信息，他有意想要知道大家的消息。咱们将这个中间人称为M。当服务器第一次给客户端发送公钥的时候，途径M。M知道你要进行密钥交换了，它把公钥扣了下来，伪装本身是客户端，伪造了一个伪秘钥（对称加密产生的），而后用服务器发来的公钥加密了伪秘钥发还给服务器，这样服务器觉得和客户端完成了密钥交换，实际上服务器是和M完成了密钥交换（得到了伪秘钥）。同时M假扮成服务器自行用非对称加密产生伪公钥和伪私钥，与客户端进行秘钥交换，拿到客户端发送过来的秘钥。如今客户端拿着秘钥，M拿着秘钥和为伪秘钥，服务器拿着伪秘钥，整个交流的过程就是：

简单点说就是：

1. 客户端用秘钥加密信息发送给M；
2. M收到后用秘钥解密拿到信息，而后用伪秘钥加密信息发送给服务器；
3. 服务器收到后用伪秘钥解密拿到信息。

这样中间人M就拿到了客户端和服务器全部的交流信息。

对于这种攻击，咱们能够加上身份认证：这个时候就要引入CA证书，CA证书的原理可回到2.1.3。数字证书中包括的主要内容有：证书拥有者的我的信息、证书拥有者的公钥、公钥的有效期、颁发数字证书的CA、CA的数字签名等。因此网上双方通过相互验证数字证书后，不用再担忧对方身份的真伪，能够放心地与对方进行交流或授予相应的资源访问权限。

通俗一点理解就是，服务器端把公钥交个CA证书，CA证书再包装一层。（具体原理请回看2.3）而后再发给客户端，这个包装一层的意思是：保证这个证书是我（服务器）给你（客户端的），其余人拿到了也没有用。

最后，你可能会想既然非对称加密能够那么安全，为何咱们不直接用它来加密信息，而是用来加密对称加密的密钥呢？

这是由于非对称加密的密码对生成和加密的消耗时间比较长，为了节省双方的计算时间，一般只用它来交换密钥，而非直接用来传输数据（具体的可看上文非对称加密的缺点）。

使用AFNetworking进行双向认证

客户端认证服务器端证书

如上图所示客户端想要认证服务器，首先须要和服务端的数字证书匹配（server.cer），具体方法以下。

1. 在项目中导入证书sever.cer和AFNetworking框架：
2. 而后到AFSecurityPolicy.m中重写
3. 重写

 

 

1 2 3

+ (instancetype)policyWithPinningMode:(AFSSLPinningMode)pinningMode

方法：

AFNetworking2是容许内嵌证书的，经过内嵌证书，AFNetworking2经过比对服务器端证书、内嵌的证书、站点域名是否一致来验证链接的服务器是否正确。在完成以上两条的状况下，会自动扫描bundle中.cer的文件，并引入，这样就能够经过自签证书来验证服务器惟一性了。

服务器端认证客户端

1. 服务端验证客户端证书，首先把服务端的证书client.p12导入到服务端的密钥库里，同时导入工程；
2. 在AFURLConnectionOperation.m中加入如下方法：

1. 重写AFURLConnectionOperation.m中的- (void)connection:(NSURLConnection*)connection

若是是须要认证的时候不会先调用didReceiveResponse，而是先调用3）和2）的函数，NSURLAuthenticationChallenge是一个认证挑战类，也就是要求客户端进行挑战，要接收挑战也就是客户端提供挑战的凭证(用户和密码，或者客户端证书，或者信任服务器证书，或者代理)，IOS提供了一个NSURLCredential的类来表示挑战凭证。能够经过以下函数来创建挑战凭证。因此访问https的时候服务器认证客户端就调用这个方法。

这两段代码是经过p12文件来验证服务器的，须要本身修改的地方只有一个，那就是2）中的CFStringRefpassword =CFSTR("123456");这是p12证书的密码，用本身的p12证书密码替换"123456"。

控制器里如何请求

经过4.1和4.2咱们的客户端和服务器双向认证已经设置好了，在控制器里只须要须要调用

 

1 2 3

manager.securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModePublicKey];

的方法来进行双向认证：

而后就能够访问HTTPS的服务器了。