在苹果全球开发者大会上，苹果规定2017年1月1日以后，App Store 当中的所有应用必须打开ATS（iOS9中新增App Transport Security（简称ATS）特性），在启用 ATS 之后，它会强制应用通过 HTTPS（而不是 HTTP）连接网络服务，这能够通过加密来保障用户数据安全。所以，所有APP都要使用HTTPS进行网络请求，否则不能上架。
在iOS9的时候，还可以关闭ATS使用HTTP，现在到年底之前不行了。是时候该改用HTTPS了。
最近研究了一下iOS中使用HTTPS实现请求，以及证书怎么生成，在介绍之前，为了更好的理解证书的特性，在这里我梳理了数字证书和互联网信息传递的安全体系方面的知识，也算是自己的一些总结笔记。
说到数字证书不得不先了解各种加解密算法和摘要算法。目前加密方法可以分两大类。一类是单钥加密，也称作是对称加密，还有一类就是双钥加密，也称作非对称加密。数字证书是基于非对称，摘要算法的，其中的核心就是非对称加密算法了。
加密算法
对称加密
对称加密指加密和解密使用相同密钥的加密算法。在大多数的对称算法中，加密密钥和解密密钥是相同的，所以也称这种加密算法为单密钥算法。
在应用该算法时，它要求发送方和接收方在安全通信之前，商定一个密钥。对称算法的安全性依赖于密钥，泄漏密钥就意味着任何人都可以对他们发送或接收的消息解密，所以密钥的保密性对通信性至关重要。对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。不足之处是，交易双方都使用同样钥匙，安全性得不到保证。
常见的对称加密算法有DES，AES，RC4，IDEA等。
非对称加密
与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥和私有密钥；并且加密密钥和解密密钥是成对出现的。在双钥体系中，公钥用来加密信息，私钥用来数字签名。
非对称加密的特性
- 对于一个公钥，有且只有一个对应的私钥。
- 公钥是公开的，并且不能通过公钥反推出私钥。
- 通过私钥加密的密文只能通过公钥能解密，通过公钥加密的密文也只能通过私钥能解密。
通过公钥是极难推算出私钥的，只能通过穷举，所以只要密钥足够长，要想从公钥推算出私钥几乎不可能的。
非对称加密不需要共享同一份秘钥，安全性要比对称加密高，但由于算法强度比对称加密复杂，加解密的速度比对称加解密的速度要慢。因此，在实际使用中，往往与对称加密和摘要算法结合使用。
常见的非对称加密算法有RSA，DSA，Diffie-Hellman，ECC等。
对称加密和非对称加密的区别
两者的主要区别就是是否使用同一个秘钥，对称加密需要用同一个秘钥。非对称加密不需要用同一个秘钥，而是需要两个秘钥：公开密钥和私有密钥，并且加密密钥和解密密钥是成对出现的。
发布者用公钥加密数据，然后把加密数据发布出去，接收者拿到数据后用私钥解密就可以看到真实内容。即使黑客抓包截获加密数据，没有私钥就无法解出内容。也就是只要私钥没有泄露，数据就是安全的。但有种情况是可能黑客拿到了公钥，他不能解密数据，但可以用拿到的公钥加密伪造数据，这时候接收者拿到的就是被篡改的数据了。
为了防止数据信息发布后不被篡改和数据的完整性，就需要用到数字签名了。
在双钥体系中，公钥用来加密信息，私钥用来数字签名。
数字签名
数字签名就是对非对称加密和摘要算法的一种应用。先来介绍下摘要算法：
摘要算法
摘要算法是将任意长度的一块数据转换为一个定长的、不可逆转的数字，其长度通常在128～256位之间。除了加密算法，摘要算法在互联网安全体系中也扮演了重要的角色。摘要算法具有以下特性：
- 只要源文本不同，计算得到的结果，必然不同（或者说机会很少）。
- 无法从结果反推出源数据（那是当然的，不然就能量不守恒了）。
基于以上特性，我们一般使用摘要算法来校验原始内容是否被篡改。常见的摘要算法有 MD5、SHA 等。
摘要算法用于对比信息源是否一致，因为只要源数据发生变化，得到的摘要必然不同。因为通常结果比源数据要短很多，所以称为“摘要”。
签名
这时候就要利用摘要算法无法还原出原来内容的特性了。
为了防止发布内容中途被篡改，发布者可以通过摘要算法提取发布内容的摘要，用私钥加密之得到密文即签名，这时候将加密内容、签名以及公钥一起发布出去。
接收者收到数据时，首先验证公钥是否是发布者的公钥，然后用公钥对密文进行解密，得到摘要，使用发布者对文本同样的摘要算法得到摘要文本，比对摘要是否一致即可确认信息是否被篡改或者是指定发布者发布的。
发布方
接受方
再次强调摘要算法的特性，只要源数据改变，经摘要算法后得到的摘要必然不同，而且是不可逆的，不能还原反推出原始数据。
如果黑客抓取到签名和公钥，还用公钥解密签名得到摘要，不知道摘要算法就还原不了原始数据，最不济黑客解密了内容，并篡改了，势必摘要会跟随改变，黑客拿伪造的内容和截获的签名发出去的时候，此时接收者计算出来的摘要签名必然跟这个签名不匹配。这就验证了是否被篡改了。
源代码的签名
这是我们兄弟会源代码平台的请求和返回规范。所有当前的项目的接口请求基本都采用这种规范，使用到了我们规定了的一套签名算法。前面沙龙群技术分享也有提到过，但是后来不少朋友还有很多传输过程中的安全疑问。
- 每一次发出的请求（Request）里含有一些参数，包括用这些参数生成的签名signature。
- 其中客户端跟服务端用同样的算法生成签名的。客户端把算好的签名跟其他参数一起传给服务器，服务器把拿到的参数用同样的算法生成签名，然后用这个签名和客户端传过来的签名对比来判断数据是否被篡改。
- 如果抓取到传输的数据，势必要变换业务参数，一旦参数变动签名就会变，如果不知道签名的算法，服务端签名验证必然不能通过，而且这个算法也有维护，周期变换规则，不仅要防止外部破解，也要防止内部离职的人员泄漏。
- 具体的加密算法和规则，前面我们的沙龙技术分享也提供了一个范本给大家，需要的朋友可以在技术群里找客服索取，也可以直接找我。
任何的加密措施，在一定程度都有被破解的可能，我们要做的就是增加破解的难度和成本。
到目前为止还有个风险就是接收者拿到的公钥被替换了成了黑客的公钥，接收者这时候被认为是可以接收黑客的数据的。黑客用自己的私钥做了数字签名，然后发布数据给接收者，接收者用黑客的公钥解密。这样接收者还是会受到被篡改的数据。
数字证书就是来解决这个问题的。
数字证书
现实生活中的证书是由权限机构颁发的证明，比如毕业证等。一般的证书都有机构的公章，通过这个公章来验证证书的合法性。问题就在这个公章，公章是可以造假的，那么证书就是假的。但是在我们的数字证书中，数字签名是没办法伪造的。
数字证书就是通过数字签名实现的数字化的证书，在现实生活中公章可以被伪造，但是在计算数字世界中，数字签名是没办法被伪造的。数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公钥的文件。数字证书里一般会包含公钥、公钥拥有者名称、CA（签发证书机构统称为CA） 的数字签名、有效期、授权中心名称、证书序列号等信息。
接着前面，那怎么判断数字证书列出的用户就是公钥的拥有者呢？（前面这个公钥可能被黑客替换）
发布证书的时候，先用私钥对文件的摘要信息进行签名，将签名和证书文件一起发布，这样能保证证书无法被伪造。验证证书是否合法时，首先用公钥（机构颁发的证书的公钥是公开的，谁都可以获取到）对签名解密得到摘要信息，另外用同样的摘要算法得到证书的另一个摘要信息，对比两个摘要信息是否一致就可以判定该证书是否合法，可以信任的。
数字证书也有很多的签发机构，不同的签发机构签发的证书，用途也是不一样的，比如iOS开发中，使用到的ipa文件签名证书，需要到苹果申请。而在Web访问中为了防止Web内容在网络中安全传输，需要用到的SSL证书则需要向几家公认的机构签发。这些签发机构统称为CA（Certificate Authority）。
Web访问相关的证书可以向国际公认的几个机构：WebTrust，GlobalSign，GTE，Nortel，Verisign。
我这里贴一张MAC里面的证书管理，受信任的根证书颁发机构，客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。
HTTPS证书
HTTPS中密钥交换用的就是非对称加密的保密特性来实现的。
目前有2中方法得到HTTPS证书：
- 第三方认证的颁发CA证书(推荐)
- 自己制作证书(这种不知道能不能满足苹果的审核)
直接购买收费的证书最省事了，也比较安全，推荐这种方法。还可以自己制作证书，但不知道能否通过苹果的审核，只有等到1月份上架APP的时候测试了。问了身边几个朋友，基本上都还没有支持HTTPS，后面有机会再分享一下怎么自己制作证书，通不通的过也算是一种尝试了。
总结
数字签名和数字证书是两个不同的概念，理解的关键点是数字签名是内容提供方用自己的私钥对内容摘要（MD5、SHA）非对称加密，而数字证书的关键是 CA 用自己的私钥对证书内容的摘要非对称加密从而确保证书内的用户合法拥有证书里列出的公钥。
有一篇国外的很好的文章,它用图片通俗易懂地解释了，"数字签名"（digital signature）和"数字证书"（digital certificate）到底是什么。中文的翻译在这里。
在这里简单的介绍了数字证书和一些加密算法，很多详细更深入的东西还没涉及，比如非对称加密算中用的最广的RSA算法原理和加密与破解，还有HTTPS秘钥协商过程等，有兴趣的朋友可以更深入的学习下。