HTTPS中的加密算法相關(guān)概念
密碼學(xué)在計算機科學(xué)中使用非常廣泛,HTTPS 就是建立在密碼學(xué)基礎(chǔ)之上的一種安全的通信協(xié)議。HTTPS 早在 1994 年由網(wǎng)景公司首次提出,而如今在眾多互聯(lián)網(wǎng)廠商的推廣之下 HTTPS 已經(jīng)被廣泛使用在各種大小網(wǎng)站中。在完全理解 HTTPS 之前,有必要弄清楚一些密碼學(xué)相關(guān)的概念,比如:明文、密文、密碼、密鑰、對稱加密、非對稱加密、摘要、數(shù)字簽名、數(shù)字證書。
密碼(cipher)
密碼學(xué)中的密碼(cipher)和我們?nèi)粘I钪兴f的密碼不太一樣,計算機術(shù)語『密碼 (cipher)』是一種用于加密或者解密的算法,而我們?nèi)粘K褂玫摹好艽a( password)』是一種口令,它是用于認(rèn)證用途的一組文本字符串。這里我們要討論的是前者:cipher。
密鑰(key)
密鑰是一種參數(shù),它是在使用密碼(cipher)算法過程中輸入的參數(shù)。同一個明文在相同的密碼算法和不同的密鑰計算下會產(chǎn)生不同的密文。很多知名的密碼算法都是公開的,密鑰才是決定密文是否安全的重要參數(shù),通常密鑰越長,破解的難度越大,比如一個 8 位的密鑰最多有 256 種情況,使用窮舉法,能非常輕易的破解。知名的 DES 算法使用 56 位的密鑰,目前已經(jīng)不是一種安全的加密算法了,主要還是因為 56 位的密鑰太短,在數(shù)小時內(nèi)就可以被破解。密鑰分為對稱密鑰與非對稱密鑰。
明文/密文
明文(plaintext)是加密之前的原始數(shù)據(jù),密文是通過密碼(cipher)運算后得到的結(jié)果成為密文(ciphertext)。
對稱密鑰
對稱密鑰(Symmetric-key algorithm)又稱為共享密鑰加密,對稱密鑰在加密和解密的過程中使用的密鑰是相同的,常見的對稱加密算法有DES、3DES、AES、RC5、RC6。對稱密鑰的優(yōu)點是計算速度快,但是它也有缺點,密鑰需要在通訊的兩端共享,讓彼此知道密鑰是什么對方才能正確解密,如果所有客戶端都共享同一個密鑰,那么這個密鑰就像萬能鑰匙一樣,可以憑借一個密鑰破解所有人的密文了,如果每個客戶端與服務(wù)端單獨維護(hù)一個密鑰,那么服務(wù)端需要管理的密鑰將是成千上萬,這會給服務(wù)端帶來噩夢。下面就是一個簡單的對稱加密,將明文加密成 ASCII。
- # 加密的方式:在ASCII的基礎(chǔ)上 + 密鑰的值
- def encipher(plain_text, key):
- # 加密
- cipher_text = []
- for c in plain_text:
- cipher_text.append(str(ord(c) + key))
- return ' '.join(cipher_text)
- def decipher(cipher_text, key):
- # 解密
- plain_text = []
- for c in cipher_text.split(" "):
- plain_text.append(chr(int(c)+key))
- return "".join(plain_text)
- if __name__ == '__main__':
- print "cipher_text:", encipher("abcdef", 0)
- print "plain_text:", decipher("97 98 99 100 101 102", 0)
非對稱密鑰
非對稱密鑰(public-key cryptography),又稱為公開密鑰加密。服務(wù)端會生成一對密鑰,一個私鑰保存在服務(wù)端,僅自己知道,另一個是公鑰,公鑰可以自由發(fā)布供任何人使用??蛻舳说拿魑耐ㄟ^公鑰加密后的密文需要用私鑰解密。非對稱密鑰在加密和解密的過程的使用的密鑰是不同的密鑰,加密和解密是不對稱的,所以稱之為非對稱加密。與對稱密鑰加密相比,非對稱加密無需在客戶端和服務(wù)端之間共享密鑰,只要私鑰不發(fā)給任何用戶,即使公鑰在網(wǎng)上被截獲,也無法被解密,僅有被竊取的公鑰是沒有任何用處的。常見的非對稱加密有 RSA,非對稱加解密的過程:
- 服務(wù)端生成配對的公鑰和私鑰
- 私鑰保存在服務(wù)端,公鑰發(fā)送給客戶端
- 客戶端使用公鑰加密明文傳輸給服務(wù)端
- 服務(wù)端使用私鑰解密密文得到明文
數(shù)字簽名(Digital Signature)
數(shù)據(jù)在瀏覽器和服務(wù)器之間傳輸時,有可能在傳輸過程中被冒充的盜賊把內(nèi)容替換了,那么如何保證數(shù)據(jù)是真實服務(wù)器發(fā)送的而不被調(diào)包呢,同時如何保證傳輸?shù)臄?shù)據(jù)沒有被人篡改呢?要解決這兩個問題就必須用到數(shù)字簽名,數(shù)字簽名就如同日常生活的中的簽名一樣,一旦在合同書上落下了你的大名,從法律意義上就確定是你本人簽的字兒,這是任何人都沒法仿造的,因為這是你專有的手跡,任何人是造不出來的。那么在計算機中的數(shù)字簽名怎么回事呢?數(shù)字簽名就是用于驗證傳輸?shù)膬?nèi)容是不是真實服務(wù)器發(fā)送的數(shù)據(jù),發(fā)送的數(shù)據(jù)有沒有被篡改過,它就干這兩件事,是非對稱加密的一種應(yīng)用場景。不過他是反過來用私鑰來加密,通過與之配對的公鑰來解密。
第一步:服務(wù)端把報文經(jīng)過 Hash 處理后生成摘要信息(Digest),摘要信息使用私鑰(private-key)加密之后就生成簽名,服務(wù)器把簽名連同報文一起發(fā)送給客戶端。
第二步:客戶端接收到數(shù)據(jù)后,把簽名提取出來用公鑰(public-key)解密,如果能正常的解密出來 Digest2,那么就能確認(rèn)是對方發(fā)的。
第三步:客戶端把報文 Tex t提取出來做同樣的 Hash 處理,得到的摘要信息 Digest1,再與之前解密出來的 Digist2 對比,如果兩者相等,就表示內(nèi)容沒有被篡改,否則內(nèi)容就是被人改過了。因為只要文本內(nèi)容哪怕有任何一點點改動都會 Hash 出一個完全不一樣的摘要信息出來。
數(shù)字證書(Certificate Authority)
數(shù)字證書簡稱 CA,它由權(quán)威機構(gòu)給某網(wǎng)站頒發(fā)的一種認(rèn)可憑證,這個憑證是被大家(瀏覽器)所認(rèn)可的。為什么需要用數(shù)字證書呢,難道有了數(shù)字簽名還不夠安全嗎?有這樣一種情況,就是瀏覽器無法確定所有的真實服務(wù)器是不是真的是真實的,舉一個簡單的例子:
A 廠家給你們家安裝鎖,同時把鑰匙也交給你,只要鑰匙能打開鎖,你就可以確定鑰匙和鎖是配對的,如果有人把鑰匙換了或者把鎖換了,你是打不開門的,你就知道肯定被竊取了,但是如果有人把鎖和鑰匙替換成另一套表面看起來差不多的,但質(zhì)量差很多的,雖然鑰匙和鎖配套,但是你卻不能確定這是否真的是 A 廠家給你的,那么這時候,你可以找質(zhì)檢部門來檢驗一下,這套鎖是不是真的來自于 A 廠家,質(zhì)檢部門是權(quán)威機構(gòu),他說的話是可以被公眾認(rèn)可的(呵呵)。
同樣的, 因為如果有人(張三)用自己的公鑰把真實服務(wù)器發(fā)送給瀏覽器的公鑰替換了,于是張三用自己的私鑰執(zhí)行相同的步驟對文本 Hash、數(shù)字簽名,最后得到的結(jié)果都沒什么問題,但事實上瀏覽器看到的東西卻不是真實服務(wù)器給的,而是被張三從里到外(公鑰到私鑰)換了一通。
那么如何保證你現(xiàn)在使用的公鑰就是真實服務(wù)器發(fā)給你的呢?我們就用數(shù)字證書來解決這個問題。數(shù)字證書一般由數(shù)字證書認(rèn)證機構(gòu)(Certificate Authority)頒發(fā),證書里面包含了真實服務(wù)器的公鑰和網(wǎng)站的一些其他信息,數(shù)字證書機構(gòu)用自己的私鑰加密后發(fā)給瀏覽器,瀏覽器使用數(shù)字證書機構(gòu)的公鑰解密后得到真實服務(wù)器的公鑰。這個過程是建立在被大家所認(rèn)可的證書機構(gòu)之上得到的公鑰,所以這是一種安全的方式。