TLS 與 SSL TLS 的前身是 SSL。其是一個用于在應(yīng)用程序之間進(jìn)行通信時保障隱私的協(xié)議。除非另有說明,本文中認(rèn)為 TLS 與 SSL 是等價的。
OpenSSL 簡單地說,OpenSSL是SSL的一個實(shí)現(xiàn),SSL只是一種規(guī)范.理論上來說,SSL這種規(guī)范是安全的,目前的技術(shù)水平很難破解,但SSL的實(shí)現(xiàn)就可能有些漏洞,如著名的”心臟出血”.OpenSSL還提供了一大堆強(qiáng)大的工具軟件,強(qiáng)大到90%我們都用不到
公鑰、私鑰 公鑰和私鑰就是俗稱的不對稱加密方式,是從以前的對稱加密(使用用戶名與密碼)方式的提高。 一個私鑰可以驗證與其對應(yīng)的用來對數(shù)據(jù)進(jìn)行加密的證書和公鑰。其決不公開提供。 公鑰和私鑰是成對的,它們互相解密。非對稱密鑰密碼的主要應(yīng)用就是公鑰加密和公鑰認(rèn)證,而公鑰加密的過程和公鑰認(rèn)證的過程是不一樣的:公鑰加密,私鑰解密。私鑰數(shù)字簽名,公鑰認(rèn)證。 比如,我用你的公鑰給這個郵件加密,這樣就保證這個郵件不被別人看到,而且保證這個郵件在傳送過程中沒有被修改。你收到郵件后,用你的私鑰就可以解密,就能看到內(nèi)容。 其次我用我的私鑰給這個郵件加密,發(fā)送到你手里后,你可以用我的公鑰解密。因為私鑰只有我手里有,這樣就保證了這個郵件是我發(fā)送的。 當(dāng)A->B資料時,A會使用B的公鑰加密,這樣才能確保只有B能解開,否則普羅大眾都能解開加密的訊息,就是去了資料的保密性。驗證方面則是使用簽 驗章的機(jī)制,A傳資料給大家時,會以自己的私鑰做簽章,如此所有收到訊息的人都可以用A的公鑰進(jìn)行驗章,便可確認(rèn)訊息是由 A 發(fā)出來的了。
摘要 對需要傳輸?shù)奈谋荆鲆粋€HASH計算,一般采用SHA1,SHA2來獲得。
簽名 使用私鑰對需要傳輸?shù)奈谋镜恼M(jìn)行加密,得到的密文即被稱為該次傳輸過程的簽名。
簽名認(rèn)證 數(shù)據(jù)接收端,拿到傳輸文本,但是需要確認(rèn)該文本是否就是發(fā)送發(fā)出的內(nèi)容,中途是否曾經(jīng)被篡改。因此拿自己持有的公鑰對簽名進(jìn)行解密(密鑰對中的一種密鑰加密的數(shù)據(jù)必定能使用另一種密鑰解密。),得到了文本的摘要,然后使用與發(fā)送方同樣的HASH算法計算摘要值,再與解密得到的摘要做對比,發(fā)現(xiàn)二者完全一致,則說明文本沒有被篡改過。
基于公鑰的加密過程 比如有兩個用戶Alice和Bob,Alice想把一段明文通過雙鑰加密的技術(shù)發(fā)送給Bob,Bob有一對公鑰和私鑰,那么加密解密的過程如下: Bob將他的公開密鑰傳送給Alice。Alice用Bob的公開密鑰加密她的消息,然后傳送給Bob。Bob用他的私人密鑰解密Alice的消息。Alice使用Bob的公鑰進(jìn)行加密,Bob用自己的私鑰進(jìn)行解密。
基于公鑰的認(rèn)證過程 身份認(rèn)證和加密就不同了,主要用來鑒別用戶的真?zhèn)巍_@里我們只要能夠鑒別一個用戶的私鑰是正確的,就可以鑒別這個用戶的真?zhèn)巍?還是Alice和Bob這兩個用戶,Alice想讓Bob知道自己是真實(shí)的Alice,而不是假冒的,因此Alice只要使用私鑰對文件簽名發(fā)送給Bob,Bob使用Alice的公鑰對文件進(jìn)行解密,如果可以解密成功,則證明Alice的私鑰是正確的,因而就完成了對Alice的身份鑒 別。整個身份認(rèn)證的過程如下: Alice用她的私人密鑰對文件加密,從而對文件簽名。Alice將簽名的文件傳送給Bob。Bob用Alice的公鑰解密文件,從而驗證簽名。Alice使用自己的私鑰加密,Bob用Alice的公鑰進(jìn)行解密。
證書(cert) 包含了提供者信息等一些額外元數(shù)據(jù)的公鑰/私鑰對的公鑰部分。它可以被自由的提供給任何人。
在簽名的過程中,有一點(diǎn)很關(guān)鍵,收到數(shù)據(jù)的一方,需要自己保管好公鑰,但是要知道每一個發(fā)送方都有一個公鑰,那么接收數(shù)據(jù)的人需要保存非常多的公鑰,這根本就管理不過來。并且本地保存的公鑰有可能被篡改替換,無從發(fā)現(xiàn)。怎么解決這一問題?由一個統(tǒng)一的證書管理機(jī)構(gòu)來管理所有需要發(fā)送數(shù)據(jù)方的公鑰,對公鑰進(jìn)行認(rèn)證和加密。這個機(jī)構(gòu)也就是我們常說的CA。
認(rèn)證加密后的公鑰,即是證書,又稱為CA證書,證書中包含了很多信息,最重要的是申請者的公鑰。數(shù)字證書用來使用戶找到該授信機(jī)構(gòu)的公鑰。
證書頒發(fā)機(jī)構(gòu)(CA) 一個頒發(fā)數(shù)字證書的公司。對于 SSL/TLS 證書,也有少數(shù)供應(yīng)商(例如 Symantec/Versign/Thawte、Comodo、GoDaddy)的證書囊括了大多數(shù)瀏覽器和操作系統(tǒng)。它們的目的是成為一個“可信的第三方”。
X.509 用于描述證書的格式和用法的一個規(guī)范。主要定義了證書中應(yīng)該包含哪些內(nèi)容.其詳情可以參考RFC5280,SSL使用的就是這種證書標(biāo)準(zhǔn).
同樣的X.509證書,可能有不同的編碼格式,目前有以下兩種編碼格式.
PEM PRivacy Enhanced Mail,打開看文本格式,以”—–BEGIN…”開頭, “—–END…”結(jié)尾,內(nèi)容是BASE64編碼. 查看PEM格式證書的信息:openssl x509 -in certificate.pem -text -noout Apache和*NIX服務(wù)器偏向于使用這種編碼格式.
DER Distinguished Encoding Rules,打開看是二進(jìn)制格式,不可讀. 查看DER格式證書的信息:openssl x509 -in certificate.der -inform der -text -noout java和Windows服務(wù)器偏向于使用這種編碼格式.
這是比較誤導(dǎo)人的地方,雖然我們已經(jīng)知道有PEM和DER這兩種編碼格式,但文件擴(kuò)展名并不一定就叫”PEM”或者”DER”,常見的擴(kuò)展名除了PEM和DER還有以下這些,它們除了編碼格式可能不同之外,內(nèi)容也有差別,但大多數(shù)都能相互轉(zhuǎn)換編碼格式.
key 通常用來存放一個公鑰或者私鑰,并非X.509證書,編碼同樣的,可能是PEM,也可能是DER. 查看KEY的辦法:openssl rsa -in mykey.key -text -noout 如果是DER格式的話,同理應(yīng)該這樣了:openssl rsa -in mykey.key -text -noout -inform der
crt crt應(yīng)該是certificate的三個字母,其實(shí)還是證書的意思,常見于*NIX系統(tǒng),有可能是PEM編碼,也有可能是DER編碼,大多數(shù)應(yīng)該是PEM編碼,相信你已經(jīng)知道怎么辨別.
cer 還是certificate,還是證書,常見于Windows系統(tǒng),同樣的,可能是PEM編碼,也可能是DER編碼,大多數(shù)應(yīng)該是DER編碼.
csr Certificate Signing Request,即證書簽名請求,這個并不是證書,用私鑰生成的一個文件。是向權(quán)威證書頒發(fā)機(jī)構(gòu)獲得簽名證書的申請, CA 則使用其私鑰對csr進(jìn)行數(shù)字簽名,并創(chuàng)建一個已簽名的證書。然后瀏覽器可以使用 CA 提供的證書來驗證新的證書是否已被 CA 批準(zhǔn)。 其核心內(nèi)容是一個公鑰(當(dāng)然還附帶了一些別的信息),在生成這個申請的時候,同時也會生成一個私鑰,私鑰要自己保管好.(?) 查看的辦法:openssl req -noout -text -in my.csr (如果是DER格式的話照舊加上-inform der,這里不寫了)
PFX/P12 predecessor of PKCS#12,對*nix服務(wù)器來說,一般CRT和KEY是分開存放在不同文件中的,但Windows的IIS則將它們存在一個PFX文件中,(因此這個文件包含了證書及私鑰)這樣會不會不安全?應(yīng)該不會,PFX通常會有一個”提取密碼”,你想把里面的東西讀取出來的話,它就要求你提供提取密碼,PFX使用的時DER編碼,如何把PFX轉(zhuǎn)換為PEM編碼? openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes 這個時候會提示你輸入提取代碼. for-iis.pem就是可讀的文本. 生成pfx的命令類似這樣:openssl pkcs12 -export -in certificate.crt -inkey privateKey.key -out certificate.pfx -certfile CACert.crt
其中CACert.crt是CA(權(quán)威證書頒發(fā)機(jī)構(gòu))的根證書,有的話也通過-certfile參數(shù)一起帶進(jìn)去.這么看來,PFX其實(shí)是個證書密鑰庫.
JKS 即Java Key Storage,這是Java的專利,跟OpenSSL關(guān)系不大,利用Java的一個叫”keytool”的工具,可以將PFX轉(zhuǎn)為JKS,當(dāng)然了,keytool也能直接生成JKS,不過在此就不多表了.
在HTTPS協(xié)議的握手階段是公鑰、私鑰、證書的典型使用場景。HTTPS握手的典型時序圖如下: ???
上圖中實(shí)線部分是必須的,虛線部分是可選的。該流程完成了兩個任務(wù):服務(wù)器身份的驗證、加密傳輸對稱加密密鑰。 1、client hello和 server hello表示雙方要建立一個加密會話。 2、服務(wù)器把數(shù)字證書傳輸給客戶端,證書中包含服務(wù)器公鑰,客戶端用公鑰解析證書中的數(shù)字簽名,可以驗證服務(wù)器的身份。 3、Server Hello Done表示hello 流程結(jié)束。 4、客戶端生成一個對稱加密密鑰,用于實(shí)際數(shù)據(jù)的加密傳輸,并用服務(wù)器的公鑰加密,把對生成的密鑰傳遞給服務(wù)器。同時攜帶一個用剛剛生成的加密密鑰加密的“client finished”。 5、服務(wù)器收到對稱加密密鑰,并嘗試用該密鑰解密加密字段,如能得到明文“client finished”,認(rèn)為該密鑰有效,可以用于之后的數(shù)據(jù)加密傳輸。同時用該密鑰加密“server finished”,傳遞給客戶端。 6、客戶端用對稱機(jī)密密鑰解密,如能得到明文“server finished”,客戶端認(rèn)為該服務(wù)器已經(jīng)正確的接收到對稱密鑰。 7、加密數(shù)據(jù)傳輸開始。 虛線部分是服務(wù)器端要求驗證客戶身份。
1.http://www.CUOXin.com/guogangj/p/4118605.html 2.http://www.oschina.net/translate/everything-you-ever-wanted-to-know-about-ssl 3.http://blog.csdn.net/sealyao/article/details/5761747
新聞熱點(diǎn)
疑難解答
圖片精選