設計 SSL 或 TLS 時的省思

(http://antbsd.twbbs.org/~ant/wordpress/?p=115, April 20th, 2006)

在 IEBlog 看到關於 SSL 與 TLS 設計時的省思。

* 因為這類安全連結會花費很多處理(multistage handshake)，所以大多網頁程式設計師都偏好用 HTTP，或用 HTTP+HTTPS 混雜的方式。(the multistage handshake with multiple roundtrips and cryptographic operations is inherently less performant than straight HTTP)

* SSL/TLS 的憑證未必是合法的，通常使用者會習慣接受憑證，但有些惡意的網站也會申請合法的憑證。

* 嚴重的錯誤1：非 HTTPS 的登入畫面 [Critical Mistake #1: Non-HTTPS Login pages (even if submitting to a HTTPS page)]。我想是雖然 login form 的網頁是在 HTTPS 下，但是 from submit 時是由 HTTP 傳輸，這樣只是外表上的安全。

* 嚴重的錯誤2：在 HTTPS 網頁中混雜 HTTP [Critical Mistake #2: Mixing HTTP Content into a HTTPS page]。這樣雖然可以指明「本網頁有包含安全與不安全的傳輸」，但使用者不知道什麼才是在安全的連線上。而且惡意的人可以在中間篡改 HTTP traffic，甚至他可以立即修改原網頁 HTTPS 的部份，改成他自己寫的 DHTML 網頁回傳給你，讓你以為是原本的網頁。或者他也可以抓出他感興趣的資訊(如信用卡卡號)，並使用 POST 的方式傳到他自己建立的機器上。

Update: 2006-07-21

我之前的論述有一些錯誤。我勾出 Server 與 Client 之間的傳輸關係。如下：

嚴重的錯誤1：只要是使用非 HTTPS 的 login form，都有問題。從架構圖中得知，無論是Server 送 Login form 到Client，或Client submit form 回 Server，都有可能遇到 man-in-the-middle。客戶不會知道Server傳過來的 Login form 是不是真的，Server也不會知道客戶傳回來的 form data 是不是真的。

並且對客戶而言，即使表面上看來是 HTTP，而底層設計是經由 HTTPS，客戶還是較難得知此網頁是否經由 HTTPS。即使在設計上有說明此網頁背後的傳輸是使用 HTTPS，甚至在提交按鈕旁放了一個 lock icon(鎖的圖，表示安全傳輸之意)，但也有可能 Login from 傳到客戶端時就被bad guy改掉 submit 的頁面，指到他所能控制的伺服器上，或是直接嵌入 keystoke collector，反而這種作法降低了客戶的安全意識。變成下圖：

嚴重的錯誤2： 在 HTTPS 網頁中混雜 HTTP。這種作法會讓客戶混淆，不知道什麼資料才是安全、什麼資料才是危險。更糟的是，Accacker可以從中將 HTTPS 的部份用 DHTML 重寫，寫成他所想要的方式。或者他可以掃描傳送頁面的資料，抓出他想要的，如信用卡卡號，並且 POST 到他自己設計的伺服器或頁面。

綜合：很多網頁程式設計師為了效能，往往會把 HTTPS 改成 HTTP傳輸，有些較有安全意識的，會將 Login form 傳輸使用 HTTP，而 Submit 才是用HTTPS。但是後面這種方法還是有問題，也就是上述所提的，Login form 有可能是假的。