2. https原理
ssh在網路的兩台主機之間提供加密資訊傳輸,常見的應用包括遠端登入(公司內部開發機)和檔案傳輸(scp), rsa為加密演算法之一,為非對稱加密方法
為什麼要採用加密傳輸?
如果使用明文傳輸,會有3大風險:
1) 竊聽風險: 第三方可獲知通訊內容
2) 篡改風險: 第三方可修改通訊內容
3) 冒充風險: 第三方可冒充他人身份參與通訊
如何解決明文傳輸的風險?
1) 所有資訊均加密傳輸,消除竊聽風險
2) 資訊末尾使用校驗碼,並和資訊一同傳輸,如果資訊被新增,刪除或修改,接收方校驗碼不匹配
3) 使用認證機制(如ca證書)解決冒充風險(中間人攻擊)
加密傳輸的方式
1)對稱加密: 加密和解密的密碼相同
優點: 簡單,可靠性高.只要秘鑰不被洩露.就能保證資訊傳輸的安全
缺點: 秘鑰需要在雙方共享,不能在網路上傳輸,因為傳輸秘鑰不能再對稱加密,只能明文傳輸,或通過其他安全的方式傳輸.明文傳輸則對稱加密就失去了意義
2)非對稱加密: 加密和解密的密碼不同,使用公鑰和私鑰,一種用來加密,另一種用來解密,缺點是計算複雜. 公鑰可以在網路上傳輸,私鑰只能在本地儲存.a只能用自己的私鑰或對方的公鑰加密. 不能用自己的公鑰加密,因為這樣傳輸給b後b需要利用a的私鑰解密,而a的私鑰是不對外公開的.
如果只用a產生的秘鑰對進行加密和解密,存在單向傳輸風險:
a 傳送訊息給 b: a(a的私鑰加密) --> b(a的公鑰解密)
b 傳送訊息給 a: b(a的公鑰加密) --> a(a的私鑰解密)
b只要知道a的公鑰即可完成雙向加密傳輸,但是從a傳送訊息給b是不安全的,因為使用公鑰解密了, a的公鑰是公開的,如果c也知道a的公鑰,那麼就能獲知a傳送給b的訊息;從b發給a的訊息是安全的, 因為即使c知道了a的公鑰,也無法對訊息解密.
為解決單向傳輸風險,只能使用一種模式: 使用傳送方使用接收方的公鑰加密,接收方使用自己的私鑰解密,因此需要a和b均持有自己的公鑰和私鑰.然而如此進行資料傳輸,計算開銷太大
遠端登入只需要客戶端登入進服務端,服務端已經預先儲存了客戶端的憑證,需要驗證客戶端向服務端傳送的憑證是否與預存的一致,只需要保證客戶端向服務端的單向傳輸安全即可
方式一: 密碼登入(密碼認證)
服務端持有的憑證是客戶端的密碼,需要驗證客戶端提供的密碼是否與儲存的密碼一致, 保證密碼傳輸的安全性
1) 客戶端連線伺服器,發起登入請求
2) 伺服器向客戶端傳送自己的公鑰
3) 客戶端將密碼使用伺服器的公鑰加密後傳輸給伺服器
4) 伺服器使用自己的私鑰解密登入密碼,如果正確,則允許客戶端登入
方式二: 公鑰登入(公鑰認證)
服務端持有的憑證是客戶端的公鑰,需要利用公鑰私鑰的唯一配對特性驗證客戶端身份
1) 客戶端預先將自己的公鑰使用安全的方式存放到伺服器上(https)
2) 客戶端連線伺服器,發起登入請求
3) 服務端將乙個隨機字串傳送給客戶端
4) 客戶端使用自己的私鑰加密該字串後傳送給服務端
5) 服務端使用客戶端的公鑰解密該加密後的字串,如果與傳送的字串一致,則允許客戶端登入
非對稱加密 + 對稱加密: 非對稱加密傳輸對稱加密的密碼, 而後使用對稱加密傳輸,如scp
客戶端連線伺服器,請求檔案傳輸
伺服器給客戶端傳送伺服器的公鑰(在此之前可能需要對客戶端的認證,密碼認證或公鑰認證)
客戶端使用伺服器的公鑰加密對稱加密的密碼
伺服器解密客戶端傳送的對稱加密的密碼
客戶端和伺服器使用對稱加密的密碼加密檔案後雙向傳輸
$ ssh-keygen -t rsa -c 「[email protected]」
在~/.ssh目錄中會產生兩個檔案: id_rsa, id_rsa.pub, 分別為私鑰和公鑰
客戶端訪問過的主機的公鑰儲存在 ~/.ssh/known_hosts檔案中(客戶端向伺服器傳送登入請求)
伺服器儲存的客戶端的公鑰儲存在 ~/.ssh/autorized_keys檔案中(實現客戶端的免密認證)
https = http + tls, tls使用了
與ss**件傳輸相同的傳輸方式,保證資訊不會被監聽
校驗碼,保證資訊不會被修改
ca證書,避免了中間人攻擊
a公司的員工小李要到b公司辦理業務,a公司給他開了一封介紹信,並蓋上a公司的公章, b公司與a公司一直有業務往來,其前台認出了介紹信中a公司的公章,因此接待了小李;
隨著公司業務的迅速發展,想要與b公司有業務往來的公司越來越多,前台要記住每乙個陌生公司的公章頗有難度,因此出現了公司身份真實性認證的權威機構c. 這時當a公司的小李再次來到b公司時,帶來了兩份檔案:
1) a公司的介紹信,其上有a公司的公章
2) 機構c給a公司頒發的證書,其上有a公司的公章和機構c的公章,證明a公司身份的真實性
b公司的前台首先檢視證書,證實了機構c公章的真實性,然後比對證書上和介紹信上的a公司的公章,發現兩者一致,因此確認了小李來自a公司,接待了小李
a公司: **
b公司: 瀏覽器
c機構: ca證書簽發機構
a公司的公章: **a提供的公鑰
c機構的公章: c機構為簽發給**的ca證書使用自己的私鑰生成的簽名
小李: **提供的內容
ca證書內容: **的公鑰 + **和ca機構的資訊 + ca機構生成的數字簽名
數字簽名:
1) hash 證書的明文內容得到摘要
2) 使用ca機構的私鑰對摘要加密
瀏覽器通過https訪問的過程:
1) 瀏覽器向**發出請求,**返回證書
2) 瀏覽器讀取證書的明文內容,使用相同的hash函式得到摘要
3) 瀏覽器使用內建的ca機構的公鑰對簽名解密,生成摘要
4) 瀏覽器比對兩個摘要,如果一致,則信任**
5) 瀏覽器使用**的公鑰加密對稱秘鑰傳送給**
6) **使用自己的私鑰解析出對稱秘鑰
7) **和瀏覽器使用該對稱秘鑰加密檔案傳輸
注: ca機構需要自己準備乙份給自己的證書(根證書),瀏覽器如果內建了該ca機構,則信任該ca機構,證書合法, 如果該ca機構沒有內建,則證書非法,根本不會繼續驗證**的真實性
參考文章:
**ssl ssh加密原理_運維_小樓吹徹玉笙寒-csdn部落格.
ssh原理講解與實踐 - 森林326 - .
ca認證的原理和流程及https原理 - brucelong - .
幾種方法來實現scp拷貝時無需輸入密碼_運維_nfer_cn的專欄-csdn部落格.
Https 與對稱加密和非對稱加密
總結沒有 https，使用者傳輸的資料，如賬號密碼，會被不法分子截獲。客戶端請求一次服務端後，服務端給客戶端乙個金鑰。然後他們傳輸的資料會用金鑰加密。但第一次告訴客戶端金鑰的時候也可能被不法分子截獲。服務端有自己的公鑰和私鑰。客戶端請求一次服務端後，服務端提供自己的公鑰，客戶端 瀏覽器 收到後自己生...
HTTPS之對稱加密和非對稱加密
1.對稱加密 a 客戶端 b 服務端 a和b實現對稱加密的前提條件是a和b必須共享同乙個公鑰 1.a使用公鑰對資訊進行加密 2.a把加密之後的密文傳送到b 3.b使用約定好的公鑰對密文進行解密 2.非對稱加密 a 客戶端 b 服務端 非對稱加密在進行加密的時候使用的是b建立的金鑰對 b的公鑰和私鑰 ...
HTTPS加密流程
1 客戶端發起https請求首先向服務端傳送客戶端ssl tls協議版本號 支援的加密演算法種類 如 rsa加密演算法，des對稱加密演算法，sha1摘要演算法 產生隨機數等資訊 2 服務端向瀏覽器回傳 ssl tls 協議版本號 選擇一種客戶端瀏覽器支援的加密演算法和hash演算法 隨機數 服務端...