小結在回顧https工作原理之前，需要問自己三個問題：
1、什麼是對稱加密？
2、什麼是非對稱加密？
3、https為了保證資料傳輸的安全，使用的是對稱加密還是非對稱加密？
帶著這三個問題，首先理解一下對稱加密：
對稱加密是指客戶端和服務端共用乙個金鑰，這個金鑰用於加密也用於解密。優點是加計算量小、加解密效率高，但安全性方面存在一些問題，因為金鑰放在客戶端會有被竊取的風險。對稱加密的代表演算法有：des、3des、aes等等。
對稱加密演算法的缺點是在資料傳送前，傳送方和接收方必須商定好秘鑰，然後使雙方都能儲存好秘鑰。其次如果一方的秘鑰被洩露，那麼加密資訊也就不安全了。另外，每對使用者每次使用對稱加密演算法時，都需要使用其他人不知道的獨一秘鑰，這會使得收、發雙方所擁有的鑰匙數量巨大，金鑰管理成為雙方的負擔。
由於對稱加密存在著上述的不安全性，因此如何把金鑰安全地傳遞到解密者手上就成了必須要解決的問題。
要解決這個問題，可以採用非對稱加密：
非對稱加密將金鑰分成了兩種：公鑰和私鑰。公鑰通常存放在客戶端，私鑰存放在伺服器。使用公鑰加密的資料必須通過私鑰才能解密，反過來，私鑰加密的資料也只有公鑰能夠解密。這樣的優點是安全性更高，因此客戶端發給伺服器的加密資訊只有服務端可以使用私鑰解密，不必擔心被人破解，但缺點也很明顯，加解密效率比對稱加密要差。非對稱加密的代表演算法有：rsa、elgamal等。
回顧傳統的http方式在網路傳輸時的表現，傳輸資訊時我們的資訊都是明文的，因此容易被監聽和竊取。
除此之外，傳輸的資料也會被別有用心的人篡改，導致瀏覽器與**收發的內容不一致。
這樣看來http是一種不安全的傳輸協議，安全性而言當然是要使用https了。那https相比http，是如何保證傳輸的安全的呢？
只用對稱加密是不夠的
由於資料明文形式在網路上進行傳輸是不安全的，我們顯然要對資料進行加密，那麼加密方式又有兩種，對稱加密和非對稱加密，該選哪種呢？就效率而言，我們當然是先選擇對稱加密了，畢竟快嘛！
但問題也隨之而來：
儘管我們通過對稱加密後，在網路上傳輸的是密文，不怕被監聽者知悉原文。而且這段密文只要使用雙方協商好的金鑰進行解密即可。但這需要有個大前提：瀏覽器和**怎麼商定使用什麼金鑰呢？
既然這個金鑰只能讓這兩者知曉，不能被監聽者得到，那就沒法通過通訊過程來進行商定了，因為第一次的通訊過程，必然是明文的。這也就意味著，不解決這首次通訊的洩密問題，我們是無論如何是無法建立起安全的對稱加密金鑰的。
引入非對稱加密幫助建立對稱加密金鑰
為了解決上述問題，我們可以引入非對稱加密方式。
比如說：我們讓瀏覽器隨機生成乙個對稱加密金鑰，但在傳輸前，我們使用**提供的公鑰先對其進行非對稱加密。這樣一來，傳輸時是一段密文，而不是金鑰原文，監聽者不知道加解密方式，也就無從得知我們的對稱加密金鑰。之後，**收到這段密文，只需要使用私鑰對其解密，就能獲取到瀏覽器生成的對稱加密金鑰。
這樣做的好處是什麼呢？採用非對稱加密方式，讓瀏覽器和**完成首次商定對稱加密金鑰的過程，等到**收到了瀏覽器隨機生成的金鑰之後，瀏覽器和**之間就可以愉快地用對稱加密進行通訊了，效率依然很高。
其實還有漏洞？**公鑰獲取有風險？
上述的工作機制看似天衣無縫，絕對安全，其實不然。想一下，**的公鑰，瀏覽器應該怎麼得到？雖然公鑰是公開的資料，在網路上傳輸不怕被人監聽，但是如果公鑰被人篡改了，你不知情的情況下用這個來歷不明的公鑰進行加密，在傳輸過程中被監聽到，你的資料就能被解密。
除非我們把所有的**公鑰都預置進作業系統，否則我們還是有可能從網路上獲得乙個不安全的公鑰。這個時候，需要乙個權威的機構來解決這個問題，它就是ca機構。
ca機構的作用
ca機構專門用於給各個**簽發數字證書，從而保證瀏覽器可以安全地獲得各個**的公鑰。它是怎麼做到的呢？
首先，**管理員要向ca機構進行申請，將自己的公鑰提交給ca機構。ca機構則會用**的公鑰，加上一系列資訊，如**網域名稱、有效時長等等，來製作證書。證書製作完成，ca機構就會用自己的私鑰對其加密，並把資料返回給我們，我們只需要用ca機構的公鑰進行解密，就能得到這份ca機構頒發給**的數字證書了，它包含了我們需要的**公鑰，還有**網域名稱等等。假如我們解密無法成功，說明這段加密資料並不是由乙個合法的ca機構使用私鑰加密而來的，可能是被人篡改了（也就是不安全的連線）。
這樣一來，就能繼續剛剛的流程了，通過ca機構的數字證書形式，保證我們得到安全的**公鑰，然後首次通訊時使用非對稱加密方式，與**商定好乙個不為人知的對稱加密金鑰，此後使用商定好的對稱加密金鑰進行安全且高效的通訊。
ca機構的公鑰從哪兒來？
不過，有了ca機構就真的安全了嗎，我們的ca機構公鑰又是從哪兒來的呢？
這就簡單不過了，因為ca機構不像**，它是有限的，任何正版作業系統都會將所有主流ca機構的公鑰內建到作業系統當中，所以我們不需要額外去獲取，解密時遍歷一遍系統中內建的ca機構公鑰，有其中乙個公鑰能進行正常解密，就說明送來的資料是合法ca機構用私鑰加密得來的。
ca機構會不會被利用
還有乙個問題，那就是ca機構為成千上萬的**簽發證書，假如攻擊者知道某個**（比如說 張偉.com）用的是某家ca機構的證書，那麼他可以為他的**（比如說 賢哥.com）去向這家ca機構申請乙個證書，然後對監聽並截獲到的加密證書資料進行替換，再返回給使用者瀏覽器，試圖讓使用者訪問它的**。
由於攻擊者申請到的證書也是正規ca機構製作的，所以這段加密資料最後可以被成功解密。考慮到這個原因，ca機構製作的證書除了**公鑰外，還加入了其他輔助驗證的資訊，比如說**網域名稱。當使用者瀏覽器收到證書並解密後，其中包含的網域名稱（賢哥.com）和瀏覽器正在請求的網域名稱（張偉.com）對不上，此時瀏覽器就會顯示異常，攻擊者也就無功而返。
講到這兒其實很明顯了，http經過一步步完善，就變成了https，上面也就是https的工作原理了。
那麼回顧開始的三個問題中的第三個問題，https為了保證資料傳輸的安全，使用的是對稱加密還是非對稱加密？
答案是：https使用的是對稱加密與非對稱加密相結合的方式。
回顧基礎知識，每天進步一點點！
JSONP安全性分析
1 主要是callback引數有沒有進行適當的處理，會造成xss漏洞，結合csrf可以獲取資訊。比方說引數為callback alert 1 truecallback。所以需要伺服器b進行請求過濾轉碼。2 這段 的大致意思就是假設黑客發給c乙個惡意鏈結，c開啟以後，這個惡意鏈結中的js 會執行，會向...
scanf安全性分析
int scanf char 是其函式宣告。其中只要求第乙個引數是char 即字串即可，而對於其他引數則沒有限制型別和個數，這其中有安全風險。舉個例子 scanf d c i,ch 如果從鍵盤上輸入的資料是 30 a？則變數ch的值是空格字元而不是字元 a 這種錯誤很隱蔽，因此建議讀者盡量不要使用s...
網路 HTTPS 怎麼保證資料傳輸的安全性
大家都知道，在客戶端與伺服器資料傳輸的過程中，http協議的傳輸是不安全的，也就是一般情況下http是明文傳輸的。但https協議的資料傳輸是安全的，也就是說https資料的傳輸是經過加密的。在客戶端與伺服器這兩個完全沒有見過面的陌生人交流中，https是如何保證資料傳輸的安全性的呢？下面我們來一步...