51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4600|回复: 2
打印 上一主题 下一主题

SSL技术详细说明

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-8-11 17:29:56 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
Secure socket layer(SSL)协议最初由Netscape企业发展,现已成为网络用来鉴别网站 和网页浏览者身份,以及在浏览器使用者及网页服务器之间进行加密通讯的全球化标准 。由于SSL技术已建立到所有主要的浏览器和WEB服务器程序中,因此,仅需安装数字证书,或服务器证书就可以激活服务器功能了 。对于Web信息传输通道的机密性及完整性,SSL是最佳的解决方案,目前所有的浏览器和Web服务器都支持SSL,采用SSL 在技术上已经很成熟,互联网的安全敏感数据几乎都是由SSL通道传输的。

采用SSL技术和数字签名技术保证邮件的安全性,为了满足企业用户保护商业秘密的需求 ,提供了完善邮件加密和认证功能,采用SSL技术对邮件的存储和传输实施加密,保证邮件不被窃取和篡改;并且提供数字签名技术, 以保证邮件的真实性。系统提供了从普通级到绝密级等多种保密等级,以满足不同环境下的保密需求。SSL协议是因特网通信标准,用 来提供两个应用之间通信的保密,可信和身份认证。SSL技术一般采用公开密钥技术,能够提供:信息加密服务,信息完整性服务,相 互认证服务这三项服务。

下面,我们将从通信量分析、主动攻击、重放攻击、密码组回滚攻击以及中间人攻击这五种常见的安全攻击入手,初步分析SSL的抵御 攻击能力。
通信量分析
如果常规的攻击失败,密码破译专家会转向使用更复杂的攻击。通信量分析是另外一种被动攻击,但它经常是恶意攻击,因此值得一提。 通信量分析的目标在于,通过检查包中未加密的域及属性,以获得受保护会话的机密信息。例如,通过检查未加密的源和目标的IP地址 (甚至TCP端口号),或者检查网络通信流,一个通信量分析专家可以确定通信各方的通信内容,使用的服务类型,有时甚至还可以获 得有关商业或个儿关系的信息。实际上,用户大都认为通信量分析的威胁相对来说是无害的,因此SSL不会试图阻止这种攻击。忽略通 信量分析看来是一种可行的设计方案。

然而在SSL体系结构中,通信量分析仍会造成一些巧妙的威胁。Bennet Yee已经指出,检查密文的长度会暴露出有关SSL或被SSL加密的网站通信中用到的URL请求的信息【Yee96】。当一个W eb浏览器通过加密传输(如SSL)连接到一台Web服务器时,包含有URL信息的GET请求会以加密方式进行传输。严格来说, 浏览器要下载哪一个页面,这种信息是保密的——显然,具有URL方面的知识,对于一个想下载整个网站的人来说,这已经足够了—— 而且,通信量分析可以获得Web服务器的身份信息,请求的URL长度,以及从Web服务器所返回的html数据的长度。这个漏洞 往往使得窃听者能够发现用户访问了哪些Web页面。

上述弱点之所以出现,是因为密文长度暴露了明文的长度。SSL在块加密模式中支持随机填充,而在流加密模式中却不支持。我们相信 ,对于所有的加密模式,SSL将会在最小程度上支持任意长度填充的使用,而且会仔细地考虑它在特定应用程序中的需求。

主动攻击
SSL能抵御主动攻击以安全地保护机密数据,这一点非常重要。当然,所使用的加密算法应该在被选择明文∕被选择密文攻击下是安全 的,但这对于加密算法来说还不够。IETF的IPSEC工作组的最近研究表明,即使所使用的密码强度足够,在记录层上精明的主动 攻击仍能打破系统的保密性。SSL 3.0 的记录层能抵御这些强有力的攻击:更进一步,为何这些攻击会被阻止,值得我们讨论。

