為您解碼網(wǎng)站建設(shè)的點點滴滴
發(fā)表日期:2017-04 文章編輯:小燈 瀏覽次數(shù):2471
什么是HTTPS
HTTPS(全稱:Hypertext Transfer Protocol over Secure Socket Layer),是以安全為目標的HTTP通道,簡單講是HTTP的安全版。即HTTP下加入SSL層,HTTPS的安全基礎(chǔ)是SSL,因此加密的詳細內(nèi)容就需要SSL。
HTTPS的作用
內(nèi)容加密,建立一個信息安全通道,來保證數(shù)據(jù)傳輸?shù)陌踩?/p>
身份認證,確認網(wǎng)站的真實性。
數(shù)據(jù)完整性,防止內(nèi)容被第三方冒充或者篡改。
HTTPS和HTTP的區(qū)別
HTTPS協(xié)議需要到CA申請證書。
HTTP是超文本傳輸協(xié)議,信息是明文傳輸;HTTPS則是具有安全性的SSL加密傳輸協(xié)議。
HTTP和HTTPS使用的是完全不同的連接方式。
HTTP默認使用80端口,HTTPS默認使用443端口。
HTTP的連接很簡單,是無狀態(tài)的。HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議,比HTTP協(xié)議安全。
下面就是HTTPS的整個架構(gòu),現(xiàn)在的HTTPS基本都使用TLS了,因為更加安全,所以下圖中的SSL應(yīng)該換為SSL/TLS。
HTTPS層次結(jié)構(gòu)
HTTPS層次結(jié)構(gòu)
對稱加密
對稱加密(也叫私鑰加密)指加密和解密使用相同密鑰的加密算法。有時又叫傳統(tǒng)密碼算法,就是加密密鑰能夠從解密密鑰中推算出來,同時解密密鑰也可以從加密密鑰中推算出來。而在大多數(shù)的對稱算法中,加密密鑰和解密密鑰是相同的,所以也稱這種加密算法為秘密密鑰算法或單密鑰算法。
常見的對稱加密有:DES(Data Encryption Standard)、AES(Advanced Encryption Standard)、RC4、IDEA。
非對稱加密
與對稱加密算法不同,非對稱加密算法需要兩個密鑰:公開密鑰(publickey)和私有密鑰(privatekey);并且加密密鑰和解密密鑰是成對出現(xiàn)的。非對稱加密算法在加密和解密過程使用了不同的密鑰,非對稱加密也稱為公鑰加密,在密鑰對中,其中一個密鑰是對外公開的,所有人都可以獲取到,稱為公鑰,其中一個密鑰是不公開的稱為私鑰。
非對稱加密算法對加密內(nèi)容的長度有限制,不能超過公鑰長度。比如現(xiàn)在常用的公鑰長度是 2048 位,意味著待加密內(nèi)容不能超過 256 個字節(jié)。
摘要算法
數(shù)字摘要是采用單項Hash函數(shù)將需要加密的明文“摘要”成一串固定長度(128位)的密文,這一串密文又稱為數(shù)字指紋,它有固定的長度,而且不同的明文摘要成密文,其結(jié)果總是不同的,而同樣的明文其摘要必定一致。“數(shù)字摘要“是HTTPS能確保數(shù)據(jù)完整性和防篡改的根本原因。
數(shù)字簽名
數(shù)字簽名技術(shù)就是對“非對稱密鑰加解密”和“數(shù)字摘要“兩項技術(shù)的應(yīng)用,它將摘要信息用發(fā)送者的私鑰加密,與原文一起傳送給接收者。接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息,然后用HASH函數(shù)對收到的原文產(chǎn)生一個摘要信息,與解密的摘要信息對比。如果相同,則說明收到的信息是完整的,在傳輸過程中沒有被修改,否則說明信息被修改過,因此數(shù)字簽名能夠驗證信息的完整性。 數(shù)字簽名的過程如下: 明文 --> hash運算 --> 摘要 --> 私鑰加密 --> 數(shù)字簽名。
數(shù)字簽名有兩種功效:
能確定消息確實是由發(fā)送方簽名并發(fā)出來的,因為別人假冒不了發(fā)送方的簽名。
數(shù)字簽名能確定消息的完整性。
注意: 數(shù)字簽名只能驗證數(shù)據(jù)的完整性,數(shù)據(jù)本身是否加密不屬于數(shù)字簽名的控制范圍。
數(shù)字證書
為什么要有數(shù)字證書?
對于請求方來說,它怎么能確定它所得到的公鑰一定是從目標主機那里發(fā)布的,而且沒有被篡改過呢?亦或者請求的目標主機本本身就從事竊取用戶信息的不正當行為呢?這時候,我們需要有一個權(quán)威的值得信賴的第三方機構(gòu)(一般是由政府審核并授權(quán)的機構(gòu))來統(tǒng)一對外發(fā)放主機機構(gòu)的公鑰,只要請求方這種機構(gòu)獲取公鑰,就避免了上述問題的發(fā)生。
數(shù)字證書的頒發(fā)過程
用戶首先產(chǎn)生自己的密鑰對,并將公共密鑰及部分個人身份信息傳送給認證中心。認證中心在核實身份后,將執(zhí)行一些必要的步驟,以確信請求確實由用戶發(fā)送而來,然后,認證中心將發(fā)給用戶一個數(shù)字證書,該證書內(nèi)包含用戶的個人信息和他的公鑰信息,同時還附有認證中心的簽名信息(根證書私鑰簽名)。用戶就可以使用自己的數(shù)字證書進行相關(guān)的各種活動。數(shù)字證書由獨立的證書發(fā)行機構(gòu)發(fā)布,數(shù)字證書各不相同,每種證書可提供不同級別的可信度。
證書包含哪些內(nèi)容
證書頒發(fā)機構(gòu)的名稱。
證書本身的數(shù)字簽名。
證書持有者公鑰。
證書簽名用到的Hash算法。
驗證證書的有效性
瀏覽器默認都會內(nèi)置CA根證書,其中根證書包含了CA的公鑰:
證書頒發(fā)的機構(gòu)是偽造的:瀏覽器不認識,直接認為是危險證書
證書頒發(fā)的機構(gòu)是確實存在的,于是根據(jù)CA名,找到對應(yīng)內(nèi)置的CA根證書、CA的公鑰。用CA的公鑰,對偽造的證書的摘要進行解密,發(fā)現(xiàn)解不了,認為是危險證書。
對于篡改的證書,使用CA的公鑰對數(shù)字簽名進行解密得到摘要A,然后再根據(jù)簽名的Hash算法計算出證書的摘要B,對比A與B,若相等則正常,若不相等則是被篡改過的。
證書可在其過期前被吊銷,通常情況是該證書的私鑰已經(jīng)失密。較新的瀏覽器如Chrome、Firefox、Opera和Internet Explorer都實現(xiàn)了在線證書狀態(tài)協(xié)議(OCSP)以排除這種情形:瀏覽器將網(wǎng)站提供的證書的序列號通過OCSP發(fā)送給證書頒發(fā)機構(gòu),后者會告訴瀏覽器證書是否還是有效的。
1、2點是對偽造證書進行的,3是對于篡改后的證書驗證,4是對于過期失效的驗證。
SSL 與 TLS
SSL (Secure Socket Layer,安全套接層)。
SSL為Netscape所研發(fā),用以保障在Internet上數(shù)據(jù)傳輸之安全,利用數(shù)據(jù)加密(Encryption)技術(shù),可確保數(shù)據(jù)在網(wǎng)絡(luò)上之傳輸過程中不會被截取,當前為3.0版本。
SSL協(xié)議可分為兩層:SSL記錄協(xié)議(SSL Record Protocol):它建立在可靠的傳輸協(xié)議(如TCP)之上,為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。 SSL握手協(xié)議(SSL Handshake Protocol):它建立在SSL記錄協(xié)議之上,用于在實際的數(shù)據(jù)傳輸開始前,通訊雙方進行身份認證、協(xié)商加密算法、交換加密密鑰等。
TLS (Transport Layer Security,傳輸層安全協(xié)議)
用于兩個應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。 TLS 1.0是IETF(Internet Engineering Task Force,Internet工程任務(wù)組)制定的一種新的協(xié)議,它建立在SSL 3.0協(xié)議規(guī)范之上,是SSL 3.0的后續(xù)版本,可以理解為SSL 3.1,它是寫入了 RFC 的。該協(xié)議由兩層組成: TLS 記錄協(xié)議(TLS Record)和 TLS 握手協(xié)議(TLS Handshake)。較低的層為 TLS 記錄協(xié)議,位于某個可靠的傳輸協(xié)議(例如 TCP)上面。
SSL/TLS協(xié)議作用:
認證用戶和服務(wù)器,確保數(shù)據(jù)發(fā)送到正確的客戶機和服務(wù)器。
加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取。
維護數(shù)據(jù)的完整性,確保數(shù)據(jù)在傳輸過程中不被改變。
TLS比SSL的優(yōu)勢
對于消息認證使用密鑰散列法:TLS 使用“消息認證代碼的密鑰散列法”(HMAC),當記錄在開放的網(wǎng)絡(luò)(如因特網(wǎng))上傳送時,該代碼確保記錄不會被變更。SSLv3.0還提供鍵控消息認證,但HMAC比SSLv3.0使用的(消息認證代碼)MAC 功能更安全。
增強的偽隨機功能(PRF):PRF生成密鑰數(shù)據(jù)。在TLS中,HMAC定義PRF。PRF使用兩種散列算法保證其安全性。如果任一算法暴露了,只要第二種算法未暴露,則數(shù)據(jù)仍然是安全的。
改進的已完成消息驗證:TLS和SSLv3.0都對兩個端點提供已完成的消息,該消息認證交換的消息沒有被變更。然而,TLS將此已完成消息基于PRF和HMAC值之上,這也比SSLv3.0更安全。
一致證書處理:與SSLv3.0不同,TLS試圖指定必須在TLS之間實現(xiàn)交換的證書類型。
特定警報消息:TLS提供更多的特定和附加警報,以指示任一會話端點檢測到的問題。TLS還對何時應(yīng)該發(fā)送某些警報進行記錄。
SSL、TLS的握手過程
SSL與TLS握手整個過程如下圖所示,下面會詳細介紹每一步的具體內(nèi)容:
SSL、TLS的握手流程圖
HTTPS握手流程圖
客戶端首次發(fā)出請求
由于客戶端(如瀏覽器)對一些加解密算法的支持程度不一樣,但是在TLS協(xié)議傳輸過程中必須使用同一套加解密算法才能保證數(shù)據(jù)能夠正常的加解密。在TLS握手階段,客戶端首先要告知服務(wù)端,自己支持哪些加密算法,所以客戶端需要將本地支持的加密套件(Cipher Suite)的列表傳送給服務(wù)端。除此之外,客戶端還要產(chǎn)生一個隨機數(shù),這個隨機數(shù)一方面需要在客戶端保存,另一方面需要傳送給服務(wù)端,客戶端的隨機數(shù)需要跟服務(wù)端產(chǎn)生的隨機數(shù)結(jié)合起來產(chǎn)生后面要講到的 Master Secret 。
客戶端需要提供如下信息:
支持的協(xié)議版本,比如TLS 1.0版。
一個客戶端生成的隨機數(shù),稍后用于生成”對話密鑰”。
支持的加密方法,比如RSA公鑰加密。
支持的壓縮方法。
服務(wù)端首次回應(yīng)
服務(wù)端在接收到客戶端的Client Hello之后,服務(wù)端需要確定加密協(xié)議的版本,以及加密的算法,然后也生成一個隨機數(shù),以及將自己的證書發(fā)送給客戶端一并發(fā)送給客戶端,這里的隨機數(shù)是整個過程的第二個隨機數(shù)。
服務(wù)端需要提供的信息:
協(xié)議的版本
加密的算法
隨機數(shù)
服務(wù)器證書
客戶端再次回應(yīng)
客戶端首先會對服務(wù)器下發(fā)的證書進行驗證,驗證通過之后,則會繼續(xù)下面的操作,客戶端再次產(chǎn)生一個隨機數(shù)(第三個隨機數(shù)),然后使用服務(wù)器證書中的公鑰進行加密,以及放一個ChangeCipherSpec消息即編碼改變的消息,還有整個前面所有消息的hash值,進行服務(wù)器驗證,然后用新秘鑰加密一段數(shù)據(jù)一并發(fā)送到服務(wù)器,確保正式通信前無誤。
客戶端使用前面的兩個隨機數(shù)以及剛剛新生成的新隨機數(shù),使用與服務(wù)器確定的加密算法,生成一個Session Secret。
ChangeCipherSpec
ChangeCipherSpec是一個獨立的協(xié)議,體現(xiàn)在數(shù)據(jù)包中就是一個字節(jié)的數(shù)據(jù),用于告知服務(wù)端,客戶端已經(jīng)切換到之前協(xié)商好的加密套件(Cipher Suite)的狀態(tài),準備使用之前協(xié)商好的加密套件加密數(shù)據(jù)并傳輸了。
服務(wù)器再次響應(yīng)
服務(wù)端在接收到客戶端傳過來的第三個隨機數(shù)的 加密數(shù)據(jù)之后,使用私鑰對這段加密數(shù)據(jù)進行解密,并對數(shù)據(jù)進行驗證,也會使用跟客戶端同樣的方式生成秘鑰,一切準備好之后,也會給客戶端發(fā)送一個 ChangeCipherSpec,告知客戶端已經(jīng)切換到協(xié)商過的加密套件狀態(tài),準備使用加密套件和 Session Secret加密數(shù)據(jù)了。之后,服務(wù)端也會使用 Session Secret 加密一段 Finish 消息發(fā)送給客戶端,以驗證之前通過握手建立起來的加解密通道是否成功。
后續(xù)客戶端與服務(wù)器間通信
確定秘鑰之后,服務(wù)器與客戶端之間就會通過商定的秘鑰加密消息了,進行通訊了。整個握手過程也就基本完成了。
值得特別提出的是: SSL協(xié)議在握手階段使用的是非對稱加密,在傳輸階段使用的是對稱加密,也就是說在SSL上傳送的數(shù)據(jù)是使用對稱密鑰加密的!因為非對稱加密的速度緩慢,耗費資源。其實當客戶端和主機使用非對稱加密方式建立連接后,客戶端和主機已經(jīng)決定好了在傳輸過程使用的對稱加密算法和關(guān)鍵的對稱加密密鑰,由于這個過程本身是安全可靠的,也即對稱加密密鑰是不可能被竊取盜用的,因此,保證了在傳輸過程中對數(shù)據(jù)進行對稱加密也是安全可靠的,因為除了客戶端和主機之外,不可能有第三方竊取并解密出對稱加密密鑰!如果有人竊聽通信,他可以知道雙方選擇的加密方法,以及三個隨機數(shù)中的兩個。整個通話的安全,只取決于第三個隨機數(shù)(Premaster secret)能不能被破解。
其他補充
對于非常重要的保密數(shù)據(jù),服務(wù)端還需要對客戶端進行驗證,以保證數(shù)據(jù)傳送給了安全的合法的客戶端。服務(wù)端可以向客戶端發(fā)出 Cerficate Request 消息,要求客戶端發(fā)送證書對客戶端的合法性進行驗證。比如,金融機構(gòu)往往只允許認證客戶連入自己的網(wǎng)絡(luò),就會向正式客戶提供USB密鑰,里面就包含了一張客戶端證書。
PreMaster secret前兩個字節(jié)是TLS的版本號,這是一個比較重要的用來核對握手數(shù)據(jù)的版本號,因為在Client Hello階段,客戶端會發(fā)送一份加密套件列表和當前支持的SSL/TLS的版本號給服務(wù)端,而且是使用明文傳送的,如果握手的數(shù)據(jù)包被破解之后,攻擊者很有可能串改數(shù)據(jù)包,選擇一個安全性較低的加密套件和版本給服務(wù)端,從而對數(shù)據(jù)進行破解。所以,服務(wù)端需要對密文中解密出來對的PreMaster版本號跟之前Client Hello階段的版本號進行對比,如果版本號變低,則說明被串改,則立即停止發(fā)送任何消息。
session的恢復
有兩種方法可以恢復原來的session:一種叫做session ID,另一種叫做session ticket。
session ID
session ID的思想很簡單,就是每一次對話都有一個編號(session ID)。如果對話中斷,下次重連的時候,只要客戶端給出這個編號,且服務(wù)器有這個編號的記錄,雙方就可以重新使用已有的”對話密鑰”,而不必重新生成一把。
session ID是目前所有瀏覽器都支持的方法,但是它的缺點在于session ID往往只保留在一臺服務(wù)器上。所以,如果客戶端的請求發(fā)到另一臺服務(wù)器,就無法恢復對話
session ticket
客戶端發(fā)送一個服務(wù)器在上一次對話中發(fā)送過來的session ticket。這個session ticket是加密的,只有服務(wù)器才能解密,其中包括本次對話的主要信息,比如對話密鑰和加密方法。當服務(wù)器收到session ticket以后,解密后就不必重新生成對話密鑰了。
目前只有Firefox和Chrome瀏覽器支持。
總結(jié)
https實際就是在TCP層與http層之間加入了SSL/TLS來為上層的安全保駕護航,主要用到對稱加密、非對稱加密、證書,等技術(shù)進行客戶端與服務(wù)器的數(shù)據(jù)加密傳輸,最終達到保證整個通信的安全性。
如何部署https加密
加密App及網(wǎng)頁通訊可確保使用者信息安全,越來越多的網(wǎng)站已經(jīng)開始使用更安全的https加密傳輸協(xié)議。因此任何新站點或新的web應(yīng)用都應(yīng)該上線前啟用https加密, 確保用戶體驗和業(yè)務(wù)未受影響。使用https協(xié)議就意味著需要在服務(wù)器上部署SSL證書。
為你的網(wǎng)站和應(yīng)用啟用https加密,需要使用全球信任的SSL證書,即根證書內(nèi)置在所有平臺的證書,并且選擇國際化的CA,可以保證長久提供穩(wěn)定、可靠、安全的SSL數(shù)字證書服務(wù)。
亞洲誠信是賽門鐵克(Symantec)亞太區(qū)首席安全技術(shù)專家戰(zhàn)略合作伙伴,提供國際知名的Symantec SSL證書可滿足ATS的各項要求,在SSL證書管理、監(jiān)控和風險評測等擁有業(yè)內(nèi)領(lǐng)先的技術(shù)解決方案和高效專業(yè)化的技術(shù)支持服務(wù),能夠幫助用戶快捷且正確配置SSL證書。
日期:2018-04 瀏覽次數(shù):6763
日期:2017-02 瀏覽次數(shù):3438
日期:2017-09 瀏覽次數(shù):3659
日期:2017-12 瀏覽次數(shù):3529
日期:2018-12 瀏覽次數(shù):4819
日期:2016-12 瀏覽次數(shù):4584
日期:2017-07 瀏覽次數(shù):13647
日期:2017-12 瀏覽次數(shù):3508
日期:2018-06 瀏覽次數(shù):4267
日期:2018-05 瀏覽次數(shù):4446
日期:2017-12 瀏覽次數(shù):3558
日期:2017-06 瀏覽次數(shù):3984
日期:2018-01 瀏覽次數(shù):3945
日期:2016-12 瀏覽次數(shù):3915
日期:2018-08 瀏覽次數(shù):4428
日期:2017-12 瀏覽次數(shù):3708
日期:2016-09 瀏覽次數(shù):6407
日期:2018-07 瀏覽次數(shù):3208
日期:2016-12 瀏覽次數(shù):3232
日期:2018-10 瀏覽次數(shù):3386
日期:2018-10 瀏覽次數(shù):3482
日期:2018-09 瀏覽次數(shù):3580
日期:2018-02 瀏覽次數(shù):3600
日期:2015-05 瀏覽次數(shù):3521
日期:2018-09 瀏覽次數(shù):3308
日期:2018-06 瀏覽次數(shù):3435
日期:2017-02 瀏覽次數(shù):3874
日期:2018-02 瀏覽次數(shù):4339
日期:2018-02 瀏覽次數(shù):4176
日期:2016-12 瀏覽次數(shù):3574
Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.