繼新發現的 POODLE 漏洞，我想在我的所有 SSH 伺服器上停用 SSLv3。如何使用 OpenSSH 實現此目的？
答案1
對 OpenSSH 來說這不是問題，因為它不使用 SSL。
摘錄-SSL 與 SSH 有什麼不同？哪個比較安全？他們對隧道周圍的事物有不同的看法。 SSL 傳統上使用 X.509 憑證來公佈伺服器和用戶端公鑰； SSH 有自己的格式。此外，SSH 附帶了一組用於隧道內部傳輸的協定（多路復用多個傳輸、在隧道內執行基於密碼的身份驗證、終端管理...），而SSL 中沒有這樣的協議，或者更準確地說，當這些東西在SSL 中使用，它們不被認為是SSL 的一部分（例如，當在SSL 隧道中進行基於密碼的HTTP 身份驗證時，我們說它是「HTTPS」的一部分，但它實際上以類似的方式工作SSH 發生的情況）。
從概念上講，您可以採用 SSH 並將隧道部分替換為 SSL 中的隧道部分。您也可以採用 HTTPS 並用 SSH-with-data-transport 取代 SSL，並使用一個鉤子從其憑證中提取伺服器公鑰。科學上不存在不可能，如果處理得當，安全性將保持不變。然而，目前還沒有一套廣泛的約定或現有工具。
作為進一步的證據，我會引導你RFC 4253，其中討論了「安全外殼 (SSH) 傳輸層協定」。這是 SSH 自己的自訂傳輸層，它與 HTTPS/SSL 使用的傳輸層不同。
本文檔描述了 SSH 傳輸層協議，該協定通常運行在 TCP/IP 之上。該協定可用作許多安全網路服務的基礎。它提供強大的加密、伺服器身份驗證和完整性保護。它還可以提供壓縮。
最後，來自安全 SE 網站的問答題目為：SSL3「貴賓犬」漏洞關於 POODLE 攻擊有這樣的說法。
摘抄Poodle 攻擊在選擇的明文上下文中起作用，就像之前的 BEAST 和 CRIME 一樣。攻擊者對受 SSL 保護的資料感興趣，他可以：
- 在自己想要取得的秘密值前後注入自己的資料；
- 檢查、攔截並修改線路上產生的位元組。
滿足此類條件的主要也是唯一可能的場景是 Web 上下文：攻擊者運行一個虛假的 WiFi 接入點，並註入一些自己的 Javascript 作為受害者瀏覽的網頁（HTTP，而不是 HTTPS）的一部分。邪惡的 Javascript 使瀏覽器向 HTTPS 網站（例如銀行網站）發送請求，受害者的瀏覽器擁有該網站的 cookie。攻擊者想要那個 cookie。
因此，OpenSSH 無需針對此特定威脅採取任何操作。