圖解HTTP之確保Web安全的HTTPS

在HTTP協(xié)議中有可能存在信息竊聽或身份偽裝等安全問題。使用HTTPS通信機制可以有效地防止這些問題。

1.HTTP的缺點

HTTP主要有這些不足,列舉如下:
通信使用名文,內(nèi)容可能會被竊聽
不驗證通信方的身份,因此有可能遭遇偽裝
無法證明報文的完整性,所以有可能已遭篡改
這些問題不僅在HTTP上出現(xiàn),其他未加密的協(xié)議也會存在這類問題。除此之外,HTTP本身有很多缺點。而且像某些特定的Web服務器和特定的Web瀏覽器在實際應用中存在的不足,另外,用Java和PHP等編程語言開發(fā)的Web應用也可能存在安全漏洞。為了有效防止這些弊端,有必要使用HTTPS。SSL提供認證和加密處理及摘要功能。僅靠HTTP確保完整性是非常困難的,因此通過和其他協(xié)議組合使用來實現(xiàn)這個目標。

2.HTTP+加密+認證+完整性保護=HTTPS

經(jīng)常會在Web的登錄頁面和購物結(jié)算等使用HTTPS通信。使用HTTPS通信時,不再用http://,而是改用https://。另外,當瀏覽器訪問HTTPS通信有效的Web網(wǎng)站時,瀏覽器的地址欄內(nèi)會出現(xiàn)一個帶鎖的標記。
HTTPS并非時應用層的一種新協(xié)議。只是HTTP通信接口部分用SSL和TLS協(xié)議代替而已。通常,HTTP直接和TCP通信,當使用SSL時,則演變成先和SSL通信,再由SSL和TCP通信了。SSL是獨立于HTTP的協(xié)議,所以不光是HTTP協(xié)議,其他運行在應用層的SMTP和Telnet等協(xié)議均可配合SSL協(xié)議使用??梢哉fSSL是當今世界上應用最為廣泛的網(wǎng)絡安全技術。

相互交互密鑰的公開密鑰加密技術

在對SSL進行講解之前,我們先來了解一下加密方法。SSL采用了一種叫做公開密鑰加密的加密處理方式。近代的加密方式中加密算法是公開的,而加密卻是保密的。通過這種方法得以保持加密方法得安全性。加密和解密都會用到密鑰。沒有密鑰就無法對密碼解密,反過來,任何人只要持有密鑰就能解密了,如果密鑰被攻擊者獲得,那加密也就失去了意義。

共享密鑰加密的困境

加密和解密用同一個密鑰的方式稱為共享密鑰加密,也被叫做對稱密鑰加密。以共享密鑰方式加密時必須將密鑰也發(fā)給對方。在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時,如果通信被監(jiān)聽,密鑰就可能落到攻擊者之手,也就失去了加密的意義。
使用兩把密鑰的公開密鑰加密
公開密鑰加密是一種非對稱的密鑰,一把叫做私有密鑰,一把叫做公開密鑰。使用公開密鑰加密方式,發(fā)送密文的一方使用對方的公開密鑰進行加密處理,對方在收到被加密的信息后,再使用自己的私有密鑰進行解密。利用這種方式,不需要發(fā)送用來解密的私有密鑰,也不必擔心密鑰被攻擊者竊聽而盜走。

HTTPS采用混合加密機制

HTTPS采用共享密鑰和公開密鑰加密兩者并用的混合加密機制。若密鑰能夠?qū)崿F(xiàn)安全交換,那么有可能考慮僅使用公開密鑰加密來通信。但是公開密鑰加密與共享密鑰加密相比,其處理速度要慢。所以應充分利用兩者各自的優(yōu)勢,將多種方法組合起來建立通信。在交換密鑰環(huán)節(jié)使用公開密鑰加密方式,之后的建立通信交換報文階段則使用共享密鑰加密方式。

證明公開密鑰正確性的證書

公開密鑰加密方式還是有一些問題,那就是無法證明公開密鑰本身就是貨真價實的公開密鑰,為了解決上述問題,可以使用由數(shù)字證書認證機構(CA,Certificate Authority)和其他相關機關頒發(fā)的公開密鑰證書。
數(shù)字證書認證機構處于客戶端和服務器雙方都可信賴的第三方機構的立場上。首先,服務器的運營人員向數(shù)字認證機構提出公開密鑰的申請。數(shù)字證書認證機構在判明提出申請者的身份之后,會對已申請的公開密鑰做數(shù)字簽名,然后分配這個已簽名的公開密鑰,并將該公開密鑰放入公鑰證書后綁定到一起。服務器會將這份由數(shù)字證書認證機構頒發(fā)的公鑰證書發(fā)送給客戶端,以進行公開密鑰加密方式通信,公鑰證書也叫做數(shù)字證書,接到證書的客戶端可使用數(shù)字證書認證機構的公開密鑰,對那張證書上的數(shù)字簽名進行驗證,一旦驗證通過,客戶端就可以明確兩件事:一,認證服務器的公開密鑰是真實有效的數(shù)字證書認證機構,二,服務器的公開密鑰是可信賴的。此處認證機關的公開密鑰如何安全的交給客戶端是個問題,因此,多數(shù)瀏覽器在開發(fā)商發(fā)布版本時,會事先植入常用認證機關的公開密鑰。

