从HTTPS到CER

之前一直对HTTPS有些理解囹圄，最近有时间，就花了2天时间深挖一下。

在学习某种技术方案的时候，我一般会对比着另外一种技术方案，这次没有例外HTTPS VS HTTP。这两种都是协议，而且在计算机七层协议中，算是应用层协议，算是顶层协议了。什么是应用层协议呢？举个简单的例子，张三写了一串数字20190719 1730 1108 3014，他把这段数字的解码格式告诉李四：前8位数字表示日期，第9到12位表示时间，13到16表示房号，17到20表示座位号。然后李四就根据这个解码方式得到“在2019年7月19日13：30 到11楼08房找3014号桌的人”。只有知道这套协议的人才能正式解码数字的意思，那么王五就拿到这段数据肯定会一脸蒙圈。那么协议就是张三跟李四说的那套解码格式。当然你会问，为什么需要这种协议，直接说人话不就好了么？那其实你有没有发现那串数字远比它代表的完整的意思的字数要少许多。
那应用层协议中的应用层是什么意思？那就要先说说传输层协议了。传输层协议的主要代表是TCP/UDP。至于TCP和UDP两者的区别我就不说了。传输层协议负责数据的收/发,计算机会将用户数据全部塞到传输协议中，传输层把数据打包好，转成0-1信号，在光纤中疯狂跑起来，到达目标设备的时候，传输层会根据协议，将用户数据又卸下来，然后继续疯狂地收发。这些用户数据就是来自应用层，传输层和应用层是分开独立的，一个只负责搬运数据，一个只负责打包数据，那么在我们的大部分见解中TCP负责帮运HTTP或HTTPS数据，不过到了HTTP3的时候，好像搬运工是UDP。如果大家有做过物联网项目，就会对这个概念更加清晰了。不过以上描述忽略了很多细节，协议不会就是一种这么简单的限定，它还有数据校验，数据拼接等等的作用。
Http和Https都是应用层协议，他们之间的区别前者不加密数据，而后者加密了。就是如果使用Http的话，张三的那串数据20190719 1730 1108 3014就会按着他原始的数据被打包起来。但是在Https的话，它可能打包成了DRW354T68E23472，就是一串被经过加密后得到的数据，而且这数据让普通人无法掌握到规律，只有拿到密钥的人才能把它转译得到原始数据。而在这段加密解密的过程中SSL(TSL)协议扮演着很重要的角色。

SSL

既然知道Https = Http + SSL，那么我们着重研究SSL就好了。SSL协议过程使用了两种类别的加密算法：对称加密与非对称加密。使用对称加密算法来加密用户数据，使用非对称加密算法来加密对称加密的密钥。那么为什么要用两种，两种不同算法在这里扮演什么角色呢？

-对称加密

对称加密，即是使用相同的密钥来加密和解密数据，关键的点是相同的密钥。如果加密和解密的双方都知道密钥，那就很容易达成这件事情，不过对于互联网来说，你张三（服务端）可能只有一个，但李四（前端）确有千千万万，你怎么确保张三一定隐秘地把密钥（K）分发给这些形形色色的李四人物呢？那你就要看非对称加密了。

-非对称加密

非对称加密，即是加密和解密方无需使用相同的密钥，在该算法体系中，将这些不相同的密钥称为：私钥与公钥。那么私钥，是不能公开的，公钥你可以广而告知，也就是张三（服务端）自己保留私钥（S），千千万万个李四（前端）能拿到公钥（P）。公钥加密的东西只有私钥能解开，私钥加密的东西公钥也能解开，但是公钥加密的东西，公钥不可能解开，就是这么神奇。那么张三就可以把公钥P给到李四，然后张三在通过私钥S去加密 对称加密所需的密钥K，然后把加密数据传个李四，李四再拿公钥P解密得到 对称加密密钥K。至此，张三和李四都拿到了K，就可以加密传输用户数据了。那么现在来了两个问题：

• 既然非对称能加密解密数据，为什么在传输用户数据的时候不直接使用非对称加密？
• 万一张三给李四传输公钥P的时候，王五拦截了，然后把自己的公钥P1给了李四，那是不是接着王五也可以把对称加密密钥K更改为自己的K2，传给李四。然后李四发来数据的时候，就可以解密李四的数据呢？

解答第一个问题：非对称加密有数据长度限制，算法效率比较低，一般不太适合用于普通的网络数据加密中，大部分用在签名过程。

解答第二个问题，请客官查看接下来的CA证书。

-第三方CA

既然担心公钥被篡改，那我们就得找JC了，而在互联网中充当公钥保驾护航的第三方机构就是扮演者JC的角色。它的工作内容如下：

• 张三（服务端）请求第三方证书CA机构生成可认证的证书，而证书的内容包含签发者姓名，机构，hash算法，签名算法和过期时间等。
• CA 也是用非对称加密的办法。首先将这些信息，通过has算法得到has值，然后拿自己的私钥S-CA去加密has值，has算法和张三的公钥P。最后打包原始内容和加密信息得到P-CA数据给到张三。
• 张三拿到P-CA数据后，把它传给李四。李四电脑预装了CA机构的公钥（一般系统安装初期或者安装浏览器的时候会植入到电脑中），则使用这个公钥去解密P-CA数据，得到has算法和has值之后，再拿has算法对P-CA中原始数据进行运算得到has值，最后将运算的has值与解密得到的has值对比，如果不匹配，则证明证书非法。否则验证成功，并且取下公钥。

设想，如果王五从中拦截，修改加密内容或者自己也向CA机构请求另一个证书在发给李四，会发生什么问题？首先修改加密内容，导致李四无法用CA的公钥解密；如果是取代证书的方式，则由于王五向CA机构申请证书的时候产生的公钥和私钥对，与张三申请的时候产生的私钥和密钥对不一致，导致李四的CA公钥无法解密王五的CA证书，验证失败。

-证书CER

张三向第三方请求证书的时候，其实就是申请cer文件的过程。就我们iOS开发者日常接触最多的就是开发证书，生产证书，推送证书等等。
如果你记得的话，我们在Mac book中申请证书的时候，首先是打开钥匙串管理工具，然后点击从第三方CA机构请求证书，最后生成一个CSR文件，并且会把证书的公钥和私钥都保留在了电脑本地（你可以查看要是串工具的keys菜单列，看看有没有多了一对公钥/私钥）。最后上传到开发者中心，到处cer文件到本地，安装到钥匙串。你会发现每个cer文件下都会有一个私钥对应着的，明显的是cer保留着公钥。
那么在开发过程中，我们需要那cer文件做代码签证，xcode会读取cer文件，也就是读取公钥。XCode在代码签证的时候，会拿到这个公钥和钥匙串的私钥去进行验证，如果密码对不符合，则会签名失败。

当然我们也看到过p12这样的文件，其实你可以理解为私钥的加密文件。你可以吧p12传给别人，别人就获得你的私钥。这个p12经常用到的地方是两个：

• APNS推送。
• 多开发者合作。
  第一种其实就是给提供后台私钥，然后后台通过该私钥加密数据传给APNS服务器，APNS通过开发者平台的cer文件中的公钥，解密数据，然后传给苹果手机，相反也是可行的。
  第二种 其实就是到出私钥给第三人并安装到钥匙串，然后第三人再从公司苹果开发者平台下载对应的cer文件，也安装到钥匙串，这样xcode就可以把两者都匹配到一起。