从ATS开始-学习笔记Part1
升级到了xCode7,第一次打开工程,虽然有了心理准备,但是心理仍然拔凉拔凉的.
几十个error(Swift1.2->2.0).修改完毕后,兴匆匆的Command+R,登陆失败=.=.
经过一番查找,原来是ATS的锅,于是有了ATS的学习笔记.
ATS
也就是App Transport Security,略显高大上的名字.意思就是说从iOS9开始会默认使用https进行数据访问.没有经过配置的工程使用http的时候无法访问数据.
当然ATS有一些独特的要求(Server):
- Transport Layer Security协议版本要求TLS1.2以上
- 服务的Ciphers配置要求支持Forward Secrecy等
- 证书签名算法符合ATS要求等
感觉好麻烦,我们更关心到底怎么办~是全面修改为https还是想办法适配http呢?
苹果提供了4种处理策略,通过Plist进行配置
- 全部使用https
- 部分使用https
- 部分不使用https
- 全部不使用https
策略1:需要符合ATS的相关规范
策略2:在plist中配置列表:哪些需要用到https
策略3:在plist中配置例外的列表:那些不需要https
策略4:在plist中申明则http又可以工作啦~所以...
相关plist关键字涉及到NSAllowsArbitraryLoads等,上方文档中有较为详细的介绍.
Https
非官方不准确的理解为加密的http.名字上就是http over s(secure socket layer),也就是信息加密过后的http.
和http相比,https因为信息加过了密,所以优势在于安全,第三方无法截获(截获后无法查看),也无法伪造.
当然劣势在于,性能肯定要差点,因为有加密解密的过程.
ATS使用TSL1.2协议,https中s的基础也就是TSL协议.
主要流程在于客户端发送请求前的四次握手,交换证书,随机数,协议等.然后通过RSA用公钥算法生成密钥,然后通过密钥加密信息.服务端通过私钥解开信息的密钥,然后用密钥解开信息.
握手阶段主要目的在于交换和验证信息,让双方保持可靠.
加密阶段分为两个部分.第一个部分为通讯内容加密,使用对称加密方式,需要一个密钥.而这个密钥也需要加密,不然会被人截取,所以使用RSA的方式进行加密.
然后就是普通的http传输了.既然是http传输,那么信息当然可以被截取.不过截取到的信息因为加过密,所以第三方也读不懂,也没办法伪造,所以就安全了.
握手
- 客户端告诉服务端:我的协议版本(ATS需要TSL1.2),我的加密方式(RSA),我的随机数(第一个随机数)
- 服务端收到了以后,告诉客户端:确认协议版本(如果不支持客户端的协议版本,则通信关闭),确认加密方式,服务端的随机数(第二个随机数),证书
- 客户端会收到证书,证书非常重要,其中包含了服务端的公钥(RSA相关).然后告诉服务端:一切ok,准备通信,在发送一个随机数(第三个随机数)
- 服务端收到了随机数后,通过以上3个随机数,生成了一个密钥,发送给了客户端.而这个密钥就是随后加密通信内容的密钥.
剩下的就是http通信了,只是将通信内容通过这个密钥加密了.
有个小小的问题,为什么要有3个随机数,服务端自己生成一个不可以吗?
原因是目前随机数算法都是伪随机,一旦随机数算法被破解,那么一切都可能会被破解.而三个随机数作用起来,被破解的可能性就非常小了.
加密
加密分为2个部分,握手阶段最重要的事情就是生成一个密钥,用来加密通信内容.
而有了这个密钥,通信内容通过对称加密的方式加密,然后就是普通的http方式传输了.
那么问题来了,为什么需要用2种加密方式呢.
生成密钥通过RSA,加密通讯内容使用DES.
- 无法单独使用RSA的原因是:该方法一是非常慢,因为其加密原理.二是对加密内容有一定要求,无法加密过长的内容.(实际上不是这个意思,加密内容是把内容转为ascii码,太长会导致这个ascii码组成的数字太大,RSA无法加密太大的数字.)
- 无法单独使用DES加密的原因是:因为传输过程中,是http.所以密钥在传输过程中是明文,会被获取.
所以结合双方有点使用,完美的解决了这个问题.
RSA
非对称加密的一种算法.具体数学原理参考:
略显复杂.
大概意思就是说,这种算法有一个公钥,一个密钥.公钥公开,私钥自己拿着.通过公钥加密的东西可以用私钥解开,通过私钥加密的东西也可以通过公钥解开.
这种算法安全的原因是基于一个比较基础的原理:人类目前暂时很难分解2个很大的素数的乘积.1024位2进制的私钥基本安全,2048位的私钥就目前而言是非常安全的.
所以在TSL中,通过该方法使用公钥加密DES的密钥,那么密钥就非常安全了.然后通过私钥解开这个加密过后的密钥,就能拿到密钥本身了.在通过密钥本身,就能解开信息内容本身了.
问题又来了,既然是需要通过公钥来加密,那么公钥在哪里?
在证书里.在握手的时候,服务端会给客户端证书,证书就包含了公钥.
证书
通过证书包含的公钥以及服务端的私钥,可以确保通信内容的加密解密.
问题继续来,为什么一定要给个证书呢,直接给公钥不行么?
不行.
公钥私钥只能证明这一套配套,能互相解开对方加密的信息.但是没有办法证明这个公钥属于谁.或许服务器被入侵,公钥私钥被人替换了,也无法得知.
所以就有了数字证书这个东西.找个第三方(CA)公正,把你的私人信息(公钥)进行加密,做成一张数字证书.用什么东西加密?用第三方(CA)的私钥.
当然,这件事情是要收费的...
操作系统等会有一个CA的信任列表,使用CA的公钥解开数字证书,再通过列表对比,则会确认该证书是否是伪造的.
