每當我們討論到資訊保安的時候，我們最長接觸到的資訊加密傳輸的方式莫過於 https 了，當我們瀏覽器位址列閃現出綠色時，就代表著這個**支援 https 的加密資訊傳輸方式，並且你與它的連線確實被加密了。但是 https 並不是乙個單一的東西，它只是我們常見的 http 協議和某個加密協議的乙個混合，這個加密協議通常會是 tls。那麼 https 為什麼安全呢？其實我們需要先考慮 http 為什麼不安全。
假設你坐在乙個教室裡，你現在非常想把某個資訊傳遞給教室裡的另乙個人，一般來說，會選擇，傳紙條。傳紙條這個比喻其實非常正確，這就是網際網路的乙個基礎協議 tcp/ip 協議基本的工作模式。而通常，http 協議的資料是使用 tcp/ip 協議進行傳送的。http 指的是你在紙條上寫明你要傳送的目的地是哪個同學的坐位，然後再是要傳遞的內容。途徑的同學拿到紙條後根據紙條上顯示的位址依次傳過去就好了。這樣要面臨的第乙個問題就是：途徑的同學可以完全知道你寫了什麼。
這就是 http 面臨的第乙個問題，這個問題通常被叫做 「竊聽」 或者 「嗅探」 ，指的是和你在同乙個網路下或者是途徑的路由上的攻擊者可以**到你傳輸的內容。這是 https 要解決的第乙個問題。這種問題通常是通過「加密」來解決的。從非常原始的角度來考慮，其實就是雙方約定乙個暗號。用什麼字母去替代什麼字母之類的。不過考慮到網際網路每天有無數資訊需要加密，這種原始的加密方法似乎不太適合。不過實際上方法也差不多，一般是採用一種叫做 aes 的演算法來解決的。這種演算法需要乙個 金鑰 key 來加密整個資訊，加密和解密所需要使用的 key 是一樣的，所以這種加密一般也被稱為「對稱加密」。aes 在數學上保證了，只要你使用的 key 足夠足夠足夠足夠的長，破解是幾乎不可能的。
我們先假設這種破解確實是不可能的，而且目前也確實沒有對 aes 本身能發動起有效的攻擊的案例出現。
我們再回到這個教室，你接著要傳小紙條，你把位址寫上後，把要傳輸的內容用 aes 蹭蹭蹭加密了起來。剛準備傳，問題來了。aes 不是有乙個 key 嗎？key 怎麼給目的地啊？如果我把金鑰直接寫在紙條上，那麼中間的人不依然可以解密嗎？在現實中你可以通過一些其它方法來把金鑰安全傳輸給目的地而不被其他人看見，但是在網際網路上，要想這麼做難度就很大了，畢竟傳輸終究要經過這些路由，所以要做加密，還得找乙個更複雜的數學方法。
於是聰明的人們發明了一種更複雜的加密演算法——非對稱加密。這種加密或許理解起來比較困難，這種加密指的是可以生成一對金鑰 (k1, k2)。凡是 k1 加密的資料，k1 自身不能解密，而需要 k2 才能解密；凡是 k2 加密的資料，k2 不能解密，需要 k1 才能解密。這種演算法事實上有很多，常用的是 rsa，其基於的數學原理是兩個大素數的乘積很容易算，而拿到這個乘積去算出是哪兩個素數相乘就很複雜了。好在以目前的技術，分解大數的素因數確實比較困難，尤其是當這個大數足夠大的時候（通常使用2的10次方個二進位制位這麼大），就算是超級計算機解密也需要非常長的時間。
現在利用這種非對稱加密的方法，我們來設想乙個場景。你繼續想要傳紙條，但是傳紙條之前你先準備把接下來通訊的對稱加密金鑰給傳輸過去。於是你用 rsa 技術生成了一對 k1、k2，你把 k1 用明文傳送了出去，路經有人或許會擷取，但是沒有用，k1 加密的資料需要用 k2 才能解密。而此時，k2 在你自己的手裡。k1 送達目的地後，目的地的人會去準備乙個接下來用於對稱加密傳輸的金鑰 key，然後用收到的 k1 把 key 加密了，把加密好的資料傳回來。路上的人就算擷取到了，也解密不出 key。等到了你自己手上，你用手上的 k2 把用 k1 加密的 key 解出來，現在全教室就只有你和你的目的地擁有 key，你們就可以用 aes 演算法進行對稱加密的傳輸啦！這時候你和目的地的通訊將無法再被任何人竊聽！
當然，這時候你可能會問兩個問題。
既然 非對稱加密 可以那麼安全，為什麼我們不直接用它來加密資訊，而是去加密 對稱加密 的金鑰呢？
這是因為 非對稱加密 的密碼對生成和加密的消耗時間比較長，為了節省雙方的計算時間，通常只用它來交換金鑰，而非直接用來傳輸資料。
使用 非對稱加密 是完全安全的嗎？
聽起來確實是挺安全的，但實際上，還有一種更惡劣的攻擊是這種方法無法防範的，這就是傳說中的「中間人攻擊」。我們繼續讓你坐在教室裡傳小紙條。現在你和目的地上途徑乙個中間人，他有意想要知道你們的訊息。由於這個描述比較複雜，我們將你稱為 a，你的目的地稱為 b，而中間人稱為 m。當你要和 b 完成第一次金鑰交換的時候，途徑了 m。m 知道你要進行金鑰交換了，它把小紙條扣了下來，假裝自己是 b，偽造了乙個 key ，然後用你發來的 k1 加密了 key 發還給你，你以為你和 b 完成了金鑰交換，實際上你是和 m 完成了金鑰交換。同時 m 和 b 完成一次金鑰交換，讓 b 誤以為和你完成了金鑰交換。現在，由 a -> b完整的加密，變成了 a（加密連線1） -> m（明文）->b（加密連線2）的情況了。這時候 m 依然可以知道 a 和 b 傳輸中的全部資訊。
對於這種事，我們似乎很難找到乙個解決方法來解決這個問題，除非我們能從源頭保證，你金鑰交換的物件是安全的。這時候我們就要認識網際網路 https 和你傳紙條的微妙區別了。你傳紙條時，你和你的目的地的關係幾乎是對等的。而你訪問**時，你訪問的物件通常是乙個比較大的服務**商，他們有充沛的資源，也許可以證明他們的合法性。
這時候我們會引入乙個第三方叫做 ca。ca 是一些非常權威的專門用於認證乙個**合法性的組織。服務商可以向他們申請乙個證書，使得他們建立安全連線時可以帶上 ca 的簽名。而 ca 的安全性由作業系統或瀏覽器來認證。你的 windows、mac、linux、chrome、safari 等會在安裝時帶上乙個他們認為安全的 ca 證書列表。如果和你建立安全連線的人帶著這些人的簽名，那麼認為這個安全連線是安全的，沒有遭到中間人攻擊。
ca 證書通常情況下是安全的。因為一旦某個 ca 頒發出的某個證書被用於了非法用途，瀏覽器和作業系統一般會通過更新將整個 ca 頒發過的全部證書全部視為不安全。這使得 ca 通常在頒發證書時是比較小心的。
所以通過 對稱加密 + 非對稱加密 + ca認證 這三個技術混合在一起，才使得 http 的後面加上了乙個 s —— security。實際上 https 的協議比我這裡描述的更複雜一些，我這裡說的主要是基本的實現原理。因為其中任何一環稍有閃失，就會使得整個加密都將變得不安全。這也是為什麼 https 的加密協議從ssl 1.0 公升級到 ssl 3.0 再被 tls 1.0 現在被 tls 1.2 取代，其背後都是一環環細節上的修改，以防任何地方的閃失。
但即使如此，你的 https 盡可能的保證了你傳輸的安全，但這種安全也不是絕對的。比如 ca 證書出了問題被用於了中間人攻擊，在短期內，你的安全將會陷入直接的麻煩直到瀏覽器或作業系統重新更新了你的 ca 列表或者你手動調整了這個列表。但大多情況下不必杞人憂天，它基本上是安全的。
當然了，路由也可以選擇直接丟包，它看不到的，也不讓你看到。
sharedpreferences如何儲存物件
昨天做了乙個搜尋歷史的功能，然後根據搜尋的歷史可以調回到上乙個頁面，這裡涉及到乙個用sharedpreferences儲存物件的問題，sharedpreferences是不能夠直接儲存物件的，我們需要將物件序列化成乙個字串進行儲存。例如 playlist這樣乙個物件 public static vo...
我是如何寫部落格的 轉
本文主要介紹了如何使用 restructuredtext 簡稱為rest 來寫部落格，並且介紹了使用 google code 來管理部落格原始檔的方法。內容如下 contents 摘要 使用restructuredtext作為格式化文件的原始檔 使用google code作為文件的源 伺服器 參考資...
如何實現執行緒保活
有兩種方案 第一種 提公升優先順序 降低程序被殺死的概率 執行緒的優先順序 a.前台程序 b.可見程序 c.服務程序 d.後台程序 e.空程序 1.利用activity 提公升許可權 監聽手機鎖屏事件 在螢幕鎖屏的時候啟動乙個 1畫素的 activity,在使用者解鎖時將 activity 銷毀,注...