使用curl操作githubAPIV3(2)

前面简单讲了对称与非对称两种算法，后面还非对称的逆过程就是签名验证过程过程。从中可以明显看出，非对称因为私钥与公钥的不同的，因此解密数据所需要的时间非常长，因此出现了第三种解密加密方案就是两者结合起来进行加密。其思想也很简单，就是利用各自的长处。如下图所示：

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：主机域名、虚拟空间、营销软件、网站建设、自贡网站维护、网站推广。

显然这里对称加密的KEY被使用非对称进行加密，这样避免了全部数据的非对称加密，又比较好的解决了对称加密的KEY的传递问题。也就是上图中的Session Key。上图虽然解决了Session Key的传输问题，但是没有解决产生问题。如何产生一个Session Key呢？当然有些人说我自己随机产生。当然可以，那有什么方法可以产生一个唯一的KEY呢？当然唯一KEY不能用在这里。但是前面签名过程中，如果也使用上述思想，我不加密全部文件，我只加密部分文件，然后你能证明原文件一定是我的吗？显然这里需要一个唯一的KEY，如下图所示：

在上面签名认证过程中，显然我必须要保证message digest同plaintext是一一对应的。那么如果做到这样，显然只有一种方法，就是HASH算法。目前HASH有两种简单，一种是MD5,一种是SHA1。HASH算法的原理比较简单，但是存在一定的安全隐患。如下图所示：

如上图所示，HASH的结果在两种算法中最终大小都是固定的，一个是16字节，一个20字节，而数据大小是不固定的，因此显然可以想像就算一一对应，固定大小的HASH结果只能对应固定数量的数据，因此，如果说数据的数量是无限的话，那么HASH必然会出现重复。这就是他的缺陷。但是考虑到2的128次方也是一个很大的数字，所以通常情况下使用SHA1还是比较可靠的。如下图所示：

前面讲了非对称加密中密钥与公钥的一一对应性，那么显然还有一点是没有讲清楚的，那就是公钥的可信性。如果说公钥是不可信的，因此解密的过程也是不可信的。那么如何保证可信性呢？

这可不是能用算法解决了信任问题，就像对称加密中如何安全传递KEY一样。必须一个可信任的渠道。这个渠道就是第三方公证。第三方有一个公开的人人可知的公钥，但是第三方会对加密方的公钥进行加密。这样解密方用第三方公钥首先解开这个加密的公钥后，就可以认证出是否是对应的可信任的加密方公钥。也就是说第三方首先为加密方签发一个含有公钥信息的数字签名证书。如下图所示：

也就是通常所讲的CA证书。那么考虑到每一个想要通过非对称传递信息的个人或组织都需要将自己公钥拿到这个第三方认证机制进行私钥加密，那么其带来的活动成本非常高，因此CA认证也进行了分层管理。如下图所示：

在这里ROOT CA首先要对下级进行认证。然后用户才能信任下级。这就形成了市面上的PKI框架概念。这里不在这里细述，但从上述解释过程中，我们可以看出，从数据交换过程中，我们默认是不信任对方的，正因为不信任对方，所以需要进行多重验证才能消除不信任。从技术实现上一般是无法做到绝对的安全，所以需要具有一定公信力的机构充当中间人。考虑到这里面涉及知识非常多，比喻AAA机制等，这里不再细述，但是我为什么题目是CURL操作GITHUP但是实际上絮絮叨叨了这么多其它东东呢。这是因为前面这些是安全的基础。不管是目前IPSEC/SSH/SSL等其实现的最基本的原理就是这两类，对称加密和非对称加密。当然大部分都是后者。所谓万变不理其宗，不管是IPSEC/SSH/SSL/HTTPS/PGP都是在通信过程中加上加密模块进行安全数据传输。那么这些不同的都是怎么实现的呢？首先我们看SSL，因为HTTPS依赖于SSL。所以理解了SSL就理解了HTTPS。SSL虽然是一个协议，但是我们首先来猜一下，基于我们前面学到的知识。首先我们肯定会想SSL肯定不会用对称加密算法，那么就是非对称加密算法，那么非对称加密，很显然需要进行公钥交换和双方加密解密算法统一。那么怎么信任对方呢？显然是证书，证书怎么发放怎么验证呢？这就是SSL协议定义的事情，因为SSL已经解决了这些安全问题，所以基于HTTP进行安全扩展成HTTPS就非常方便。那么首先看一下SSL协议栈如下所示：

从上面可以SSL实际上是一个应用层协议，正因为是应用层协议，所以根本不需要修改TCP/IP协议栈，不像IPSEC需要借助OS功能进行IP层修改。也就是说他借助其它协议进行传输，只是对这些协议建议一个遂道传输。通常包括以下四种子协议：握手协议，交换cipher spec，alter protocol,record layer.那我们看他是怎么实现这个过程的，如下图所示：

从上面两个图中可以看出，首先服务端与客户端配置好SSL所需要的公钥、证书等（因为这是一个双向通信，所以双方都需要），客户端选择一个加密解密方法告诉服务端。服务端也可以确定后然后告诉客户端。当这个过程结束后，基于应用层的隧道就建好了，比喻说HTTP数据就可以通过这个隧道进行传输了。那么HTTP是怎么变成HTTPS呢？比喻常见的APACHE服务器怎么变成HTTPS呢？

这是因为APACHE有一个SSL模块插件。到此为止，SSL协议应该是比较清楚了，但是还有一个概念经常混淆，就是SSLV2,SSLV3,SSLV3.1,TLSV1 PCT等，首先SSLV2,V3好理解是SSL的不同版本，主要是为了解决专利问题和一些内部问题。PCT是微软实现的，SSL是由NETSCAP 实现的，现在最主要使用的是OPENSSL实现。那么TLSV1又是什么呢？其实就是SSLV3.1,只是他是由IETF制定的。其目的是集两家之长做成的一个协议，不是完全兼容SSL以前版本。其它的WTLS是MOBILE上的TLS，基于UDP。