SSL 運作原理、安全威脅與防護之道
2014許多SSL 的資訊安全風險發生，
SSL 被廣泛運用在 Browser 與 Web Site 溝通的加密與身分驗證
因為Browser 都會內建 CA 認證，
只要透過 HTTS 就可以建立以 SSL/TLS 的驗證與加密機制
因此SSL 被廣泛的應用在各種雲端服務的加密傳輸
這篇文章主要針對 SSL/TLS 的下列議題討論：
1. 什麼是 SSL/TLS?
2. SSL/TLS 差異
3. SSL/TLS 認證加密過程
4. SSL/TLS潛在資訊安全風險
5. 如何做基本的SSL測試知道網站 HTTPS 是否有風險?
6. SSL/TLS 網站防護建議
SSL/TLS的關係
SSL (Secure Socket Layer) 原先為 NetScape 所開發，
SSL 1.0/2.0 因為有些漏洞陸續被找到因此，接著有 SSL 3.0
但是也因為 SSL 3.0 最近被找到一個嚴重的漏洞(POODLE attack)，
造成SSL 溝通過程中所加密的資訊可以被解密，因此也建議用 TLS
什麼是 TLS
TLS (Transport Layer Security) 是根據 SSL 3.0 為基礎設計
最新版的 TLS 1.2 幾乎等於 SSL 3.0
但是還是有些細微的差異，這個差異在於一些已知弱點的加密演算法補強
參考Wiki列表如下
SSL 加密與認證的過程
要了解 SSL 所造成的漏洞與資訊安全風險，首先必須先了解 SSL 加密認證的過程，
Browser 用 HTTPS 連線到Web Server時，Browser會跟 Web server 進行Handshek ，
流程如下
1. Browser Client =======HttpS://Website.com/ ===============>>>> WebSite
- Browser 發出 https connect 到 WebSite
- 另外，送出Browser 目前支援的加密演算法、TLS/SSL版本等
2. Browser Client <<<<=== Web Site Certificate encrypted by private Key====WebSite
- Website 用自己的 private Key 加密網站的 CA certificate (Website.com)
- Browser Client收到加密的訊息之後，試著用 Website.com 的 public Key 解密，解開之後驗證CA certificate訊息內容是否為 WebSite.com，藉由這樣認證該網站的真實性。
- 另外，Website.com也送出目前支援的加密演算法、TLS/SSL版本等，Browser/Website 會相互配對決定兩者都可以支援的加密與 TLS/SSL通訊協定。
3. Browser Client ====== SessionKey encrypted by Public Key =====>>>>WebSite
- Browser 接著將接下來要傳輸資料要用到的加密金鑰訊息，用 Website 的public key 加密傳送給 Website
- 由於該加密是用 Website.com 的public key 加密，因此只有 Website.com的private key 才有辦法解密知道該 Session Key
- SessionKey 每次都會不同，隨機亂數產生，只有在當下 Browser 與Website才會知道
- WebSite.com 收到之後，就會用自己的 private key 解密知道接下來資料傳輸需要用什麼 session key 加密
3. Browser Client <<<<== Encrypted Data tron with SessionKey ==>>>>WebSite
- 雙方用協議好的 session key 與加密演算法將接下來的資料傳輸加密解密。
這個 SSL/TLS handshake 的過程如下圖紅色框框所示 (圖表來源：MSDN)
SSL/TLS 資訊安全風險
那麼問題出現在哪呢? 為什麼 2014有許多重大的 SSL 資訊安全風險被找到呢?
Heartbleed / OpenSSL CVE-2014-0160
上述加密的過程 Web Server private key 十分重要，
如果 Web Server private 可以被取得的話，整個加解密的過程就很被破解
因此，這個 HeartBleed 主要的發現在於透過網站記憶體上的存取，
可以將Web Server 的 private取得，
所以迫使 OpenSSL 必須要呼籲所有用到 HTTS 的網站都要更新 OpenSSL 版本
POODLE /CVE-2014-3566
Poodle的發現在於SSL 3.0中有一個加密演算法，被發現有破解的方法，
造成加密的資料內容有可能因為 Man In the Middle 而被解密
相對於 HeartBleed來說，這個技術實務上發生的機率相對較低，
但是，難保病毒會利用這樣的原理，竊取所有的https 傳輸內容資訊
解決的方法，網站設定使用新版的 TLS 1.2的通訊協定。或是停止 SSL 3.0的支援。
網站測試
有什麼什麼比較簡便的方法，測試網站是否有 SSL/TLS 相關已知的風險呢?
這個網站只要您將受測網站的網址輸入，
就會給該受測網站相關 SSL/TLS設定、已知風險做測試
並且會給一個報表，告訴您該網站的 SSL/TLS風險與建議
O-Saft
另外可以使用這個工具測試內部網站 SSL/TLS設定的正確性與潛在的風險。
www.owasp.org/index.php/O-Saft
網站防護建議
網站防護有什麼要注意的地方呢?
- 妥善的保護 Website private key
- Renew Certificate with New private Key
- Certificate 要包含所有的網站 domain name。例如. www.site.com 與 site.com等。避免用萬用字元
- 選擇有公信力的 CA單位
- 如果可以盡量設定使用 TLS 1.1/1.2
- 使用 128bits 以上的加密演算法
- HTTP Strict Transport Security (HSTS)：這個設定可以強迫 Browser/Web 間所有的傳輸一定要透過 HTTPS。