使用curl操作github API V3(2)

前面簡單講了對稱與非對稱兩種算法，后面還非對稱的逆過程就是簽名驗證過程過程。從中可以明顯看出，非對稱因為私鑰與公鑰的不同的，因此解密數(shù)據(jù)所需要的時間非常長，因此出現(xiàn)了第三種解密加密方案就是兩者結(jié)合起來進行加密。其思想也很簡單，就是利用各自的長處。如下圖所示：

顯然這里對稱加密的KEY被使用非對稱進行加密，這樣避免了全部數(shù)據(jù)的非對稱加密，又比較好的解決了對稱加密的KEY的傳遞問題。也就是上圖中的Session Key。上圖雖然解決了Session Key的傳輸問題，但是沒有解決產(chǎn)生問題。如何產(chǎn)生一個Session Key呢？當(dāng)然有些人說我自己隨機產(chǎn)生。當(dāng)然可以，那有什么方法可以產(chǎn)生一個唯一的KEY呢？當(dāng)然唯一KEY不能用在這里。但是前面簽名過程中，如果也使用上述思想，我不加密全部文件，我只加密部分文件，然后你能證明原文件一定是我的嗎？顯然這里需要一個唯一的KEY，如下圖所示：

在上面簽名認(rèn)證過程中，顯然我必須要保證message digest同plaintext是一一對應(yīng)的。那么如果做到這樣，顯然只有一種方法，就是HASH算法。目前HASH有兩種簡單，一種是MD5,一種是SHA1。HASH算法的原理比較簡單，但是存在一定的安全隱患。如下圖所示：

如上圖所示，HASH的結(jié)果在兩種算法中最終大小都是固定的，一個是16字節(jié)，一個20字節(jié)，而數(shù)據(jù)大小是不固定的，因此顯然可以想像就算一一對應(yīng)，固定大小的HASH結(jié)果只能對應(yīng)固定數(shù)量的數(shù)據(jù)，因此，如果說數(shù)據(jù)的數(shù)量是無限的話，那么HASH必然會出現(xiàn)重復(fù)。這就是他的缺陷。但是考慮到2的128次方也是一個很大的數(shù)字，所以通常情況下使用SHA1還是比較可靠的。如下圖所示：

前面講了非對稱加密中密鑰與公鑰的一一對應(yīng)性，那么顯然還有一點是沒有講清楚的，那就是公鑰的可信性。如果說公鑰是不可信的，因此解密的過程也是不可信的。那么如何保證可信性呢？

這可不是能用算法解決了信任問題，就像對稱加密中如何安全傳遞KEY一樣。必須一個可信任的渠道。這個渠道就是第三方公證。第三方有一個公開的人人可知的公鑰，但是第三方會對加密方的公鑰進行加密。這樣解密方用第三方公鑰首先解開這個加密的公鑰后，就可以認(rèn)證出是否是對應(yīng)的可信任的加密方公鑰。也就是說第三方首先為加密方簽發(fā)一個含有公鑰信息的數(shù)字簽名證書。如下圖所示：

也就是通常所講的CA證書。那么考慮到每一個想要通過非對稱傳遞信息的個人或組織都需要將自己公鑰拿到這個第三方認(rèn)證機制進行私鑰加密，那么其帶來的活動成本非常高，因此CA認(rèn)證也進行了分層管理。如下圖所示：

在這里ROOT CA首先要對下級進行認(rèn)證。然后用戶才能信任下級。這就形成了市面上的PKI框架概念。這里不在這里細(xì)述，但從上述解釋過程中，我們可以看出，從數(shù)據(jù)交換過程中，我們默認(rèn)是不信任對方的，正因為不信任對方，所以需要進行多重驗證才能消除不信任。從技術(shù)實現(xiàn)上一般是無法做到絕對的安全，所以需要具有一定公信力的機構(gòu)充當(dāng)中間人?？紤]到這里面涉及知識非常多，比喻AAA機制等，這里不再細(xì)述，但是我為什么題目是CURL操作GITHUP但是實際上絮絮叨叨了這么多其它東東呢。這是因為前面這些是安全的基礎(chǔ)。不管是目前IPSEC/SSH/SSL等其實現(xiàn)的最基本的原理就是這兩類，對稱加密和非對稱加密。當(dāng)然大部分都是后者。所謂萬變不理其宗，不管是IPSEC/SSH/SSL/HTTPS/PGP都是在通信過程中加上加密模塊進行安全數(shù)據(jù)傳輸。那么這些不同的都是怎么實現(xiàn)的呢？首先我們看SSL，因為HTTPS依賴于SSL。所以理解了SSL就理解了HTTPS。SSL雖然是一個協(xié)議，但是我們首先來猜一下，基于我們前面學(xué)到的知識。首先我們肯定會想SSL肯定不會用對稱加密算法，那么就是非對稱加密算法，那么非對稱加密，很顯然需要進行公鑰交換和雙方加密解密算法統(tǒng)一。那么怎么信任對方呢？顯然是證書，證書怎么發(fā)放怎么驗證呢？這就是SSL協(xié)議定義的事情，因為SSL已經(jīng)解決了這些安全問題，所以基于HTTP進行安全擴展成HTTPS就非常方便。那么首先看一下SSL協(xié)議棧如下所示：

從上面可以SSL實際上是一個應(yīng)用層協(xié)議，正因為是應(yīng)用層協(xié)議，所以根本不需要修改TCP/IP協(xié)議棧，不像IPSEC需要借助OS功能進行IP層修改。也就是說他借助其它協(xié)議進行傳輸，只是對這些協(xié)議建議一個遂道傳輸。通常包括以下四種子協(xié)議：握手協(xié)議，交換cipher spec，alter protocol,record layer.那我們看他是怎么實現(xiàn)這個過程的，如下圖所示：

從上面兩個圖中可以看出，首先服務(wù)端與客戶端配置好SSL所需要的公鑰、證書等（因為這是一個雙向通信，所以雙方都需要），客戶端選擇一個加密解密方法告訴服務(wù)端。服務(wù)端也可以確定后然后告訴客戶端。當(dāng)這個過程結(jié)束后，基于應(yīng)用層的隧道就建好了，比喻說HTTP數(shù)據(jù)就可以通過這個隧道進行傳輸了。那么HTTP是怎么變成HTTPS呢？比喻常見的APACHE服務(wù)器怎么變成HTTPS呢？

這是因為APACHE有一個SSL模塊插件。到此為止，SSL協(xié)議應(yīng)該是比較清楚了，但是還有一個概念經(jīng)?；煜褪荢SLV2,SSLV3,SSLV3.1,TLSV1 PCT等，首先SSLV2,V3好理解是SSL的不同版本，主要是為了解決專利問題和一些內(nèi)部問題。PCT是微軟實現(xiàn)的，SSL是由NETSCAP 實現(xiàn)的，現(xiàn)在最主要使用的是OPENSSL實現(xiàn)。那么TLSV1又是什么呢？其實就是SSLV3.1,只是他是由IETF制定的。其目的是集兩家之長做成的一個協(xié)議，不是完全兼容SSL以前版本。其它的WTLS是MOBILE上的TLS，基于UDP。