互連網伺服器的實現過程需要考慮哪些安全問題 & 加解密及雜湊知識點

標籤：glib   targe   關閉   改變   實現   hostname   byte   環境   art   

http://www.cnblogs.com/charlesblc/p/6341265.html 其中的一篇。

參考

https://zhuanlan.zhihu.com/p/20336461?refer=auxten

 

網路編程（四）：互連網中TCP Socket伺服器的實現過程需要考慮哪些安全問題？

在Internet環境下，安全問題我主要分為如下幾類：

1. 資訊傳輸過程中被駭客竊取
2. 伺服器自身的安全
3. 服務端資料的安全

 

首先，如果能用https，就盡量用https，能用nginx等常見伺服器，就用常見伺服器，主要能避免以下問題：

• 自己實現的協議&Server端可能會有各種Bug，被緩衝區溢位攻擊等
• SSL加密體系在防監聽方面已經足夠成熟，值得信賴

 

如果需要自己實現Server端，實現一套合格的SSL還是很考驗功底的：

• 首先要弄明白SSL加密體系金鑰交換的原理
• 對各種對稱、非對稱式加密演算法要有深刻的理解
• 用非對稱式加密演算法怎麼實現一套金鑰交換體系
• 如何處理ca認證，在自簽名情況下怎麼避免中間人攻擊

工程實現過程中，要考慮：

• 各種可能的緩衝區溢位攻擊
• SYN flood攻擊，慢串連攻擊
• DDoS防起來有難度，但至少能防禦DoS攻擊

商務邏輯層面，要考慮：

• 每個介面都要做好使用者&許可權驗證
• 介面會不會被人亂用，重放攻擊
• 攻擊方會不會找到一個比較消耗服務端資源的介面，用很小的代價耗盡服務端資源
• 使用者的使用者名稱密碼會不會被通過介面破解，參見：2014 celebrity photo hack
• 你的服務會不會被駭客利用去攻擊別的服務，特別是會根據使用者輸入抓取什麼資源的服務
• 古老的SQL注入
• 無恥的仿冒服務，DNS欺詐
• 涉及HTML的，還要考慮跨站……

即使你做到了天衣無縫，還要考慮隊友有時會掉鏈子：

• glibc、openssl這些基礎的庫也會爆出漏洞，參見：Heartbleed
• 同一台主機上的其它服務被攻陷

寫完之後整個人都不好了

關於加密解密演算法參見：加解密（Encryption）& 雜湊（Hash）演算法----入門指引 - 面向工資編程 - 知乎專欄 

一、Encryption演算法和Hash演算法的區別

• 資訊理論角度：
• Encryption是可逆的，沒有資訊熵的改變
• Hash是無法復原的，Hash一般會導致資訊熵減小
• 應用角度：
• Encryption常被用來做基於密鑰的資料加解密（AES、RSA、ECC）
• Hash主要被用來做數位簽章、資料校正（CRC、SHA、MD5）
• 小白角度：
• Encryption就是帶密碼的保險箱
• Hash就是榨汁機，有去無回

二、加解密演算法分為對稱（Symmetric）、非對稱（Asymmetry）兩大類

• 對稱（Symmetric）加密
  • 　　對稱式加密的演算法非常之多，一般使用中用AES就基本夠用了。

非對稱（Asymmetry）加密

• 非對稱式加密演算法，就是加密、解密的密鑰分為兩組，並且互相不能反推。這種演算法在現實中很難有什麼事物可以類比。大致就是通過某種演算法可以產生一個金鑰組k1、k2，用k1加密之後的密文只能用k2解密，反之亦然。
  非對稱式加密演算法從原理上講常用的有兩種：
• 基於因數分解的演算法
• RSA、DSA是此類演算法中的代表，Linux系統的SSH就是基於這兩種演算法進行檔案key auth。前幾年一般建議RSA至少要達到1024位密鑰才能保證抵禦暴力破解，但由於GPU和超級電腦的算力提升，現在密鑰長度建議2048位了。
• 橢圓曲線演算法（ECC）

• 非對稱式加密演算法非常酷，但它有一個致命的缺點：慢。RSA加密的速度大致是AES的1/30左右。所以我們不可能在所有場合都採用這類密碼編譯演算法。我們的程式猿前輩們就創造了SSL、TLS等加密體系：

 

三、加密體系

TLS的前身是SSL，HTTP + TLS = HTTPS

一旦用戶端和伺服器都同意使用TLS協議，他們通過使用一個握手過程協商出一個有狀態的串連以傳輸資料[1]。通過握手，用戶端和伺服器協商各種參數用於建立安全連線：

1. 當用戶端串連到支援TLS協議的伺服器要求建立安全連線並列出了受支援的密碼組合（加密密碼演算法和加密雜湊函數），握手開始。

2. 伺服器從該列表中決定加密和散列函數，並通知用戶端。

3. 伺服器發回其數位憑證，此認證通常包含伺服器的名稱、受信任的憑證授權單位（CA）和伺服器的公開金鑰。

4. 用戶端確認其頒發的認證的有效性。

5. 為了產生工作階段金鑰用於安全連線，用戶端使用伺服器的公開金鑰加密隨機產生的密鑰，並將其發送到伺服器，只有伺服器才能使用自己的私密金鑰解密。

6. 利用隨機數，雙方產生用於加密和解密的對稱金鑰。

7. 這就是 TLS 協議的握手，握手完畢後的串連是安全的，直到串連（被）關閉。如果上述任何一個步驟失敗，TLS 握手過程就會失敗，並且斷開所有的串連。

 

五、鹽的重要性

之前在這篇文章中提到過，如果單純的把檔案按塊去加密，即使採用最強壯的演算法也會存在一個很明顯的漏洞，這裡不再贅述，參見：用已知密碼編譯演算法AES加密文本123，得到密文xxx，問能否根據密文、密碼編譯演算法、原文本123直接推匯出密鑰是什嗎？ - auxten 的回答

關於雜湊函數的選用：

工作中發現，很多人對雜湊函數的瞭解僅限於MD5。例如，在做資料庫的分庫分表的時候，可能需要對hostname做一次雜湊再去模數，這裡採用MD5就顯得過於浪費CPU。要知道MD5平均會將每個Byte進行6.8次運算代入。

如果只是需要利用雜湊的離散型，完全可以採用更輕的雜湊演算法

互連網伺服器的實現過程需要考慮哪些安全問題 & 加解密及雜湊知識點