SSL 3.0 Fallback protection-SSL 3.0 降級保護(hù)策略

一、背景

自從大學(xué)畢業(yè)后,閱讀英文的文檔水平很差(其實(shí)未畢業(yè)也是這樣的水平),極其痛恨自己看美劇這么久還是要慢慢看中文字幕(能學(xué)會看英文字幕也不錯吧?!),加之自己的安全知識過于薄弱,就從Open SSL的Security Advisory開始進(jìn)行翻譯吧。再者,很久沒寫Markdown,也很久沒寫文章,借此機(jī)會也好好訓(xùn)練一下。翻譯得不好的,請見諒,會努力逐漸進(jìn)步。

二、原文

SSL 3.0 Fallback protection
===========================

Severity: Medium

OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications
to block the ability for a MITM attacker to force a protocol
downgrade.

Some client applications (such as browsers) will reconnect using a
downgraded protocol to work around interoperability bugs in older
servers. This could be exploited by an active man-in-the-middle to
downgrade connections to SSL 3.0 even if both sides of the connection
support higher protocols. SSL 3.0 contains a number of weaknesses
including POODLE (CVE-2014-3566).

OpenSSL 1.0.1 users should upgrade to 1.0.1j.
OpenSSL 1.0.0 users should upgrade to 1.0.0o.
OpenSSL 0.9.8 users should upgrade to 0.9.8zc. 

https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
https://www.openssl.org/~bodo/ssl-poodle.pdf

Support for TLS_FALLBACK_SCSV was developed by Adam Langley and Bodo Moeller.

三、譯文

SSL 3.0  降級保護(hù)策略
=============================================
安全等級:中等

OpenSSL已經(jīng)增加對TLS_FALLBACK_SCSV允許程序禁用協(xié)議降級的支持。此選項(xiàng)能夠拒絕從SSL協(xié)議降級時所受到的中間人攻擊。

一些客戶端程序(例如瀏覽器)會使用協(xié)議降級的方法重連一些兼容性較差的老舊服務(wù)。這樣從高版本協(xié)議降低到SSL3.0的處理會被中間人去利用獲取信息,即使是兩邊都支持高版本的協(xié)議。SSL 3.0包含一系列的漏洞,包括POODLE(CVE-2014-3566)。

四、學(xué)習(xí)

POODLE這個漏洞爆出之后,很多廠商紛紛上配置改Apache改Nginx,將SSLv3.0以下的版本都禁掉(順便也把SSLv2也殺掉),從此只支持TLS。

下文是轉(zhuǎn)網(wǎng)上的一篇文章:

Google的建議:關(guān)閉客戶端SSLv3支持或者服務(wù)器SSLv3支持或者兩者全部關(guān)閉。

建議支持TLS_FALLBACK_SCSV,這可以解決重試連接失敗的問題,從而防止攻擊者強(qiáng)制瀏覽器使用SSL3.0, 它還可以防止降級到TLS1.2至1.1或1.0,可能有助于防止未來的攻擊。

SSLv3漏洞的解決方案如下:

  1. 如果要完全避免此漏洞,需要禁止使用SSLv3協(xié)議;
  2. 考慮到老版本瀏覽器(如IE6)的默認(rèn)設(shè)置為SSLv3協(xié)議,如果直接禁用SSLv3協(xié)議,將導(dǎo)致這批采用默認(rèn)設(shè)置的用戶無法訪問對應(yīng)網(wǎng)站,可以采用通過修改webserver的SSL配置來修復(fù)這個問題,配置實(shí)現(xiàn)的效果是客戶端通過SSLv3協(xié)議訪問https業(yè)務(wù)時雙方使用RC4-SHA加密,而采用TLS1.0或更高版本協(xié)議時優(yōu)先使用其他強(qiáng)加密算法。 RC4-SHA加密方式未驗(yàn)證是否能夠避免問題
  3. 某些移動客戶端訪問的應(yīng)用在禁止SSLv3或更改SSL配置時,需要考慮到移動客戶端中是否指定了使用SSLv3協(xié)議或者采用CBC模式的塊加密,如果有這個問題則需要先修改客戶端的實(shí)現(xiàn)才能執(zhí)行修復(fù)方案,否則移動客戶端的訪問將受影響。
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容