前面簡(jiǎn)單講了對(duì)稱(chēng)與非對(duì)稱(chēng)兩種算法，后面還非對(duì)稱(chēng)的逆過(guò)程就是簽名驗(yàn)證過(guò)程過(guò)程。從中可以明顯看出，非對(duì)稱(chēng)因?yàn)樗借€與公鑰的不同的，因此解密數(shù)據(jù)所需要的時(shí)間非常長(zhǎng)，因此出現(xiàn)了第三種解密加密方案就是兩者結(jié)合起來(lái)進(jìn)行加密。其思想也很簡(jiǎn)單，就是利用各自的長(zhǎng)處。如下圖所示：
顯然這里對(duì)稱(chēng)加密的KEY被使用非對(duì)稱(chēng)進(jìn)行加密，這樣避免了全部數(shù)據(jù)的非對(duì)稱(chēng)加密，又比較好的解決了對(duì)稱(chēng)加密的KEY的傳遞問(wèn)題。也就是上圖中的Session Key。上圖雖然解決了Session Key的傳輸問(wèn)題，但是沒(méi)有解決產(chǎn)生問(wèn)題。如何產(chǎn)生一個(gè)Session Key呢？當(dāng)然有些人說(shuō)我自己隨機(jī)產(chǎn)生。當(dāng)然可以，那有什么方法可以產(chǎn)生一個(gè)唯一的KEY呢？當(dāng)然唯一KEY不能用在這里。但是前面簽名過(guò)程中，如果也使用上述思想，我不加密全部文件，我只加密部分文件，然后你能證明原文件一定是我的嗎？顯然這里需要一個(gè)唯一的KEY，如下圖所示：
在上面簽名認(rèn)證過(guò)程中，顯然我必須要保證message digest同plaintext是一一對(duì)應(yīng)的。那么如果做到這樣，顯然只有一種方法，就是HASH算法。目前HASH有兩種簡(jiǎn)單，一種是MD5,一種是SHA1。HASH算法的原理比較簡(jiǎn)單，但是存在一定的安全隱患。如下圖所示：
如上圖所示，HASH的結(jié)果在兩種算法中最終大小都是固定的，一個(gè)是16字節(jié)，一個(gè)20字節(jié)，而數(shù)據(jù)大小是不固定的，因此顯然可以想像就算一一對(duì)應(yīng)，固定大小的HASH結(jié)果只能對(duì)應(yīng)固定數(shù)量的數(shù)據(jù)，因此，如果說(shuō)數(shù)據(jù)的數(shù)量是無(wú)限的話，那么HASH必然會(huì)出現(xiàn)重復(fù)。這就是他的缺陷。但是考慮到2的128次方也是一個(gè)很大的數(shù)字，所以通常情況下使用SHA1還是比較可靠的。如下圖所示：
前面講了非對(duì)稱(chēng)加密中密鑰與公鑰的一一對(duì)應(yīng)性，那么顯然還有一點(diǎn)是沒(méi)有講清楚的，那就是公鑰的可信性。如果說(shuō)公鑰是不可信的，因此解密的過(guò)程也是不可信的。那么如何保證可信性呢？
這可不是能用算法解決了信任問(wèn)題，就像對(duì)稱(chēng)加密中如何安全傳遞KEY一樣。必須一個(gè)可信任的渠道。這個(gè)渠道就是第三方公證。第三方有一個(gè)公開(kāi)的人人可知的公鑰，但是第三方會(huì)對(duì)加密方的公鑰進(jìn)行加密。這樣解密方用第三方公鑰首先解開(kāi)這個(gè)加密的公鑰后，就可以認(rèn)證出是否是對(duì)應(yīng)的可信任的加密方公鑰。也就是說(shuō)第三方首先為加密方簽發(fā)一個(gè)含有公鑰信息的數(shù)字簽名證書(shū)。如下圖所示：
也就是通常所講的CA證書(shū)。那么考慮到每一個(gè)想要通過(guò)非對(duì)稱(chēng)傳遞信息的個(gè)人或組織都需要將自己公鑰拿到這個(gè)第三方認(rèn)證機(jī)制進(jìn)行私鑰加密，那么其帶來(lái)的活動(dòng)成本非常高，因此CA認(rèn)證也進(jìn)行了分層管理。如下圖所示：
在這里ROOT CA首先要對(duì)下級(jí)進(jìn)行認(rèn)證。然后用戶才能信任下級(jí)。這就形成了市面上的PKI框架概念。這里不在這里細(xì)述，但從上述解釋過(guò)程中，我們可以看出，從數(shù)據(jù)交換過(guò)程中，我們默認(rèn)是不信任對(duì)方的，正因?yàn)椴恍湃螌?duì)方，所以需要進(jìn)行多重驗(yàn)證才能消除不信任。從技術(shù)實(shí)現(xiàn)上一般是無(wú)法做到絕對(duì)的安全，所以需要具有一定公信力的機(jī)構(gòu)充當(dāng)中間人?？紤]到這里面涉及知識(shí)非常多，比喻AAA機(jī)制等，這里不再細(xì)述，但是我為什么題目是CURL操作GITHUP但是實(shí)際上絮絮叨叨了這么多其它東東呢。這是因?yàn)榍懊孢@些是安全的基礎(chǔ)。不管是目前IPSEC/SSH/SSL等其實(shí)現(xiàn)的最基本的原理就是這兩類(lèi)，對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密。當(dāng)然大部分都是后者。所謂萬(wàn)變不理其宗，不管是IPSEC/SSH/SSL/HTTPS/PGP都是在通信過(guò)程中加上加密模塊進(jìn)行安全數(shù)據(jù)傳輸。那么這些不同的都是怎么實(shí)現(xiàn)的呢？首先我們看SSL，因?yàn)镠TTPS依賴于SSL。所以理解了SSL就理解了HTTPS。SSL雖然是一個(gè)協(xié)議，但是我們首先來(lái)猜一下，基于我們前面學(xué)到的知識(shí)。首先我們肯定會(huì)想SSL肯定不會(huì)用對(duì)稱(chēng)加密算法，那么就是非對(duì)稱(chēng)加密算法，那么非對(duì)稱(chēng)加密，很顯然需要進(jìn)行公鑰交換和雙方加密解密算法統(tǒng)一。那么怎么信任對(duì)方呢？顯然是證書(shū)，證書(shū)怎么發(fā)放怎么驗(yàn)證呢？這就是SSL協(xié)議定義的事情，因?yàn)镾SL已經(jīng)解決了這些安全問(wèn)題，所以基于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層修改。也就是說(shuō)他借助其它協(xié)議進(jìn)行傳輸，只是對(duì)這些協(xié)議建議一個(gè)遂道傳輸。通常包括以下四種子協(xié)議：握手協(xié)議，交換cipher spec，alter protocol,record layer.那我們看他是怎么實(shí)現(xiàn)這個(gè)過(guò)程的，如下圖所示：
從上面兩個(gè)圖中可以看出，首先服務(wù)端與客戶端配置好SSL所需要的公鑰、證書(shū)等（因?yàn)檫@是一個(gè)雙向通信，所以雙方都需要），客戶端選擇一個(gè)加密解密方法告訴服務(wù)端。服務(wù)端也可以確定后然后告訴客戶端。當(dāng)這個(gè)過(guò)程結(jié)束后，基于應(yīng)用層的隧道就建好了，比喻說(shuō)HTTP數(shù)據(jù)就可以通過(guò)這個(gè)隧道進(jìn)行傳輸了。那么HTTP是怎么變成HTTPS呢？比喻常見(jiàn)的APACHE服務(wù)器怎么變成HTTPS呢？
這是因?yàn)锳PACHE有一個(gè)SSL模塊插件。到此為止，SSL協(xié)議應(yīng)該是比較清楚了，但是還有一個(gè)概念經(jīng)常混淆，就是SSLV2,SSLV3,SSLV3.1,TLSV1 PCT等，首先SSLV2,V3好理解是SSL的不同版本，主要是為了解決專(zhuān)利問(wèn)題和一些內(nèi)部問(wèn)題。PCT是微軟實(shí)現(xiàn)的，SSL是由NETSCAP 實(shí)現(xiàn)的，現(xiàn)在最主要使用的是OPENSSL實(shí)現(xiàn)。那么TLSV1又是什么呢？其實(shí)就是SSLV3.1,只是他是由IETF制定的。其目的是集兩家之長(zhǎng)做成的一個(gè)協(xié)議，不是完全兼容SSL以前版本。其它的WTLS是MOBILE上的TLS，基于UDP。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專(zhuān)為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。
重慶分公司
重慶分公司
