年底到了，又開始專案系統忙著黑白箱的掃瞄。
每到此時， 就會心煩氣燥，因為不管新舊系統都要面臨各項工具的檢測，然後就一直在不斷的修改測試再送檢測，每回回來的報告有高中低風險，心裡的OS都會是幹字無限迴圈。
整個政府都被這些黑白箱工具廠商給綁架了，連帶我們這些小本經營的資訊廠商也一起綁著跳入這萬劫不復的火坑中，真痛苦。
先說Micro Focus WebInspect黑箱檢測，其中有個Insecure Transport: Weak SSL Cipher ( 11285 )和Insecure Transport: Insufficient Diffie Hellman Strength ( 11520 )，這是有關TLS CIPHERSUITES 設定的弱點，看似一個很單純的FIX卻花了我好幾天。
一般都用IISCRYPTO工具來關閉較弱 Cipher，一如往常，我也是給他設定後重開機，然後再用TLSSSLSERVER.EXE做檢測。神奇的是TLSSSLSERVER檢測的結果竟然與IISCRYPTO UI不符。
當天連續做了四台主機設定，竟有二台有檢測不符的狀況。一時間自已也搞不清楚，一直以為是因為先前主機套用GCB(政府組態基準)造成的。
後來原因竟是前面WAF設備CACHE造成外部一直讀取到未更新的 Cipher，這WAF又是一個錢坑。資安都坑這些花錢不手軟的大爺們，哈哈。
最後解決鬼打牆的CACHE後，終於設定好 Cipher，原則上現在CBC都屬不安全的協定
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA _WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_ GCM _SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
結果一設好，使用者就打來說無法連線。但查看系統LOG卻是大部份使用者都可正常使用。那些無法使用的都是WIN7 + IE11，很神奇的是WIN7的CHROME/FIREFOX也都正常。
想著想著，再用TLSSSLSERVER.EXE檢測一次，這才發現設備廠商又沒將Cipher設定正確只設了
TLS_ECDHE_RSA_WITH_AES_256_ GCM _SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(說到這，我也不懂為啥清掉CACHE後，廠商說還得要在設備中再指定一次Cipher??)
最後使用network monitor工具查看到底WIN 7+IE11 (才支援TLS1.2)是使用什麼Cipher，一看之下，剛好就只支援廠商漏設定那二組。
這幾天又重新目睹了WIN7的風釆，但沒有懷念，哈哈。
