由於個人資料數量龐大，透過一系列可透過網際網路傳輸的資料，加密並不是我們應該或應該輕忽的。新式瀏覽器提供多種機制，可用於確保使用者資料在傳輸過程中安全無虞：安全的 Cookie 和嚴格傳輸安全性是其中兩大要素。可讓您順暢地保護使用者、將連線升級為 HTTPS，並保證使用者資料絕不會直接傳送。
這麼做有什麼好處？請考慮以下幾點：
比起將未密封的信封寄給在街道上，第一人看起來是走在郵局的方向上，但透過未加密的 HTTP 連線提供網頁的做法，則有所不同。如果你很幸運，她可能會一路走完，或者也可以把它交給下一位看到誰正想正確的人。那個人可能也會做同樣的事，依此類推
這種即興鏈的大多數陌生人都值得信賴，永遠不會察覺或更改公開信件。不過，字母改變手部的次數越多，代表你所寄出信件的完整存取權的人數越多。說到底，您信件的收件者很可能在郵件中看到「東西」，但它與您一開始提交的問題是否「相同」是開放的問題。或許你該把這封信封上...
中間人
要更好或更糟的是，網路上可觀的大量內容取決於陌生人的可信度。伺服器不會直接彼此連線，而是在這款巨大的電話遊戲中，將要求和回應從路由器傳送至路由器。
您可以透過 traceroute 查看這些躍點的實際運作情形。從電腦到 HTML5Rocks 的路線看起來會像這樣：
$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
1 router1-lon.linode.com (212.111.33.229) 0.453 ms
2 212.111.33.233 (212.111.33.233) 1.067 ms
3 217.20.44.194 (217.20.44.194) 0.704 ms
4 google1.lonap.net (193.203.5.136) 0.804 ms
5 209.85.255.76 (209.85.255.76) 0.925 ms
6 209.85.253.94 (209.85.253.94) 1.226 ms
7 209.85.240.28 (209.85.240.28) 48.714 ms
8 216.239.47.12 (216.239.47.12) 22.575 ms
9 209.85.241.193 (209.85.241.193) 36.033 ms
10 72.14.233.180 (72.14.233.180) 43.222 ms
11 72.14.233.170 (72.14.233.170) 43.242 ms
12 *
13 lb-in-f102.1e100.net (173.194.71.102) 44.523 ms
13 個躍點也不是壞事。但是，如果我透過 HTTP 傳送要求，則每個中繼路由器都可存取我的要求和伺服器回應的完整存取權。所有資料都會以未加密的明文形式傳輸，任何這些中介者都可以充當「中間的男性」、讀取我的資料，甚至操控傳輸中的資料。
更糟的是，這種攔截事件幾乎無法被偵測到。惡意修改的 HTTP 回應看起來就像有效回應，因為沒有任何機制可讓您確保接收到的資料「確切」就是傳送的資料。如果有人決定想讓網際網路上下顛倒，我就更難辦到。
這是安全專線嗎？
從純文字 HTTP 改用安全的 HTTPS 連線，可以提供抵禦中間人的最佳防禦。HTTPS 連線會在任何資料傳送前對整個管道進行端對端加密，因此您與目的地之間的機器就無法讀取或修改傳輸中的資料。
安全性 HTTPS 以公開和私人加密編譯金鑰的概念為基礎。進一步探討細節 (幸好) 並不在本文的討論範圍，但核心概念非常簡單：以特定公開金鑰加密的資料「只能」使用對應的私密金鑰解密。當瀏覽器啟動 HTTPS 握手以建立安全通道時，伺服器會提供憑證來為瀏覽器提供所有必要資訊，以驗證伺服器是否擁有適當的私密金鑰。從該點以後的所有通訊都會經過加密，以證明要求確實傳送至經過驗證的伺服器，以及從驗證伺服器接收的回應。
因此，您可以確保自己與所通訊的伺服器進行通訊，而且沒有其他人正在聽取您的連線或傳輸的位元。這類加密程序是確保網路安全性的絕對先決條件；如果您的應用程式目前並未透過 HTTPS 傳送，就容易遭受攻擊。修正問題。Ars Technica 提供完善的免費取得及安裝憑證指南，建議您參考相關技術詳細資料。設定會從供應商、供應商和伺服器到伺服器，但任何位置的憑證要求程序都相同。
預設將安全性納入考量
要求並安裝憑證後，請確保使用者從您付出的心力中獲益：利用 HTTP 重新導向的魔法，將現有使用者遷移至 HTTPS 連線，並確保 Cookie「僅」透過安全連線傳送。
以便
當使用者造訪 http://example.com/ 時，請傳送含有適當 Location 標頭的 301 Moved
Permanently 回應，將他們重新導向至 https://example.com/：
$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/
您可以在 Apache 或 Nginx 等伺服器中輕鬆設定這類重新導向。例如，從 http://example.com/ 重新導向至 https://example.com/ 的 Nginx 設定如下所示：
server {
listen [YOUR IP ADDRESS HERE]:80;
server_name example.com www.example.com;
location "/" {
rewrite ^(.*) https://www.example.com$1 permanent;
}
}
鎖定 cookie jar
Cookie 可讓我們透過無狀態 HTTP 通訊協定，為使用者提供順暢的登入體驗。Cookie 中儲存的資料 (包括工作階段 ID 等機密資訊) 會隨著每個要求一併傳送，讓伺服器瞭解自己在回應的是哪位使用者。確定使用者會透過 HTTPS 造訪我們的網站後，我們也應確保儲存在 Cookie 中的機密資料只會透過安全連線轉移，而且絕對不會以明確的方式傳送。
設定 Cookie 通常涉及的 HTTP 標頭，如下：
set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT
您可以處理單一關鍵字，指示瀏覽器限制 Cookie 使用 Cookie 的安全工作階段：
Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure
凡是透過 secure 關鍵字設定的 Cookie，都不會透過 HTTP 傳送。
正在關閉開啟的視窗
如果以透明化的方式重新導向至 HTTPS，則代表使用者在大部分的情況下造訪您的網站，都會使用安全連線。不過，這麼做會留下一小部分的攻擊機會：初始 HTTP 連線會處於公開狀態，容易遭到 SSL 去除和相關攻擊攻擊。由於中間的人可以完全存取初始 HTTP 要求，因此它可做為您和伺服器之間的 Proxy，因此無論伺服器的意圖為何，都可讓您保持使用不安全的 HTTP 連線。
您可以要求瀏覽器強制執行 HTTP 嚴格傳輸安全性 (HSTS)，藉此降低這類攻擊的風險。傳送 Strict-Transport-Security HTTP 標頭會指示瀏覽器在不接觸網路的情況下，執行 HTTP 到 HTTPS 重新導向的用戶端 (這也會帶來良好效能，因此最好不要發出要求)：
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
支援此標頭的瀏覽器 (目前為 Firefox、Chrome 和 Opera： caniuse： caniuse) 詳細資料會註明此網站要求僅限 HTTPS 的存取權，也就是說，無論使用者以何種方式前往網站，她都會透過 HTTPS 造訪網站。即使她在瀏覽器中輸入 http://example.com/，卻直接使用 HTTPS，完全不需要建立 HTTP 連線。更棒的是，如果瀏覽器偵測到無效的憑證 (也許會試圖假冒您的伺服器身分)，使用者就無法透過 HTTP 繼續；全部或全部內容都沒問題。
瀏覽器會在 max-age 秒後過期伺服器的 HSTS 狀態 (本例約為一個月)；請將其設為合理的高一些值。
您也可以在標頭中加入 includeSubDomains 指令，確保來源的所有子網域都能受到保護：
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
放心使用，不費吹灰之力
要順利使用 HTTPS，甚至可以確定您傳送的資料能完整傳送給指定收件者，建議您現在就為網站和應用程式設定安全連線這項程序相當簡單，且能協助保障客戶資料安全。加密管道建立完成後，您應傳送 301 HTTP 回應，公開將使用者重新導向至這個安全連線。接著，請在設定 Cookie 時新增安全關鍵字，確保所有使用者的機密工作階段資訊「只」使用安全連線。完成所有確認操作後，請確保使用者不會意外落入公車：請附加 Strict-Transport-Security 標頭，確保瀏覽器正常運作，以確保使用者能正常運作。
設定 HTTPS 並不容易，而且能為網站和使用者帶來巨大優勢。這絕對值得。
資源
- StartSSL 提供免費網域驗證憑證。你是無比追求的。無論採用哪種方法，您一定可以採用合理價格，然後再提高驗證等級。
- 安全資料傳輸層 (SSL) 伺服器測試：當您為伺服器設定 HTTPS 後，請透過 SSL 研究室的伺服器測試執行，確認您已正確執行。您可獲得詳盡的報表，顯示是否已開始運作。
- Ars Technica 近期發表的「使用 SSL/TLS 保護網路伺服器」一文，有助您進一步瞭解設定伺服器的基本概念。
- 針對您可能想要的
Strict-Transport-Security標頭，建議您仔細閱讀 HTTP 嚴格傳輸安全性規格 (RFC6797) 的相關技術資訊。 - 清楚瞭解執行目標後，下一步就是宣傳您的網站，讓網站只能透過一組特定憑證連上。IETF 還有一項工作，可以讓您透過
Public-Key-Pins標頭完成這項工作，目前仍在早期開發階段，但值得一試，也值得一試。