IPSEC中的一个重要的主动攻击是Bellovin的剪贴攻击。回想起来,要获得保密性,光对链接进行加密是不够的——接收端 也必须防止敏感数据在无意中被泄露出来。剪贴攻击的攻击方式就是谋求接收端的信任,使之对敏感数据进行解密并将这些数据泄露给它 们。
SSL 3.0能够阻止剪贴攻击。阻止这种攻击的一种局部性防御策略是为每一个不同的上下文使用独立的会话密钥,这样便能在不同的连接之 间,以及连接的不同方向之间阻止剪贴操作。SSL已经为每个连接方向使用了独立的密钥。但是,这种机制无法阻止传输中一个方向上 的剪贴操作。应用最广泛的防御策略是在所有加密包上使用强大的认证机制,以阻止敌方对密文数据的修改。SSL记录层确实采用了这 种防御策略,因此剪贴操作被完全阻止住了。
另一种主动攻击是短块攻击,它主要针对IPSEC。这种攻击适用于最后的报文块包含一个一字节长的明文并且报文块剩余部分由随机 数填充的情况。在SSL上并没有明显的短块攻击。SSL记录层格式与以前的IPSEC格式相当类似,这种格式容易遭到攻击,因此 可以想象,修改性攻击会对SSL产生威胁。但是,无论如何,由标准SSL加密的Web服务器基本上不会受到短块攻击的威胁,因为 这些服务器不会经常对短块进行加密。(但要注意,由SSL加密的telnet客户端必须得到特殊的保护,以防止短块攻击,因为每 一次按键在传送时都是一字节长的数据包。)

重放攻击
光靠使用报文鉴别码(MAC)不能防止对方重复发送过时的信息包。SSL通过在生成MAC的数据中加入隐藏的序列号,来防止重放 攻击。这种机制也可以防止被耽搁的,被重新排序的,或者是被删除数据的干扰。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2007-8-12 08:05:03 | 只看该作者
TKS
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2016-8-25 11:11
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    3#
    发表于 2013-3-8 14:45:45 | 只看该作者
    五点攻击方式讲了三,少了二点
    ----------------------
    密码组回滚攻击(CipherSuite Rollback attack)
    SSL 2.0密钥交换协议中有一个严重的缺陷:主动攻击者能够在暗地里迫使一个家庭用户使用功能被削弱的出口加密算法,即使通信双方都支持并首选了较高等级的算法。这就是人们所说的密码组回滚攻击(CipherSuite Rollback attack),它通过编辑在hello报文中发送的所支持密码组的明文列表来达到自身的目的。SSL 3.0 修正了这个缺陷,它使用一个master_secret来对所有的握手协议报文进行鉴别,这样一来,便可在握手结束时检查出敌方的上述行为,如果有必要,还可结束会话。

    接着,我们来详细描述一下SSL 3.0中防止修改握手协议报文的机制。在以前SSL握手协议中,有几个常见的弱点,我们将依次进行介绍。
    所有初始的握手协议报文在传送时都是未保护的,此时密钥交换协议会将当前会话状态改为未决的会话状态,而不是修改当前使用中的各个参数。在协商完成之后,通信的每一方都发送一个短的更改密码规格报文(change cipher spec message),该报文仅仅是警告对方将当前状态升级为未决的会话状态。虽然change_cipher_spec报文未受保护,但是新的会话状态还是将以下一个报文为开始。紧跟在change_cipher_spec报文之后的是结束(finished)报文,它包含了一个报文鉴别码(MAC),此MAC由被master_secret加密过的所有握手协议报文计算得出。(基于特殊的非安全性因素,change_cipher_spec报文和alert报文在finished报文中没有进行鉴别。)48字节长的master_secret从未被泄露出去,而且会话密钥由它产生。这就保证了即使会话密钥被人截获,master_secret仍可安然无恙,所以握手协议报文能够安全的得到鉴别。Finished报文使用新建的密码组(ciphersuite)对自身进行保护。通信各方只有在收到对方的finished报文并对其进行核实后,才会接收应用层的数据。

    中间人攻击(man_in_the_middle attack)
    SSL 3.0中包含了对Diffie-Hellman密钥交换进行短暂加密的支持。Diffie-Hellman是一种公开密钥算法,它能有效地提供完善的保密功能,对于SSL来说是一个有益的补充。在SSL 3.0 Diffie-Hellman密钥交换系统中,服务器必须指定模数和原始根(这两个数均为素数),以及Diffie-Hellman的指数。为了防止服务器端产生的陷门,客户端应该对模数和原始根进行仔细的检查,看它们是否为固定公共列表上的可靠数值。在SSL 3.0中,通过对服务器端的Diffie-Hellman指数的鉴别,可以抵御众所周知的中间人(man-in-the-middle)攻击。(匿名客户不必拥有证书。)另外,在SSL 3.0中并不支持具有较高性能的Diffie-Hellman变量,如较小的指数变量(160bit)或椭圆曲线变量。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-22 21:56 , Processed in 0.072274 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表