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

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長期合作伙伴，公司提供的服務(wù)項(xiàng)目有：主機(jī)域名、虛擬空間、營銷軟件、網(wǎng)站建設(shè)、自貢網(wǎng)站維護(hù)、網(wǎng)站推廣。

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

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

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

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

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

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

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

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

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

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