會話管理，SSL，WSGI和Cookies

Question

我正在評估實現wsgi-app瀏覽器會話管理的可能性和可行性，而不使用任何現成的中間件。

所考慮的一般方法是：

在瀏覽器和服務器之間使用SSL。 將SSL會話標識公開到WSGI或OS.environment，以用作會話標識以啓用應用程序級別的持久性和身份驗證。 因爲如果服務器+瀏覽器再次握手，SSL會話ID可能隨時發生變化，所以想法是使用cookie來保存生成的SSL ID的散列版本。 如果檢測到握手和SSL ID更改（暴露給環境的SSL會話ID與客戶端返回的cookie不匹配），則可以檢查哈希cookie以查看它是否包含先前已知的會話ID，if那麼我們應該繼續當前會話並更新cookie中使用的SSL會話標識（並存儲在後端數據庫中），以作爲新生成的握手SSL會話標識。因此，即使SSL會話ID可以在我們的腳下改變，我們仍然可以繼續會話。

根據我的理解，這個想法是讓SSL生成會話ID，並且做一些比依靠cookie + hmac來保存會話ID更安全的事情。

我會對任何人對上述過程的想法感興趣。原則上，我聽起來很合理，但我對這種功能的使用經驗很少。我已經繪製了幾個場景下客戶端&服務器& wsgi-app之間的交流流程，它看起來工作得很好，但我不舒服我已經涵蓋了所有的基礎。

Answer 1

有什麼不對您的協議

你可能要考慮以下幾點：

1. 愛麗絲接觸您的服務器並獲取SSL會話ID S。包含H(S)的cookie被髮送給Alice。
2. 鮑勃正在收聽交流。 SSL會話ID未加密，因此他可以讀取S。
3. Bob將會話cookie設置爲H(S)與您的服務器聯繫。他的會話ID沒有被識別，但是你的系統無論如何都會讓他進入Alice的會話中（也可能會把Alice踢出去！）。

解決方案然後是使用HMAC所以簽署會話ID。但是，你可能首先使用一個HMAC'ed會話ID。

---

的一些細節：

• 知道cookie的，他應該發送的名稱，鮑勃只需聯繫您的服務器。
• 鮑勃可以做同樣獲得哈希算法的概念，您使用的是

什麼是偉大的HMAC

會話Cookie + HMAC已經被證明是加密安全。爲了驗證數據，HMAC爲設計了。邏輯behing HMAC是健全的，到目前爲止，還沒有協議存在的攻擊。

更好的是，它被證明比攻擊基礎Hash算法並不意味着對HMAC的攻擊存在（這並不意味着你應該使用MD5！）。

還有沒有理由爲什麼你不想使用HMAC。

---

對於負載均衡器，SSL會話ID最多是有用的。

千萬不要實施你自己的密碼學

你永遠不應該重新發明密碼學。密碼算法已被（可能）數千名在該領域具有豐富經驗的人員審查過。

每當你覺得你有更好的主意，你可能會錯過一些東西。也許你不會！但是，你應該在你的算法上寫一篇論文，並讓它進行同行評審。

堅持標準。