pki體系
tls/ssl握手過程
https的使用成本
https的優化後記
接上篇，本章主要講解https相關知識點，重點是stl/ssl的握手。https全稱secure hypertext transfer protocol（安全超文字傳輸協議），是乙個安全通訊通道，用於在客戶計算機和伺服器之間交換資訊。它使用安全套接字層進行資訊交換，簡單來說它是http的安全版，是使用tls/ssl加密的http協議。
http協議採用明文傳輸資訊，存在資訊竊聽、資訊篡改和資訊劫持的風險，而協議tls/ssl具有身份驗證、資訊加密和完整性校驗的功能，可以避免此類問題發生。
tls全稱transport layer security（安全傳輸層協議）, 前身是ssl，故現在用tls/ssl統稱。是介於tcp和http之間的一層安全協議，不影響原有的tcp協議和http協議，所以使用https基本上不需要對http頁面進行太多的改造。
套用在tcp/ip四層模型裡的結構如下：
tls/ssl的功能實現主要依賴於三類基本演算法：雜湊函式（hash）、對稱加密和非對稱加密。
其利用非對稱加密實現身份認證和金鑰協商，對稱加密演算法採用協商的金鑰對資料加密，基於雜湊函式驗證資訊的完整性。
tls/ssl = 非對稱加密 + 對稱加密 + 雜湊演算法
加密和解密使用不同金鑰的加密演算法，也稱為公私鑰加密。金鑰成對出現，一般稱為公鑰（publickey）和私鑰（privatekey），公鑰加密的資訊只能私鑰解開，私鑰加密的資訊只能公鑰解開。即伺服器持有私鑰，客戶端持有公鑰，客戶端要傳送的資訊經過公鑰加密後傳遞給伺服器，伺服器用私鑰解密得到明文資訊。
特點：可以實現1對多的通訊；
保密性比較好，只有公鑰需要被傳遞，故私鑰被劫持的概率很低；
安全性高，保密性保證私鑰安全，因此安全性僅依賴於演算法本身；
計算複雜，加密速度慢。
在tls/ssl中，非對稱加密僅用於「身份認證」和「金鑰協商」，不在後續正文資料傳輸中使用，這是安全性與效能之間的平衡取捨。
加密和解密使用相同金鑰的加密演算法。即客戶端與伺服器所持有的金鑰是相同的，客戶端要傳送的資訊經過金鑰加密後傳遞給伺服器，伺服器用相同金鑰解密得到明文資訊。
-特點：在tls/ssl中，對稱加密的金鑰是通過非對稱加密的「金鑰協商」產生的，這樣就最大限度的保證了金鑰的安全。由於其效率高的特點，正文資料傳輸使用了該加密方式。
一種將任意長度的訊息壓縮到某一固定長度的訊息摘要的函式，常用於防止資訊篡改並驗證資料的完整性。
在資訊傳輸過程中，雜湊函式不能單獨實現資訊防篡改，因為明文傳輸，中間人可以修改資訊之後重新計算資訊摘要，因此需要對傳輸的資訊以及資訊摘要進行加密。在tls/ssl中，「金鑰協商」的最後步驟和傳輸正文資訊都會帶上雜湊函式計算出的資訊摘要，他們一起經過對稱加密後傳輸，用來驗證完整性。
前面講到「身份驗證」和「金鑰協商」是tls/ssl的基礎功能，要求的前提是合法的伺服器掌握著對應的私鑰。但非對稱加密演算法無法確保伺服器身份的合法性，因為公鑰並不包含伺服器的資訊。
假定出現以下的情況：
如圖，中間節點m和伺服器s之間再建立合法的連線，因此c和s之間通訊被m完全掌握，m可以進行資訊的竊聽、篡改等操作，這類攻擊被稱為「中間人攻擊」。
為了解決上述的隱患，關鍵是確保獲取公鑰途徑是合法的，能夠驗證伺服器的身份資訊，為此需要引入權威的第三方機構ca。
ca全稱certificate authority（證書頒發機構），它負責核實公鑰的擁有者的資訊，並頒發認證"證書"，同時能夠為使用者提供證書驗證服務，即pki體系。
證書 = 公鑰 + 申請者與頒發者資訊 + 有效時間 + 網域名稱資訊 + 簽名ca認證流程如下：
客戶端會內建信任ca的證書資訊（包含公鑰），如果ca不被信任，則找不到對應ca的證書，證書也會被判定非法。
也可以這樣理解，**千千萬，瀏覽器廠商沒辦法一家一家去認證，於是跟ca合作，通過維護乙個ca列表，只要**有經過這個列表裡ca的認證，就可以信任該**的證書。
tls/ssl握手過程也就是所謂的https四次握手（不含證書驗證步驟）。
客戶端發起請求，以明文傳輸請求資訊，包含版本資訊，加密套件候選列表，壓縮演算法候選列表，隨機數random_c（明文），擴充套件欄位等資訊。
服務端返回協商的資訊結果，隨機數random_s（明文），證書鏈等。
對證書進行驗證，包括證書可信性、有效性等，可能需要聯絡ca。
細分為四步：
client_key_exchange：客戶端計算產生隨機數字pre-master，並用證書公鑰加密，傳送給伺服器;
客戶端根據random_c、random_s以及pre-master，計算得到協商金鑰enc_key（即對稱加密用的金鑰）；
change_cipher_spec：客戶端通知伺服器後續的通訊都採用協商的通訊金鑰和加密演算法進行加密通訊;
encrypted_handshake_message：結合之前所有通訊引數的hash值與其它相關資訊生成一段資料，採用協商金鑰enc_key進行加密，然後傳送給伺服器用於資料與握手驗證;
細分為四步：
伺服器使用私鑰解密pre-master，根據random_c、random_s以及pre-master，計算得到協商金鑰enc_key；
計算之前所有接收資訊的hash值，然後解密客戶端傳送的encrypted_handshake_message，驗證資料和金鑰正確性；
change_cipher_spec：驗證通過之後，伺服器同樣傳送change_cipher_spec以告知客戶端後續的通訊都採用協商的金鑰與演算法進行加密通訊;
encrypted_handshake_message：伺服器也結合所有當前的通訊引數資訊生成一段資料並採用協商金鑰enc_key加密併發送到客戶端;
握手結束，開始使用協商金鑰enc_key進行對稱加密通訊（包含hash完整性驗證）。
示意圖如下：
在tls/ssl協商第二階段，也就是瀏覽器生成最後乙個隨機數並用公鑰加密傳送給伺服器後，立即傳送加密的應用層資料，而無需等待伺服器的確認。如果使用者的乙個業務請求包含了多條的加密流，客戶端與伺服器要反覆握手，必定導致更多的時間損耗。或某些特殊情況導致會話中斷，需要重新握手。
伺服器為每一次的會話生成並記錄乙個sessionid，傳送給客戶端，客戶端重新連線只需要提供這個id，不需要重新握手。
ocsp全稱online certificate status protocol。由web伺服器向ocsp server周期性地查詢證書狀態，獲得乙個帶有時間戳和簽名的ocsp response並快取它。當有客戶端發起請求時，web伺服器會把這個response在tls握手過程中發給客戶端。
（谷歌瀏覽器預設只使用內建列表檢查，故這個優化對谷歌無效）
乙個報文頭部字段，告訴瀏覽器，接下來的一段時間內，當前網域名稱(及其子網域名稱)的後續通訊應該強制性使用https，直到超過有效期為止。
形如：
strict-transport-security: max-age=
31536000
;includesubdomains
你所應該知道的雲計算
感覺像是雲計算的乙個推崇者，為雲計算在做廣告，robyn peterson的文章what you need to know about cloud computing。雲計算可以保證我們不再受硬體的困擾，真的是這樣嗎？在為乙個小型商業或者大型企業構建it結構的時候，我們常常需要花費大筆的錢財去購買裝...
android裝置你所應該知道的Android設計
時光緊張，先記一筆，後續優化與完善。當然很多系統的問題被誇大其詞，其中一些android的問題在新版本中已不復存在，針對仍然存在的一些問題，本文提供了一些處理方案，同時也為將要開始計畫巨大的android應用的你提供一些提議。上圖分別是google在2010年蒲月計畫的action bar模式提議，...
你所應該要知道的面試藝術與技巧
面試乙份工作需要哪些 1.專業知識 如果沒有任何專業技能，那麼靠什麼進入企業呢？如果想要進入好的企業，沒有深厚的專業技能無疑是不行的。2.業務知識 企業想要招的是有能力為企業帶來利益的人，如果你不能將專業知識聯合起來運用，那麼你就不是企業的理想人才。所以你還要了解業務知識，能熟練運用知識，即所謂的專...