使用curl操作github API V3(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。