面向网络应用层安全的分析与设计
- 格式:doc
- 大小:28.00 KB
- 文档页数:9
龙源期刊网 http://www.qikan.com.cn 面向网络应用层安全的分析与设计 作者:谷铮 来源:《电子技术与软件工程》2016年第22期
摘 要 网络已经普及,在给整个社会带来巨大变革的同时,网络安全形势日益复杂和严峻,通过对网络的攻击能够获取到有价值的信息或者伪造信息进而实施欺骗能够造成重大信息泄露和损失,并且通过网络攻击造成网络瘫痪,这使得我们不禁去思考怎样才能提高网络安全性,避免造成重大损失。
【关键词】网络应用层 安全 HTTPS攻击 随着越来越多的人开始使用网络,网络的安全可靠就变得尤为重要,随着网络基础协议的逐渐完善,网络攻击向应用层发展的趋势越来越明显,诸如应用层的DDOS攻击、HTTPS攻击以及DNS劫持发生的次数越来越多,特别是HTTPS由于已经被电子商务、互联网金融、政务系统等广泛使用,如果遭受攻击造成的损失和影响非常大,面对这些网络应用层安全事件,应该仔细分析目前的形势,探究发生这些事件的缘由,据此提出自己的建议。
1 应用层安全分析 网络OSI模型分七层,通过示意图我们可以看到应用层位于最顶端,目前仍然活跃并被广泛使用的应用层协议主要有:HTTP、HTTPS、SMTP、POP3、DNS、DHCP、NTP等,常见攻击主要利用http/https协议以及DNS协议进行。下面将就目前逐渐被广泛应用的https进行一些分析与研究。
HTTPS原理: 1.1 内容加密 加密算法一般分为两种,对称加密和非对称加密。对称加密就是指加密和解密使用的是相同的密钥。而非对称加密是指加密和解密使用了不同的密钥。如图1、图2所示。
对称加密的加密强度是挺高的,但是问题在于无法安全保存生成的密钥。 非对称加密则能够很好地解决这个问题。浏览器和服务器每次新建会话时都使用非对称密钥交换算法生成对称密钥,使用这些对称密钥完成应用数据的加解密和验证,会话在内存中生成密钥,并且每个对话的密钥也是不相同的,这在很大程度上避免了被窃取的问题,但是非对龙源期刊网 http://www.qikan.com.cn 称加密在提高安全性的同时也会对https连接速度产生影响,下面将会探究一下非对称加密算法,以便为下一步分析安全风险做准备
1.1.1 非对称密钥交换 非对称加密出现主要是为了解决对称密钥保存的安全性不足问题,密钥交换算法本身非常复杂,密钥交换过程涉及到随机数生成,模指数运算,空白补齐,加密,签名等操作。常见的密钥交换算法有RSA,ECDHE,DH,DHE等算法。它们的特性如下:
RSA:算法实现简单,诞生于1977年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数(目前常用的是2048位)来保证安全强度,很消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法。
DH:diffie-hellman密钥交换算法,诞生时间比较早(1977年),但是1999年才公开。缺点是比较消耗CPU性能。
ECDHE:使用椭圆曲线(ECC)的DH算法,优点是能用较小的素数(256位)实现RSA相同的安全等级。缺点是算法实现复杂,用于密钥交换的历史不长,没有经过长时间的安全攻击测试。
ECDH:不支持PFS,安全性低,同时无法实现false start。 建议优先使用RSA加密,这也是目前最普及的非对称加密算法,应用十分广泛 非对称密钥交换算法是整个HTTPS得以安全的基石,充分理解非对称密钥交换算法是理解HTTPS协议和功能的非常关键的一步,下面重点探究一下RSA在密钥交换过程中的应用。
1.1.1.1 RSA密钥协商 (1)RSA算法介绍。RSA算法的安全性是建立在乘法不可逆或者大数因子很难分解的基础上。RSA的推导和实现涉及到了欧拉函数和费马定理及模反元素的概念。从目前来看,RSA也是HTTPS体系中最重要的算法,没有之一。RSA的计算步骤如下:
1.随机挑选两个质数p, q,假设p = 13, q = 19。 n = p * q = 13 * 19 = 247。 2.∅(n)表示与整数n互质数的个数。如果n 等于两个质数的积,则∅(n)=(p-1)*(q-1) 挑选一个数e,满足1< e
3.计算e关于n的模反元素, ed≡1 mod ∅(n) ,由e = 17,∅(n)=216 可得 d = 89 龙源期刊网 http://www.qikan.com.cn 实际应用中,(n,e)组成了公钥对,(n,d)组成了私钥对,其中n和d都是一个接近2^2048的大数。即使现在性能很强的CPU,想要计算〖m ≡ c〗^d mod (n),也需要消耗比较大的计算资源和时间。公钥对(n, e)一般都注册到了证书里,任何人都能直接查看,比如百度证书的公钥对如图3,其中最末6个数字(010001)换算成10进制就是65537,也就是公钥对中的e。e取值比较小的好处有两个:
(1)由c= m^e mod (n)可知,e较小,客户端CPU计算消耗的资源较少。 (2)加大server端的破解难度。e比较小,私钥对中的d必然会非常大。所以d的取值空间也就非常大,增加了破解难度。那为什么(n,e)能做为公钥公开,甚至大家都能直接从证书中查看到,这样安全吗?分析如下:由于ed≡1 mod ∅(n),知道了e和n,想要求出私钥d,就必须知道∅(n)。而∅(n)=(p-1)*(q-1),必须计算出p和q才能确定私钥d。但是当n大到一定程度时(比如接近2^2048),即使现在最快的CPU也无法进行这个因式分解,即无法知道n是由哪个数p和q乘出来的。所以就算知道了公钥,整个加解密过程还是非常安全的。到此就将RSA算法的原理介绍了一下,图4 是以百度为例,其密钥就是RSA算法生成。
(2)握手过程中的RSA密钥协商。介绍完了RSA的原理,那最终会话所需要的对称密钥是如何生成的呢?跟RSA有什么关系?以TLS1.2为例简单描述一下,省略跟密钥交换无关的握手消息。过程如下:
(1)浏览器发送client_hello,包含一个随机数random1。 (2)服务端回复server_hello,包含一个随机数random2,同时回复certificate,携带了证书公钥P。
(3)浏览器接收到random2之后就能够生成premaster_secrect以及master_secrect。其中premaster_secret长度为48个字节,前2个字节是协议版本号,剩下的46个字节填充一个随机数。结构如下:
Struct { byte Version[2]; bute random[46]; } master secrect的生成算法简述如下: 龙源期刊网 http://www.qikan.com.cn Master_key = PRF(premaster_secret, “master secrect”, 随机数1+随机数2) 其中PRF是一个随机函数,定义如下: PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed)
从上式可以看出,把premaster_key赋值给secret,”master key”赋值给label,浏览器和服务器端的两个随机数做种子就能确定地求出一个48位长的随机数。而master secrect包含了六部分内容,分别是用于校验内容一致性的密钥,用于对称内容加解密的密钥,以及初始化向量(用于CBC模式),客户端和服务端各一份。至此,浏览器侧的密钥已经完成协商。
浏览器使用证书公钥P将premaster_secrect加密后发送给服务器。 服务端使用私钥解密得到premaster_secrect。又由于服务端之前就收到了随机数1,所以服务端根据相同的生成算法,在相同的输入参数下,求出了相同的master secrect。
RSA密钥协商握手过程图示如图5:可以看出,密钥协商过程需要2个RTT,这也是HTTPS慢的一个重要原因。而RSA发挥的关键作用就是对premaster_secrect进行了加密和解密。中间者不可能破解RSA算法,也就不可能知道premaster_secrect,从而保证了密钥协商过程的安全性。
通过上面的探究,https所采用的加密算法安全性比较高,但是现在存在一个问题那么使用了https就能确保安全传输了吗?是不是可以高枕无忧了呢?
2 安全验证与设计 理想上是安全的,现实却不是。 目前根据已经爆出的https安全事件发生的缘由可以分为两大类: (1)漏洞 2014年爆发heartbleed “心血”漏洞,就是因为openssl在实现TLS的心跳扩展时没有对输入进行适当验证使得https加密出现重大安全事件,其余的还有版本迭代出现的漏洞
(2)算法被攻破 基于摩尔定律,计算能力得到大幅调高,之前很多被认为安全的算法,也已经被攻破,譬如SHA-1算法目前已经能够在10内破解
下面将会以之前出现的漏洞,用https协议降级的方法来验证https所存在的漏洞 龙源期刊网 http://www.qikan.com.cn 我们之前提到SSL/TLS协议通过握手来确定通信信息,其中握手双方要统一加密协议版本。
在握手过程中这样确认加密协议版本: (1)由客户端(如浏览器)发送第一个数据包 ClientHello,这个数据包中保存着客户端支持的加密协议版本。
(2)服务器收到这个ClientHello数据包,查看里面客户端支持的加密协议版本,然后匹配服务器自己支持的加密协议版本,从而确认双方应该用的加密协议版本。
(3)服务器发送ServerHello数据包给客户端,告诉客户端要使用什么加密协议版本。 在上述过程中,如果客户端发送给服务器的ClientHello数据包中说自己仅支持某个有漏洞的旧版本加密协议(比如仅支持SSLv3.0),服务器有两种可能:
(1)服务器支持很多版本,其中包括有漏洞的旧版本和新版本(包括了SSLv3.0协议),那么服务器会认可使用有漏洞的旧版本协议,从而告诉客户端使用有漏洞的旧版本(可以使用SSLv3.0)。
(2)服务器不支持有漏洞的旧版本,拒绝客户端的这次请求,握手失败。 对于攻击者,作为中间人只能监听到加密过的数据,如果这些数据通过没有漏洞的加密版本加密,攻击者并不能做什么。
但是,如果服务器提供有漏洞的旧版本加密协议的支持,而同时攻击者又能作为中间人控制被攻击者的浏览器发起漏洞版本的HTTPS请求,那虽然攻击者监听到的也是加密过的数据,但因为加密协议有漏洞,可以解密这些数据,所以数据就和明文传输没有什么差别了。