可證明組織真實性的EV SSL證書

證書的一個作用是用來證明作為通信一方的服務器是否規(guī)范,另外一個作用是確認對方服務器背后運營的企業(yè)是否真實存在,擁有該特性的證書就是EV SSL證書。

用以確認客戶端的客戶端證書

HTTPS中可以使用客戶端證書。以客戶端證書進行客戶端認證,證明服務器正在通信的對方始終是預料之內(nèi)的客戶端,其作用跟服務器證書如出一轍。例如,銀行的網(wǎng)上銀行就采用了客戶端證書。在登錄網(wǎng)銀時,不僅要求用戶確認輸入ID和密碼,還會要求用戶的客戶端證書,以確認用戶是否從特定的終端訪問網(wǎng)銀。

認證機構信譽第一

SSL機制中介入認證機構之所以可行,是建立在其信用絕對可靠的這一大前提下的,然后2011年發(fā)生在荷蘭的偽造證書事件從根本上撼動了SSL的可信度。因為偽造證書上有正規(guī)認證機構的數(shù)字簽名,所以瀏覽器會判定該證書是正當?shù)摹.攤卧斓淖C書被用作服務器偽裝時,用戶根本無法察覺,雖然存在將證書無效化的證書吊銷列表機制以及從客戶端刪除根證書頒發(fā)機構的對策,但距離生效期間還需要一段時間,在這段時間里有多少用戶蒙受損失就不得而知了。
由自認證機構頒發(fā)的證書稱為自簽名證書
即使使用自簽名證書,通過SSL加密之后,可能偶爾還會看見通信處在安全的狀態(tài)的提示,可那也是有問題的,因為就算加密通信,也不能排除正在和已經(jīng)通過偽裝的假服務器保持通信。

3.HTTPS的安全通信機制

1.客戶端通過發(fā)送Client Hello報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件列表(所使用的加密算法及密鑰長度等)。
2.服務器可進行SSL通信時,會以Server Hello報文作為應答。和客戶端一樣,在報文中包含SSL版本和加密組件,服務器的加密組件內(nèi)容是從客戶端加密組件列表內(nèi)篩選出來的。
3.服務器發(fā)送Certificate報文。報文中包含公開密鑰證書。
4.最后服務器發(fā)送Server Hello Done報文通知客戶端,最初階段的SSL握手協(xié)商部分結(jié)束
5.客戶端以Client Key Exchange報文作為回應。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文采用公開密鑰加密。
6.接著客戶端繼續(xù)發(fā)送Change Cipher Spec報文。該報文會提示服務器,在此報文之后的通信會采用Pre-master secret密鑰加密。
7.客戶端發(fā)送Finished報文,該報文包含連接至今的全部報文的整體較驗值。此次握手是否成功,取決于服務器是否正確解密該報文作為判斷標準。
8.服務器同樣發(fā)送Change Cipher Spec報文
9.服務器同樣發(fā)送Finished報文
10.SSL連接建立完成,當然,通信會收到SSL的保護,從此處開始進入應用層協(xié)議的通信,即發(fā)送HTTP請求。
11.應用層協(xié)議通信,即發(fā)送HTTP響應。
12??蛻舳藬嚅_連接,斷開時發(fā)送close_notify報文,這步之后發(fā)送TCP FIN報文來關閉與TCP的通信。
在以上流程中,應用層發(fā)送數(shù)據(jù)時會附加一種叫做MAC的報文摘要,MAC能夠查知報文是否遭到篡改,從而報文報文的完整性。

SSL和TLS

HTTPS使用SSL和TLS這兩個協(xié)議。SSL技術最初是由瀏覽器開發(fā)商網(wǎng)景通信公司倡導的,開發(fā)過SSL3.0之前的版本。目前由IETF(Internet Engineering Task Force,Internet工程任務組)的手中。
IETF以SSL3.0為基準,后制定了TLS1.0、TLS1.1、TLS1.2。TSL是以SSL為原型開發(fā)的協(xié)議,有時會統(tǒng)一稱該協(xié)議為SSL。當前的主流版本是SSL3.0和TLS1.0。

?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容