28.双向HTTPS认证201710

好久没有写文章了,今天写下HTTPS的内容,加深下自己的理解

一、https工作原理
HTTPS其实是有两部分组成:HTTP + SSL / TLS,
也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密,所以传输的数据都是加密后的数据。

PS:SSL / TLS就是安全证书,SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全(Transport Layer Security,TLS)是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。

二、图文解说https


28.双向HTTPS认证201710_第1张图片
图片.png

咋看一下,有点懵逼。还好有解释。
个人先解释几点:
crt表示证书
crypt加密
decrypt解密

  1. 客户端发起HTTPS请求

这个没什么好说的,就是用户在浏览器里输入一个https网址,然后连接到server的443端口。

  1. 服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择,有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解,可以想象成一把钥匙和一个锁头,只是全世界只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。

  1. 传送证书

这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。

PS:服务端发送一个证书给客户端,把它想象成一个没上锁的箱子

  1. 客户端解析证书

这部分工作是有客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。如果证书没有问题,那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。
PS:客户查看箱子没什么问题,就把属于自己的没有上锁的小箱子放到这个大箱子里面,然后把大箱子上锁。

  1. 传送加密信息

这部分传送的是用证书加密后的随机值,目的就是让服务端得到这个随机值key,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

  1. 服务段解密信息

服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密。所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。

PS;服务器拿回来自己的大箱子,用自己的钥匙打开,发现里面有一个没上锁的小箱子。把要传输的内容,放到小箱子里面,顺便再放一个更小的箱子没上锁的,这样只有客户端才能打开。

  1. 传输加密后的信息

这部分信息是服务段用私钥加密后的信息,可以在客户端被还原。

  1. 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容。整个过程第三方即使监听到了数据,也束手无策。


二、AFNetwork 3.0下的SSL
在app的开发中因为我们的app通常只需要和一个服务器端进行交互,所以不必要每次请求都从服务器那边获取证书(公钥),在开发中app直接将服务器对应生成的证书(公钥)放在沙盒中,HTTPS请求时只要直接和服务器返回的证书(公钥)进行比对。如果验证通过则使用公钥进行加密在传递回服务器。
这样即使app中的证书(公钥)被截取,中间人使用证书冒充了服务器与客户端进行通信时(通过了验证),但因为从app返回的数据都是通过证书(公钥)加密的。而中间人从app截取的证书时公钥,缺少对应的私钥即使截获了信息也无法解密。能够最大的程度的保护传递的信息安全。

从上面的通信过程中,最重要的是存储在服务器的私钥。因为只有私钥生成了在通信过程中传递的证书(公钥),且只有通过私钥才能对公钥加密的信息进行解密,所以在开发过程中保护好私钥的安全。

苹果已经封装了HTTPS连接的建立、数据的加密解密功能,我们直接可以访问https网站的,但苹果并没有验证证书是否合法,无法避免中间人攻击。要做到真正安全通讯,需要我们手动去验证服务端返回的证书。AFNetwork中的AFSecurityPolicy模块主要是用来验证HTTPS请求时证书是否正确。 AFSecurityPolicy封装了证书验证的过程,让用户可以轻易使用,除了去系统信任CA机构列表验证,还支持SSL Pinning方式的验证。

PS:再次说下SSL Pinning方式的验证

AFSecurityPolicy模块包括四大组成:

SSLPinningMode

pinnedCertificates

allowInvalidCertificates

validatesDomainName

@property (nonatomic, strong, nullable) NSSet *pinnedCertificates
根据验证模式来返回用于验证服务器的证书。

@property (nonatomic, assign) BOOL allowInvalidCertificates
属性代表是否允许不信任的证书(证书无效、证书时间过期)通过验证 ,默认为NO.

@property (nonatomic, assign) BOOL validatesDomainName
是否验证域名证书的CN(common name)字段。默认值为YES。

@property (readonly, nonatomic, assign) AFSSLPinningMode SSLPinningMode
验证证书的模式:
AFSSLPinningModeNone: 这个模式表示不做SSL pinning,只跟浏览器一样在系统的信任机构列表里验证服务端返回的证书。若证书是信任机构签发的就会通过,若是自己服务器生成的证书,这里是不会通过的。
AFSSLPinningModeCertificate:这个模式表示用证书绑定方式验证证书,需要客户端保存有服务端的证书拷贝,这里验证分两步,第一步验证证书的域名/有效期等信息,第二步是对比服务端返回的证书跟客户端返回的是否一致。
AFSSLPinningModePublicKey:这个模式同样是用证书绑定方式验证,客户端要有服务端的证书拷贝,只是验证时只验证证书里的公钥,不验证证书的有效期等信息。

PS:我用的就是这个AFSSLPinningModeCertificate,以前的旧版本不知道有没有问题,自建的证书快过期了,

你可能感兴趣的:(28.双向HTTPS认证201710)