[size=small]曾幾何時，https 安全但缺乏效率，http 有效率但卻缺乏安全， 魚與熊掌——兩者不可兼得！
https 採用不對稱加密演算法建立安全的連線，之後用對稱加密演算法傳遞資料，安全性毋庸置疑——但因效率較低和授權費用（第三方 ca 機構認證）而難以普及。
http 設計的初始是基於相互信任，資料在網路上的傳輸是採用明文，不做任何加密處理，因此也就得到了效率——但資料的安全性或隱秘性就無從談起了。只要別人願意，網路監聽就是一目了然的事。
為何不能將兩者結合起來呢？——既有 http 的高效，又有類似 https 的足夠的安全性！
在資料安全方面的理論中，要保證資料加密的可靠性，「金鑰的傳遞」必須是安全的！一般情況下，金鑰的傳遞途徑最好與密文（加密後的資料）的傳遞途徑不同。
乙個顯而易見的難題是——[color=blue]http 是明文傳輸[/color]！
所以，通過 http 協議連線的伺服器端和客戶端，首先就無法實現金鑰的安全傳遞！ 或許因此，http 下資料的加密傳輸就失去了意義，也缺乏研究（大多寄希望於 ipv6 了——但那也還有些遙遠，遠水不解近渴）。
但當真如此嗎？ http 下真的沒法做加密通訊麼？ 或許，我們可以慢慢**一下……
[b]一、金鑰的安全傳遞[/b]
這是首先要解決的問題。但如何在明文傳輸的 http 下進行呢？ 毫無疑問，這是不可行的，《老子》曰：曲成萬物而不遺——曲則全。呵呵，我們可借助 https 的安全性來實現金鑰的安全傳遞，然後在 http 下進行業務資料的加密傳輸。
這樣的想法，似乎一目了然，很直觀，但如何實現？ 經濟效益如何？ 在瀏覽器跨域安全規則的限制下，這樣的想法實現起來卻並不直觀。初看起來，經濟效益也並不怎樣——既然有了 https 服務，幹嘛不就用 https 來做業務資料的傳輸呢？
其實並不然，首先可以看下經濟效益的問題：
有一台 https 伺服器
[b]a.[/b] [color=blue]直接用來做業務[/color]，業務占用大量的 https 資源……這台 https 也就只能做少量的用途了。
[b]b.[/b] [color=blue]只做 「認證」 服務[/color]，即只做金鑰的傳遞工作……它可以給很多普通 http 伺服器提供服務——這很適合一站通式的站群登入服務。
並且：[b]a 方式中[/b]，大量的業務可能會壓垮 https 伺服器，使得需要投入新的 https 相關費用。
[b]b 方式中[/b]，因為只提供認證服務，服務單一，既便於維護，也可以承載更大量的認證請求。同時，認證與業務的分離，使得業務的擴充套件變得簡單——不論是相同業務的硬體擴充套件，還是不同業務的軟體擴充套件。
所以說，在經濟上，這十分划算！
下面看看，金鑰如何從安全的 https 連線中安全地傳遞到普通的 http 連線下（這裡說的傳遞可是指任意域間的跨域傳遞哦！）。
[color=gray]說明：因為沒有現成的 https 服務，沒有做過 https 頁面中向 http iframe 設定 window.name 的測試。但原理上，設定 iframe 的 window.name 與 iframe 的 src 屬性中 url 的協議型別無關，故這應該是可行的，有條件的朋友不妨一試。[/color]
用圖示說明較好，傳遞方式如下：[/size]
[img]
[size=small]
[b]1. 安全認證[/b]（圖中 1-3）：
通過 https 安全連線登入， 伺服器端儲存金鑰，同時返回金鑰和登入id；
客戶端轉遞金鑰到目標域本地儲存，同時向目標域中的 http 伺服器傳送登入id。
[b]2. 安全業務[/b]（圖中 4-5）：
目標域中的 http 伺服器通過「登入id」從 https 伺服器提取金鑰並儲存（session 中）；
與客戶端進行資料的加密傳輸，實現資料安全的業務通訊。
[b]二、資料的加密傳輸[/b]
在實現了金鑰的安全傳遞之後，資料的安全就可以通過加密來保證了。
但就我所知，在現階段的各個瀏覽器中，尚未實現 http 下資料加密的呼叫介面（指 js 環境），故我們只能自己來創造 js 下的加密方法了。如本部落格前幾篇博文所述（請參看：[url=幾個文字加密的 js 簡潔演算法和一些個人的想法》[/url]、[url=幾個文字加密的 js 簡潔演算法（續）-- 字元錯位法》[/url]和[url=幾個文字加密的 js 簡潔演算法（續2）--進製亂序法》[/url]）， js 環境下也是可以有簡單且高效的加密方式的——或許我們只需要對「文字」進行處理，加密後的密文依然是正常的可視文字，從而並不影響 http 下明文傳輸的設計思想。
文字的加密方式應該會有很多，前幾篇博文也僅是提供了一些思考的素材。http 下的通訊因沒有考慮安全性，故網路劫持依然會存在——不論對客戶端還是伺服器，但那是另乙個話題了（當然也可以通過一些手段來增強其安全性）。
js 下資料的加密演算法有待專業人士的努力和創造，俺就不多干巴了……但就前述的幾種加密演算法，本人傾向於「進製亂序法」，因為密文十分規範，網路傳輸十分可靠（ascii 字符集是任何系統都可良好處理的）。——注：該演算法或許應該改進一下，實現自動識別單雙位元組以節約編碼長度。
[b]參考：[/b]
wnrequest 的實現，請參考[url=近乎完美的簡單 js 跨域解決方式 --window.name》[/url]；
在一年多以前，曾經寫了一篇博文[url=普通 http 下可靠的網路認證方式》[/url]，如果您時間充裕，不妨小看一下，呵呵。
歡迎提出寶貴意見！
[/size]
HTTP下密碼的安全傳輸 OAuth認證
在複雜的web環境下，我們沒有百分的把握保證資訊在傳輸的過程中不被接貨，那不是用明文如何告訴伺服器自己的身份呢？在一些高度通訊安全的網路中，資料傳輸會使用https作為傳輸協議，但是通常情況下我們沒必要使用https傳輸，雖說安全，但傳輸資料都需要加密解密，很費事。我們可以使用一些加密方式 md5 ...
HTTPS 網路安全傳輸協議下的訪問
https http 超文字傳輸協議 ssl 安全連線層 http 的安全版本.https 會專門建立乙個 安全的資料傳輸通道來傳輸資料,外界拿不到任何資料,現階段最安全的協議，目前在 http 模式下三大運營商傳送的惡意廣告氾濫，並且可以獲得使用者的個人資訊，知乎有專門文章講解如何到工信部投訴的內...
安全加密 資料安全傳輸的原理
安全是相對的，沒有絕對的安全。資料的安全 機密性完整性 身份認證 握手階段 資料傳輸階段 原因 比非對稱加密加密快。加密 解密資料，需要兩樣東西 演算法 金鑰。通過非對稱加密演算法，加密後傳輸的。非對稱加密的金鑰分為 公鑰 私鑰。私鑰自己私有，公鑰公之於眾。實際傳遞對稱演算法金鑰流程更複雜 例如ss...