最近不小心遇到了這個東西，才發現還真是對它完全不熟 =.=
當初為了要驗證這個弱點，找了一大堆工具來測，測出來結果竟然一半一半!?!? (一半說有這弱點一半說沒有)
最終證明公信力強的工具測出來皆不是誤判，會讓你感覺到誤判了其實是驗證的工具設定沒有對所以沒測出來。(別再說服自己已經修了!)
弱點說明：
Compression
Ratio Info-leak Made Easy (CRIME)，這是一個針對Web cookie的攻擊，若網站有使用HTTPS及SPDY(Google開發的類似HTTP協定)則允許data
compression(資料壓縮)。
CRIME是Client端的攻擊，但也可透過Server端來防禦。只要Server端不支援compression(以CRIME來說是Deflate compression)，就可以解決此問題。
CRIME的防禦在於停用compression，無論是Client端瀏覽器在傳送HTTPS/SPDY Request時停用compression，還是Server端TLS停用data
compression。
最簡單的解決方式是Server直接改為僅允許使用TLS 1.2，因為其提供的compression method只有'NONE'一種(no compression)。
通常在建立連線之時，Client會發送一系列的Client Hello，包含其支援的compression method。
而Server收到Client Hello後，只能選擇Client提供的其中一種compression方式包進Server
Hello做回覆。
因此若TLS 1.2僅有compression method: NONE，那麼Server也只能對此種方式做回應，便不會對資料進行compression。
CRIME是一種普遍性攻擊，因為它可以攻擊很多種協定，如SPDY(通常對Request Header做compression)、TLS(可能會對Record做compression)、HTTP(可能會對Response做compression)。
-
嚴重性：中風險
影響：導致可取得SSL加密的敏感資料，最直觀的攻擊方式是透過此漏洞取得受害者的cookie並以此受害者身分登入
CVE: CVE-2012-4929
CWE: CWE-310
-
檢測方式：
工具一：Acunetix (SSL_Audit.script)
本來當初就是被Acunetix找到，但怕是誤判總是要多試幾個工具。
工具二：SSL Labs (線上)
當SSL/TLS compression為 Yes INSECURE 代表有弱點!
工具三：TestSSLServer (支援Windows, Linux,
OS X)
TestSSLServer2.exe
<target>:<port>
這一隻是OWASP裡提到的測試工具，當掃描結果出現Server compression support: yes(以及WARN[CP001]: Server supports compression)代表有CRIME。
官方說明：
CP001:
Server supports compression.
Compression
makes data length depend on data contents, thereby leaking information, since
encryption does not hide length. This can be leveraged in some contexts to
reveal secret values (attack "CRIME").
SSL/TLS-level compression should be disabled. Compression, if used at all in a
protocol, should be applied at the application level (e.g. HTTP compression),
with great care.
工具四：sslyze
sslyze --compression
<target>:<port>
(吃本機OpenSSL注意!)
錯誤訊息：utils.ctSSL.errors.ctSSLFeatureNotAvailable
- Could not enable Zlib compression: OpenSSL was not built with Zlib support ?
(懶懶的跳過不測了)
工具五：testssl.sh
./testssl.h -C <target>:<port>
(吃本機OpenSSL注意!)
錯誤訊息：Local problem: /usr/bin/openssl lacks
zlib support
自己包一隻OpenSSL就可解決錯誤訊息。
工具六：sslscan (會誤判)
sslscan --no-failed
<target>:<port>
(我猜他應該也是吃本機OpenSSL，不過測試失敗不會有錯誤訊息反而直接顯示Compression disable，哀傷)
工具七：OpenSSL (有前提)
openssl s_client
-connect <target>:<port>
前提：要能送出有compression method: DEFLATE的Request
(可自己make，參考補充2)
若結果出現Compression: NONE，代表沒問題，Compression: zlib compression代表有問題。
以Kali內建的OpenSSL為例，透過WireShark查看封包，發現此版本OpenSSL無法驗證此弱點，因其送出的Client Hello只有一個null compression method。
然而若使用自製的OpenSSL，確實可進行CRIME測試：
還有一種測法是：(沒試成功過)
openssl s_client
-connect <target>:<port>
CONNECTED(00000003)
[skip
certificate info]
GET / HTTP/1.1 [Enter]
Host: google.com
[Enter]
Accept-Encoding:
compress, gzip [Enter, Enter]
若回應有出現Content-Encoding: gzip，表示有問題。
但同樣的，此種方法也只是多送出Application Data而已，若OpenSSL一開始便無法送出指定DEFLATE compression method的封包就沒有用。
補充(1)：用WireShark查看Compression Method DEFLATE
這邊用TestSSLServer來跑看看，可以看到本機送出了一堆Client Hello，裡面有要求DEFLATE
Compression：
Filter:
ip.addr==<target
ip> && ssl
而Server Hello也確實回應：
補充(2)：自製可測CRIME的OpenSSL (參考)
./config enable-comp enable-zlib
--prefix=/usr/local/openssl-1.0.2l
--openssldir=/usr/local/openssl
make
make test
make install
修補建議：
停用SSL/TLS compression及HTTP compression。
以Apache為例：
[Disable
SSL Compression]
版本2.4以上，支援SSLCompression flag，預設為on，改為off就好。
[Disable
HTTP Compression] (參考)
可用mod_deflate
設定export OPENSSL_NO_DEFAULT_ZLIB=1
結論：
其實用前三個工具就足矣。
不過測SSL的工具真是百百種，有興趣可以看看這個XD
