写在前面，因为是踩坑记，所以基本上是按着自己遇到的坑写上去的，没有整理，可能嫌的很乱，写下来只是为了加深下印象。
之前以为自己是懂https的，但是这两天折腾了一下后，发现都是止于表面。所以记录一下这两天踩过的坑。
首先，之前的服务器其实就已经是支持https的了，然后当时苹果刚推出ATS的时候，浏览了相关教程，错误的理解到如果服务器购买了https证书，就等于支持了https，然后app端就不需要做任何适配的工作，苹果做好了一切。又同时一直以来，app都能正常跟后台打交道，所以认为这个错误的理解是正确的，就没管了。直到昨天，服务器证书过期，并且从之前的绑定域名转到直接绑定IP访问，就出现了一系列的踩坑，填坑过程了。。。
服务器证书过期，但是app还能正常请求接口，只是不能访问图片，视频等资源，查证之后发现，原来工程plist里面一直都把NSAllowsArbitraryLoads设置为YES，禁用ATS了。没多久，服务器部署新证书后，把NSAllowsArbitraryLoads设置为NO，打开app，没想到竟一直报SSL验证错误，突然想死的心都有了。然后把报错信息贴到度娘，看了半天发现都还是千篇一律的说把policy的允许自签证书设为YES等等。因为之前对https的理解都是止于表面，所以没想太多，把代码复制上去，还是失败。心想不行，还是重头认识下https吧。
第一时间想到了陈宜龙大神写的一篇ios9网络适配_ats改用更安全的https，马上开撸，经历了之前的挖坑，心烦带意燥，第一遍没看太细，没得到答案，然后又分心找度娘了，后来再看第二遍，发现漏掉了很重要的东西，而且也是文章多次提到的东西“forward secrecy协议”，开始以为这是购买https证书自带的，所以没留意，后来度娘了一下，发现这也得后台配置，后台不配置的话，plist文件得声明暂不支持这个协议，果不其然，按文章步骤配置之后，app正常访问了。文章里面提到
nscurl --verbose --ats-diagnostics https://#your server name
这句命令可以查看服务器是否符文ATS标准，会返回不同ATS配置下请求https的结果，可以按照这个返回结果配置项目的plist。
横向开拓，度娘了一下“forward secrecy协议”，大概意思是即便服务器私钥丢了，也不会泄漏之前用私钥加密得到会话密钥来加密的数据，称之为向前保密协议。
然后再次横向开拓，度娘了下中间人攻击，就是两个主机发起通信，被中间人截获，中间人就可以伪造信息，或者监听双方信息，信息就泄漏了。同时也提到了发起中间人攻击很重要的一个步骤就是ARP欺骗。
横向开拓，度娘了ARP协议，(Address Resolution Protocol,地址解析协议）是根据IP地址获取物理地址的一个TCP/IP协议，主机发送信息时，将包含目标地址的IP地址的ARP请求广播到局域网中，局域网中的主机接收到ARP请求匹配自己的IP地址，如果匹配不成功就丢弃，如果匹配成功，就保存源主机的IP地址和MAC地址到本地ARP缓存中，并返回一个包含本机MAC地址的响应给源主机，源主机也把目标主机的MAC地址缓存到本地的ARP缓存中，下次发送信息时，就可以直接从缓存读取。因为OSI模型把网络工作分为7层，IP地址在第三层网络层，MAC地址在第二层数据链路层，所以需要把IP解析成MAC地址，才能顺利执行网络访问。
那ARP欺骗呢，因为主机把ARP请求广播到局域网的时候，任何主机都可以响应，并且源主机并不会验证响应的主机是否为目的主机，所以就出现ARP欺骗了。源主机信任了伪造的主机，伪造的主机就可以发起中间人攻击了。
防止ARP欺骗，提到了IP地址跟MAC地址静态绑定，启用ARP防火墙，查看ARP缓存是否正常等等。
那防止中间人攻击呢？就是https的作用了。https采用非对称加密，提供一个私钥和公钥?？突Ф朔梦逝渲胔ttps的服务器时，服务器会返回公钥，然后客户端把请求的数据列表和一个对称加密的密钥使用公钥加密传到服务器，服务器利用私钥解密得到数据和对称加密的密钥把数据使用对称加密返回给客户端，客户端解密得到数据，完成交互。因为中间人不知道私钥，所以即便拦截到请求也不能解密。其中也涉及到数字签名的概念，如果中间人伪装了证书，返回了一个假的证书并跟客户端说，这是服务器的安全证书，请用这个公钥匙加密，欢迎享用?？突Ф诵湃瘟撕?，数据也还是会发给到这个中间人的服务器，中间人也采用同样的措施跟服务器打交道，就还是GG了。所以数字签名的目的就是创建一个权威的标记，贴到安全证书上“这个证书得到ynot的认证，是安全的”，客户端才会信任，颁发这个数字签名的机构就是CA，根CA可以认证子CA，子CA也可以颁发数字签名，有了CA的认证，第三方就不能伪造证书了。最坏的结果就是如果CA机构因为自己掌握的权力而伪造证书，那么这就是TLS的中间人攻击了。
手里掌握权力的人，只有道德能够防止他做坏事
这里有一个有趣的例子，可能有助于理解。什么是 TLS 中间人攻击？如何防范这类攻击？
经过这两天挖坑，我的理解是，https所做的，或者网络安全所做的就是通过一系列验证，确保通信双方我是我，你是你之后，才进行进一步的数据传输。PS：最近好长一段时间断断续续在做Jenkins的CI，也是踩了好多坑，等完成之后，再总结一篇。
