普通 http 网络下数据的安全传输（设计原理）

曾几何时，https 安全但缺乏效率，http 有效率但却缺乏安全， 鱼与熊掌——两者不可兼得！

https 采用不对称加密算法创建安全的连接，之后用对称加密算法传递数据，安全性毋庸置疑——但因效率较低和授权费用（第三方 CA 机构认证）而难以普及。
http 设计的初始是基于相互信任，数据在网络上的传输是采用明文，不做任何加密处理，因此也就得到了效率——但数据的安全性或隐秘性就无从谈起了。只要别人愿意，网络监听就是一目了然的事。

为何不能将两者结合起来呢？——既有 http 的高效，又有类似 https 的足够的安全性！

在数据安全方面的理论中，要保证数据加密的可靠性，“密钥的传递”必须是安全的！一般情况下，密钥的传递途径最好与密文（加密后的数据）的传递途径不同。

一个显而易见的难题是——http 是明文传输！

所以，通过 http 协议连接的服务器端和客户端，首先就无法实现密钥的安全传递！ 或许因此，http 下数据的加密传输就失去了意义，也缺乏研究（大多寄希望于 IPv6 了——但那也还有些遥远，远水不解近渴）。

但当真如此吗？ http 下真的没法做加密通讯么？ 或许，我们可以慢慢探讨一下……

一、密钥的安全传递

这是首先要解决的问题。但如何在明文传输的 http 下进行呢？ 毫无疑问，这是不可行的，《老子》曰：曲成万物而不遗——曲则全。呵呵，我们可借助 https 的安全性来实现密钥的安全传递，然后在 http 下进行业务数据的加密传输。

这样的想法，似乎一目了然，很直观，但如何实现？ 经济效益如何？ 在浏览器跨域安全规则的限制下，这样的想法实现起来却并不直观。初看起来，经济效益也并不怎样——既然有了 https 服务，干嘛不就用 https 来做业务数据的传输呢？

其实并不然，首先可以看下经济效益的问题：

有一台 https 服务器
A.  直接用来做业务，业务占用大量的 https 资源……这台 https 也就只能做少量的用途了。
B.  只做 “认证” 服务，即只做密钥的传递工作……它可以给很多普通 http 服务器提供服务——这很适合一站通式的站群登录服务。

并且：
A 方式中，大量的业务可能会压垮 https 服务器，使得需要投入新的 https 相关费用。
B 方式中，因为只提供认证服务，服务单一，既便于维护，也可以承载更大量的认证请求。同时，认证与业务的分离，使得业务的扩展变得简单——不论是相同业务的硬件扩展，还是不同业务的软件扩展。

所以说，在经济上，这十分划算！

下面看看，密钥如何从安全的 https 连接中安全地传递到普通的 http 连接下（这里说的传递可是指任意域间的跨域传递哦！）。
说明：因为没有现成的 https 服务，没有做过 https 页面中向 http iframe 设置 window.name 的测试。但原理上，设置 iframe 的 window.name 与 iframe 的 src 属性中 url 的协议类型无关，故这应该是可行的，有条件的朋友不妨一试。

用图示说明较好，传递方式如下：



1. 安全认证（图中 1-3）：
    通过 https 安全连接登录， 服务器端存储密钥，同时返回密钥和登录ID；
    客户端转递密钥到目标域本地存储，同时向目标域中的 http 服务器发送登录ID。

2. 安全业务（图中 4-5）：
    目标域中的 http 服务器通过“登录ID”从 https 服务器提取密钥并存储（Session 中）；
    与客户端进行数据的加密传输，实现数据安全的业务通讯。

二、数据的加密传输

在实现了密钥的安全传递之后，数据的安全就可以通过加密来保证了。

但就我所知，在现阶段的各个浏览器中，尚未实现 http 下数据加密的调用接口（指 JS 环境），故我们只能自己来创造 JS 下的加密方法了。如本博客前几篇博文所述（请参看：《几个文字加密的 JS 简洁算法和一些个人的想法》、《几个文字加密的 JS 简洁算法（续）-- 字符错位法》和《几个文字加密的 JS 简洁算法（续2）--进制乱序法》）， JS 环境下也是可以有简单且高效的加密方式的——或许我们只需要对“文字”进行处理，加密后的密文依然是正常的可视文字，从而并不影响 http 下明文传输的设计思想。

文字的加密方式应该会有很多，前几篇博文也仅是提供了一些思考的素材。http 下的通讯因没有考虑安全性，故网络劫持依然会存在——不论对客户端还是服务器，但那是另一个话题了（当然也可以通过一些手段来增强其安全性）。

JS 下数据的加密算法有待专业人士的努力和创造，俺就不多干巴了……但就前述的几种加密算法，本人倾向于“进制乱序法”，因为密文十分规范，网络传输十分可靠（ASCII 字符集是任何系统都可良好处理的）。——注：该算法或许应该改进一下，实现自动识别单双字节以节约编码长度。

参考：
wnRequest 的实现，请参考《近乎完美的简单 JS 跨域解决方式 --window.name》；
在一年多以前，曾经写了一篇博文《普通 http 下可靠的网路认证方式》，如果您时间充裕，不妨小看一下，呵呵。
欢迎提出宝贵意见！

不错的文章，分享既方便他人，也方便自己。

可以看出LZ对CAS单点登入也是蛮有研究的哦。

对称加密算法的效率通常都非常高的吧，以前在学校的时候，课程设计就是实现AES算法。
当时一个同学的程序就有10M每秒（或者是20M？记不清了）的处理速度，要知道当时还是单核，1G的时代。

嗯。。。我想应该比gzip还要快些吧，没试过……