三种保证URL地址可信的加密方式近日接到一个需求，要求一台资源服务器不仅在可以暴露在公网环境下的同时，还
三种保证URL地址可信的加密方式
近日接到一个需求，要求一台资源服务器不仅在可以暴露在公网环境下的同时，还要保证只接受并处理可信的http访问请求。
?
需求场景如图：
为了访问资源文件，用户需要首先访问某一台Frontend Server进行用户身份认证———所有的用户信息均由Frontend Server保存，Frontend Server认证通过后返回真实的重定向地址，用户再根据重定向地址访问Resource Server获取资源文件。
具体的使用场景正如上面所述，下面是我的思考过程...
?
为了保证资源服务器收到的是一个可信的重定向地址，在安全性上有三点考虑：
?
重定向地址必须是可信的，即不可以被伪造，必须是由某一台Frontend Server返回的重定向地址。为了防止盗链或资源被采集，每个Frontend Server返回的重定向地址应具有时效性。这个可以通过在链接地址上增加时间戳实现，但前提是该时间戳不可以被伪造。最后，在必要的情况下，还可以不去响应某一台Frontend Server返回的重定向地址，即认为某一台Frontend Server的重定向地址不可信、该Frontend Server不可信。这要求Resource Server能够及时标示一台Frontend Server为不可信服务器，并且该Frontend? Sever服务器还不可伪造剩余可信服务器返回的重定向地址。
?
以上三点也可以总结为：防止公网用户伪造URL地址，防止不可信Frontend Server伪造地址，防止过期URL地址访问。
由于Resource Server需要允许所有的公网用户访问，所以不能对Ip进行限制，并且一般情况下Resouce Server也不会与Frontend Server直接通信，因此只能通过URL的验证方式。Frontend Server在生成每个URL的过程中中应包括Resource Server为每一个Frontend Server分配的账户fsId、密钥fsKey以及记录当前URL生成时间的时间戳fstime。fsid必须明文传输，fsKey做为加密运算的一个常量不可以明文传输。
可以想到的有如下三种：
1.使用自定的加密函数生成加密签名字符串。
加密函数将所有需要明文传输的参数以及当前Frontend Server使用的密钥fsKey做为参数并通过MD5转换后生成加密签名字符串，md5(encode(params,fsid, fskey, fstime))。
重定向地址链接：
http://res.com/fsid=***&fstime=***¶ms=***&signmsg=md5(encode(params,fsid,fskey, fstime))
Resource Server收到该请求后
根据fstime判断该请求是否过期，过期请求直接返回。根据fsid判断该Frontend Server是否可信，如可信再根据fsid获得服务器端保存的fskey。使用相同的参数加密签名过程，Resource Server根据params,fsid, fskey, fstime生成签名字符串。比较重定向地址传来的签名字符串signmsg与本地生成的签名字符串是否相同，相同则认为是可信请求，否则为非法请求。
2.使用对称加密算法保证HTTP通信可信。
Resource Server为每一台Frontend Server分配不同的Des密钥（fskey），Frontend Server使用对称加密算法对拼接后的传递参数进行加密des(params|fstime)
重定向地址链接：
http://res.com/fsid=***&desmsg= des(params|fstime)
Resource Server收到该请求后
首先根据fsid判断该Frontend Server是否可信，如可信再根据fsid获得每个Frontend Server使用的Des密钥fskey。使用密钥对desmsg信息解密，解密失败直接返回。根据解密后的fstime判断是否过期，过期直接返回。
3.同时使用非对称，对称加密算法保证HTTP通信可信。
Frontend Server随机生成key做为对称加密算法的公钥des(params|fskey|fstime)，并使用Resource Server提供的公钥对key进行非对称加密rsa(key)
重定向地址链接：
http://res.com/fsid=***&rsamsg=rsa(key)&desmsg= des(params|fskey|fstime)
Resource Server收到该请求后
首先根据fsid判断该Frontend Server是否可信，如可信再根据服务器端保存的非对称加密私钥解密rsa(key)。根据key解密des(params|fskey|fstime)。通过fsid获得服务器端保存的fskey，对比解密后的fskey，如果不相同则认为是Frontend Server伪造的非法请求。根据fstime判断是否过期，过期直接返回。
以上三种方法第一种会暴露所有的明文传递参数，第二种貌似最方便但却有被攻破的危险，第三种有可能又会产生效率的问题。
由于没有进行过相关方面的开发，以上也是对平时了解有限的一些资料的总结，难免考虑不周。各位有更好的方法和建议吗？
?
?
<p>?</p> 7 楼 bengxia 2009-11-23 感觉跟CAS在原理上很相似。但有一个安全假设存在隐患，就是client在frontend server认证后返回重定向地址的过程是安全可靠的，这点要看实际情况。 8 楼 jef 2009-11-23 谢谢大家的回帖，看来要保证网络通信的绝对安全也不是件易事。
参照grandboy的说法，应该选择一种适合的方案解决一定密级要求下的网络安全。所以解决方案也可以分为两种，一种是适合于金融交易系统，要求在任何情况下都能保证网络通信绝对安全的场景，但在这种情况下可能需要较高的成本投入。
另一种情况是适合于普通互联网应用环境，可以低成本投入，高效率运行，并能保证一定密级要求的次优解决方案。具体说就是：
1，理论上不保证每个时间点的绝对通信安全。
2，可以被破解,但破解行为必须付出一定程度的时间成本。破解的时间成本也可以参考一些资料估算得出。
3，在破解行为必须付出的时间成本内Frontend Server和Resource Server可通过定时任务交换最新的fskey。这个可以通过对Frontend Server和Resource Server之间的特定调用接口进行IP和口令限制保证通信安全。
也就是说破解行为所需要的时间周期远高于Frontend Server和Resource Server的fskey更新周期，这些条件达成时，感觉应该也算是在次优方案下保证了网络通信的绝对安全。 9 楼 jef 2009-11-23 ebeach：
是有点像单点场景，不过前置服务器和后端服务器肯定不能频繁的交互，否则应用在互联网环境下对效率的开销太大。
bengxia 写道感觉跟CAS在原理上很相似。但有一个安全假设存在隐患，就是client在frontend server认证后返回重定向地址的过程是安全可靠的，这点要看实际情况。
对用户来说，需要收到一个安全的重定向地址。对Resource Server来说需要处理一个可信的访问请求。 10 楼 hcqenjoy 2009-11-23 引用3.同时使用非对称，对称加密算法保证HTTP通信可信。
Frontend Server随机生成key做为对称加密算法的公钥des(params|fskey|fstime)，并使用Resource Server提供的公钥对key进行非对称加密rsa(key)
重定向地址链接：
http://res.com/fsid=***&rsamsg=rsa(key)&desmsg= des(params|fskey|fstime)
Resource Server收到该请求后
首先根据fsid判断该Frontend Server是否可信，如可信再根据服务器端保存的非对称加密私钥解密rsa(key)。
根据key解密des(params|fskey|fstime)。
通过fsid获得服务器端保存的fskey，对比解密后的fskey，如果不相同则认为是Frontend Server伪造的非法请求。
根据fstime判断是否过期，过期直接返回。
这个采用数字签名就可以 即(params|fskey|fstime)做摘要如SHA-1 然后用Frontend Server的私钥对摘要做加密 将(params|fskey|fstime) 和加密值发送给接收端
接收端 用Frontend Server的公钥解密出摘要值 与 (params|fskey|fstime)的摘要值对比 符合即通过
定期更换两台服务器的公私钥 可以防止密钥的泄漏
数字签名是很成熟的安全方案
11 楼 jef 2009-11-23 <p>恩，是这个意思吧，重定向地址前半部分是明文传递的参数，后半部分是使用非对称加密算法加密的参数摘要。<br><br><em><span style="text-decoration: underline;"><span style="color: #0000ff;">http://res.com/fsid=***&fstime=***&params=***&fskey=***&signmsg=RSA(SHA-1(fsid,fskey,fstime,params))</span></span></em><br><br>这个办法很不错，安全性更高了，多谢！</p>
<p>?</p> 12 楼 daquan198163 2009-11-23 有个叫HDIV的框架，应该能满足你的要求。 13 楼 cszhz 2009-11-24 可是试试SSO（app sever都支持的），你这种case 根本不需要有额外的coding 14 楼 jef 2009-11-24 cszhz 写道可是试试SSO（app sever都支持的），你这种case 根本不需要有额外的coding
sso不太适合大量部署吧，而且又会引起很多效率上的开销。 15 楼 iamlotus 2009-11-24 这就是CA要解决的问题啦，加密解决了防篡改的问题，CA的引入则解决了防伪造的问题。所以建一个CA是技术上最完美的方案，不过代价也最昂贵。
