读书频道 > 网站 > 网页设计 > Web之困:现代Web应用安全指南
3.9 协议级别的加密和客户端证书
13-09-30    奋斗的小年轻
收藏    我要投稿   
本书开篇回顾了Web的发展历程和安全风险的演化;第一部分解剖了现代浏览器的工作原理,包括URL、HTTP协议、HTML语言、CSS、文档格式、浏览器插件等内容;第二部分从浏览器的设计角度深入分析了各种现代Web浏览器立即去当当网订购

写到这里已经很明显了,HTTP会话在网络上进行的所有信息交换,都是明文方式的。在上世纪90年代,这不算啥大问题:没错,明文信息会把你的浏览习惯暴露给聒噪的ISP服务商们,或办公室内网里某个搞恶作剧的家伙,甚至惹来某些过于热心的政府人士,但这些状况和SMTP、DNS以及其他常用协议的问题相比,似乎又不算那么严重。但随着Web日益成为最受欢迎的商务平台,风险愈加凸显,另外随着公用无线网络的出现,由于Web本质上就已经不太安全了,所以更会导致严重的网络安全性倒退,这简直是雪上加霜。

在尝试过几种不太成功的做法后,在RFC 281821里终于找到了可行之道:为何不用于几年前出现的多用途传输层加密(Transport Layer Security ,简称TLS,也叫SSL)机制来传输常规的HTTP请求呢。这种传输方式使用公钥加密算法建立一条保密的可信任的通信通道,而在HTTP级别服务器和客户端都无需再作任何调整。

 为了让网站服务器能证明自己的身份,每个支持HTTPS的浏览器都内置了一大堆各种各样的证书发行中心(Certificate Authorities,下文简称CA中心)的公钥信息。CA中心是浏览器开发商信任的授权机构,它为有需要的网站颁发用于验证的服务器公钥,颁发前该机构应尽量确认申请者的身份,并确保颁发的服务器证书确实是由该域名使用的。

每种浏览器里内置的受信任机构各自不同,随心所欲,也没有什么特别详细的文档规范,这点经常招致各种批评。但总体来说,这套系统还算运作良好。到目前为止只有区区几次出问题的报道(其中就有近期非常瞩目的Comodo22公司CA系统被利用的问题),目前还没有大范围的CA系统特权被滥用的报道。

至于CA中心的具体实现上,就是在创建一个新的HTTPS连接时,浏览器端收到服务器的签名公钥,验证签名后(除非CA的私钥泄漏,否则签名无法被伪造),检查证书里被签名的cn项(Common Name,常用名称)或subjectAltName项的值,由此确认对方确实是浏览器真正要访问的服务器,并确认该公钥不在CA机构的公开撤销列表里(例如,证书是假冒或欺诈手段获取到的)。如果所有检查都通过了,浏览器就可以用这个公钥加密信息并传回给服务器端,通过这种方式,确认只有特定的接收者才能对加密信息进行解密。

一般来说,客户端是匿名的。它产生一个临时的密钥,但这个处理并不能证实客户端的身份。当然要想证明客户端身份也是可以的。证书发行机构也都内建支持客户端证书,全球范围内已有若干国家在全国范围内承认电子证书(例如用于政府的电子政务)的使用。客户端证书最常规的用途就是证明真实世界里使用者的身份,所以在访问站点之初,出于隐私的考虑,浏览器往往需要提示一下用户,是否需要发送客户端证书;除此之外,客户端证书也可以作为全局授权认证方式的一种形式。

值得注意的是,尽管HTTPS对被动型和主动型攻击者都能防御,但HTTPS访问里一些已知的公开信息还是难以避免地暴露在外。譬如,我们还是能获得访问会话里HTTP请求和响应的大小、访问流量的进出方向、时间模式的规律,等等,对那些全盘照收数据的被动型攻击者来说,这些信息甚至能泄漏用户正在使用加密通道浏览维基百科上哪些不雅页面。实际上,在一个极端的例子里,微软的研究者甚至通过分析这种数据包的统计信息,重组还原出用户对某个线上应用访问时的键盘输入23。

点击复制链接 与好友分享!回本站首页
分享到: 更多
您对本文章有什么意见或着疑问吗?请到论坛讨论您的关注和建议是我们前行的参考和动力  
上一篇:1.3 功能
下一篇:1.5 小结
相关文章
图文推荐
JavaScript网页动画设
1.9 响应式
1.8 登陆页式
1.7 主题式
排行
热门
文章
下载
读书

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训
版权所有: 红黑联盟--致力于做最好的IT技术学习网站