我就是那塊遲鈍の糕同學，我一直都只知道https是http+ssl/tls兩種協議共同構成的，但是對於其中的機制，可以說是很多環節都充滿了各種疑問。這個學期我們開了資訊保安課，可惜老師只是講了一些加密的演算法，加上教材的語言真的太深奧了，於是我自己去借了一些書籍檢視，最後終於弄清楚了自己的一些疑問。噗！必須要推薦《**密碼技術》這本書啊~（本文也是緩慢補坑）
那當然是因為http有很多缺點，我們可以例舉一些（來自**http這本書142頁）：
我們的目標當然就是盡力去彌補這幾個缺陷，所以我們針對1號缺陷，我們就對通訊進行加密。針對2號缺陷，我們就想辦法能確定雙方的身份。針對3號缺陷，我們就想辦法確定報文沒有被修改過。
下面，我們來假設有兩個孩子在通訊，乙個是alice小姑娘，還有乙個是bob小男孩（看書上這個例子也是密碼學上舉例慣用的姓名啊）。
說到加密，我們就必須先了解一下常用的加密方法：對稱加密和非對稱加密。
對稱加密簡單來說就是我用a口令去加密，同樣用這個a口令來進行解密。
目前市面上常用的對稱加密方法有：des，aes。
而非對稱加密就是我用a口令來加密，但是可以用b口令來進行解密。
目前市面上常用的非對稱加密方法有：rsa。
這裡的口令其實就是我們所說的金鑰啦~
我們首先來分析http的報文格式：報文頭+內容主體。報文頭一般是比較短的，內容主體內容可能會很長。
剛才介紹到的對稱加密方法，我們很容易發現只要我們有那個口令，就能完成加密和解密，所以alice用口令加密訊息後給bob，bob拿口令進行解密。但是問題是，口令也要安全傳給bob呀！所以可知，這樣其實解決不了根本的問題。
而非對稱加密的方法就可以解決這個問題，alice用a口令進行加密傳給bob，假如bob自己本來就有a口令對應的b口令，bob就可以進行解密，這樣alice就不用把口令傳給bob了。
但是我們用腦子想想也知道，很明顯非對稱加密的方式比對稱加密的方式要複雜一些，如果要計算肯定是花費很大。
報文頭的內容很短，我們也可以把訊息加密的金鑰存在這裡啊！這樣我們可以用非對稱方式加密報文頭，對稱方式加密報文體，這樣一來，就很好的保證了安全性，又減少了開銷。
相信很多童鞋都知道，https會有公匙和私匙這兩個東西的存在。這其實也是一種非對稱加密方式裡面的實現。
q：私鑰和公鑰是什麼？
a：公鑰很明顯，意思就是公共的鑰匙，意思是每個人都可以拿到這個鑰匙。私鑰則是自己的鑰匙，永遠都不能給別人。
q：私鑰和公鑰怎麼加密來傳輸資訊的？
a：首先，alice用bob的公鑰加密了一句我把100塊放在你的第乙個抽屜裡了，隨後bob就用自己的私鑰去解開這個加密的訊息，得到這個訊息。也就是說公鑰在這裡充當著加密的角色，而私鑰才能對應去解密。
如果黑客拿到了bob的私鑰，那麼一切都沒戲了，但是黑客拿到的是bob的公鑰的話，那他做的就是加密自己寫的訊息給bob罷了。
q：咦？真的會有這種奇怪的加密方法嗎？能舉個例子嗎
a：最常見的公鑰密碼演算法就是rsa加密方法了。
密文 = 明文e mod n （rsa加密）
e和n的組合是公鑰。
密文 = 明文d mod n （rsa解密）
d和n的組合就是私鑰。
以上，我們解決了訊息加密的問題。但是我們無法確定，和alice在進行交流的真的是bob嗎？和bob交流的又真的是alice嗎？
如果一開始bob在發布自己的公鑰的時候，來了乙個攻擊者mallory把這個公鑰換成了自己的公鑰給alice，那麼alice就會用mallory的公鑰來加密，那麼資訊就會暴露了。
所以我們必須要進行身份的確認。
情景假設：alice熬夜幾天辛苦的把**寫完了，倒頭就睡。但是第二天她起來要上交**的時候，如何判斷程式是不是被人更改過了什麼地方呢？
單向雜湊函式擁有：乙個輸入（訊息）、乙個輸出（雜湊值）。
無論這個輸入有多長，輸出的長度總是固定的。
所以我們可以讓alice給她的**用這個單向雜湊函式來生成乙個輸出，這樣保留好這個輸出值。第二天只要再用函式生成乙個輸出，對比一下就知道是不是有變化了。
簡稱為mac，是一種確認完整性並進行認證的技術。
完整驗證碼的操作需要任意長度的訊息、傳送者與接收者之間的共享金鑰（可以輸出固定長度的資料，即mac值）。
它的機制與單向雜湊函式比較類似，所以在上面我們先引入了這個概念。我們可以理解為:
訊息認證碼是一種與金鑰相關的單項雜湊函式所以兩者區別在於：
訊息---（單項雜湊函式）------>雜湊值
訊息---（訊息認證碼+金鑰）--->mac值
下面插乙個我自己畫的訊息驗證碼小劇場：
訊息驗證碼存在的問題:
重放攻擊
假設mallory去alice銀行向自己在bob銀行的賬號存100塊。
alice把這個訊息算出mac值後把訊息一起給了bob銀行，然後bob銀行發現是alice銀行發的，且內容也是正確的。
假如mallory把這個訊息重**n次，那bob每次肯定都會給mallory的賬號打錢啊。
解決方法:
序號：每次傳送訊息賦予乙個遞增的序號，計算mac值時這個序號也包括在其中。
時間戳：每次傳送訊息包含當前時間。
第三方證明
bob收到了alice的訊息，但是無法證明這條訊息來自alice，如果有乙個第三方證明victor的話就好了。但是他要介入就必須知道這個共享金鑰，這樣一來訊息驗證碼的安全性也會遭到威脅。所以訊息驗證碼無法彌補這個缺陷。
否認
bob收到了alice的訊息「我alice於今日向借了bob100塊」，但是alice否認這條訊息是她發的，因為她可以說這個訊息是bob自己生成的。而由於沒有第三個人能知道這個事情，所以bob證明不了這個訊息就是alice發的，而第三者也無法判斷真假。
訊息驗證碼出現缺陷就是因為使用了只有兩個人之間才知道的金鑰，這樣無法通過第三方來驗證。
數字簽名的機制其實和金鑰與公鑰的機制非常類似，相當於是「反過來用」的。alice用簽名金鑰生成訊息簽名，bob要驗證數字簽名，而第三方也和bob一樣可以對簽名進行驗證，所以bob和第三方都擁有驗證金鑰。
兩種生成和驗證數字簽名的方法:
直接對訊息簽名：也就是上面講的那個意思。
對訊息的雜湊值簽名：就是alice要先算出訊息的雜湊值，用私鑰對雜湊值進行加密，再把訊息和簽名發給bob。
反過頭來，我們可以發現數字簽名能解決「否認」這個問題。
ssl/tls在認證伺服器的身份是否合法的時候，就是加上了數字簽名的公鑰來驗證。
中間人攻擊
alice和bob在通訊的時候，黑客介入它們之中，面對alice的時候偽裝成是bob，面對bob的時候又裝作是alice，這樣能夠在不破解簽名演算法的前提下進行攻擊。
破解方法是確認自己的公鑰是不是真的屬於自己的目的物件（比如：alice打**直接問bob）。但是往往確認的內容會很多，我們可以生成雜湊值來確認。而實際上，公鑰密碼的軟體可以顯示公鑰的雜湊值，即指紋。
證書可以解決讓alice知道自己拿到的鑰匙到底是不是bob得，這樣就可以防禦中間人攻擊。
證書實質是乙個資料結構，是一種由乙個可信任的權威機構簽署的資料集合。而證書本身也分為很多種，常見的比如：pki證書、pgp證書等。
數字證書舉例（模擬教材畫的圖，其中ca是指簽證機構）：
q：那麼alice怎麼確定手上的公鑰匙bob的呢？
a：alice可以向bob/證書機構索要公鑰證書，然後alice拿簽證機構（ca）的公鑰去驗證這個簽名，就可以獲得bob真實的公鑰。
ssl/tls協議在網路層次中的位置：
q:ssl協議和tls協議的關係
a：tls是ssl 3.0版本上的公升級而來的。
q:ssl協議和tls協議只能搭配http使用嗎
a：顯然不是的，它們可以搭配很多協議。比如搭配傳送郵件的smtp協議和接受郵件的pop協議來使用。
在前文中我們講到的一些技術，搭配起來就能夠增加http協議的安全性，但是這些技術裡面也有很多不同的加密演算法，比如分享公鑰我們可以用公鑰演算法也可以用diffie-hellmanfan方法，這個是我們自己可以自由搭配選擇的，哪個部分的方法很弱，我們就可以再替換那個部分的方法。
但是如果完全客戶自定義了，很可能會出現溝通的障礙，因為接收方和傳送方的加密解密方法應該是配套的。所以官方提供了一些加密**組合，叫做密碼套件，供我們選擇。
記錄自己乙個呆萌呆萌的幾個bug
關於postman傳送post請求 注意post請求引數不會出現在位址列，用row行編輯，json格式，雖然手寫不太方便，但是可以保證準確，不要以為後台傳入資料null是springboot封裝資料物件出錯了，可能本身傳入的資料就有問題 後台bug2，requestbody required fal...
大眼呆萌隊 Beta衝刺 Day2
github位址 成員任務 溫騰虎實施軟體功能測試方案進行軟體各項功能測試 司紹斌實施軟體功能測試方案進行軟體各項功能測試 常夢嬌廖堃焱 成員任務 溫騰虎壓力測試 司紹斌壓力測試 常夢嬌壓力測試 廖堃焱壓力測試 1 登入頁面未輸入使用者名稱時不彈出提示框 2 登入頁面未選擇使用者身份時不彈出提示框 ...
Python萌新筆記
mychael上了大學，對python產生了濃厚的興趣，便開始了python的學習 學習的時候，感覺python確實比以往學的c 表達簡潔很多，而又不失強大 以後的學習筆記就記在這啦 python中的變數無需宣告，其類別也只有具體賦值的時候才確定 整型 int 1 字串 string1 hello ...