域名频道资讯站
我们一直在努力制造惊吓

【转】从一次“自黑”来看Https的重要性

最近,一名对IT技术基本没有了解的快递员,因为通过锁定其他人的Apple ID获利3万余元,最终被公安机关抓获。据供述,他通过某种途径购入大量多类型邮箱账号,并尝试登陆AppleID,结果不出所料,部分用户的账号密码是通用的,所以他记录下这些账号,并修改了Apple ID密码。进而通过“查找我的iPhone”功能,将该iCloud绑定的苹果设备设置成丢失模式或抹掉状态,再发送一条所谓解锁QQ敲诈受害者,每笔300-800元。

现在因为Apple ID被窃取而被锁定的用户不在少数。按说苹果网站的安全性很高,账号密码应该没这么容易窃取,从上面的新闻也可以看出,大部分的Apple ID与其其它邮箱账号密码是相同的,这也就导致密码被窃的几率大增。那么,账号密码真的这么容易窃取?

自黑,如何窃取账号密码?

首先,我们先来个比较简单比较低级的方式。使用的工具是Wireshark,这是一个网络封包分析软件,用于撷取网络封包,并尽可能显示出最为详细的网络封包资料,类似于电工手中的万用表。这个软件一般只能监测本机的流量数据,因此通常被用作自检,但是如果配合ARP欺骗技术,就能够监控整个局域网的流量!

我们这次测试的是在本机。首先,你需要知道本机的IP以及即将访问网站的IP。以IT门户数字尾巴为例,通过Ping地址,我们得到数字尾巴的IP为203.195.146.235,而本机的IP为10.72.12.143。接下来就是打开Wireshark,然后开启监听。

这时候我们开始在数字尾巴的登陆界面输入账号密码,登陆后,关闭监听。我们来看看监听到了什么?

细心的读者或许已经看到,在监听的数据中明确写着如下几行代码:

username=17686******(这是笔者手机,做模糊处理哈)

password=Sj******(登录密码)

也就是说,数字尾巴的登陆没有做加密处理,只要能够登录,你的账号密码就会以明文的形式在网络传播!如果你的其它账号使用了同样的账号密码(事实上,笔者的确如此),一旦被窃取,其他网站的账户也就容易被攻破。

然后又测试了几个网站,发现可以直接获取明文账号密码的网站已经不是太多了。即使同样的Http登陆,也做了一些加密处理,比如通过session计算出一个常数,储存在服务器。在提交password的时候,在前端通过js将这个常数与用户输入的密码进行md5运算,运算结果POST给服务器。这样黑客们不需要知道你的明文密码,监听到你所谓的密文,然后用脚本发起一个Http请求就可以登录上去了。并且,既然服务器端需要验证,也就需要还原原始密码,既然有方法,这对于黑客来说就完全可以破解了。

或许,你又会说,那就设置更复杂的加密传输,比如非对称加密。但是,这不是Https提供的功能么?而且Https提供的安全保障还可以应对其他的攻击。所以,目前来看Https是解决账号安全的靠谱方案。

Https真能解决问题?

先说结论:真能!这就要先说说Https的核心——非对称加密。Https在HTTP下加入SSL层(安全套接层)/TLS(TLS是SSL的升级协议),HTTPS在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行数次握手,在握手过程中将确立双方加密传输数据的密码信息,这样,Https就能保障数据在传输过程中不被非法篡改和利用。而Https握手加密使用的是非对称加密。

对称加密算法是指加密和解密时使用的是同一个秘钥;而非对称加密算法需要两个密钥来进行加密和解密,这两个秘钥是公开密钥(public key)和私有密钥(private key)。以最常用的RSA为例,它的原理是:

随意选择两个大的质数p和q,p不等于q,计算N=pq。根据欧拉函数,求得r = (p-1)(q-1)选择一个小于r 的整数e,求得e 关于模r 的模反元素,命名为d。(模反元素存在,当且仅当e与r互质)将p 和q 的记录销毁。

这其中(N,e)就是公钥,(N,d)是私钥。传输过程中,只发送公钥(N,e),私钥(N,d)则不在传输中体现。

这种加密其实就是利用了一个数学难题:当p和q是一个大素数的时候,从它们的积pq去分解因子p和q是很难的

举个例子: 3233可以进行因数分解为61×53,但是你可以试试如下数字的因数分解: 1230186684530117755130494958384962720772853569595334792197322452151726400507263657

51874520219978646938995647494277406384592519255732630345373154826850791702612

2142913461670429214311602221240479274737794080665351419597459856902143413

而这只是一个232个十进制位(768个二进制位)的数字哦,目前主流的加密会使用1024位甚至更高。事实上这是目前人类能分解的最大整数,1024位的破解尚未被报道(但估计也用不太久的时间,所以还是推荐使用更高位的加密)。

因此,目前采用RSA1024或者更高加密方法的Https是安全的,暂时还不用担心会被破解。但是越来越高的质数分解,导致服务器端的加密和解密计算量大增,这也导致用户在访问Https网站时候可能导致一定的延迟。

SSL造成的延迟到底有多少?

下面我们来实际测试下SSL将会造成大少的延迟。命令行工具curl有一个w参数,可以用来测量TCP握手和SSL握手的具体耗时。

curl -w "TCP handshake: %{time_connect}, SSL handshake:%{time_appconnect}n" -so /dev/null Https://www.zhihu.com

TCP handshake耗时在23-54ms,而SSL handshake在88-145ms之前。延迟跟网络有关系(内网环境下,网络延迟较高),但一般SSL造成的延迟是TCP握手的3-4倍。

这部分延迟除了网络问题,最重要的还有加密和解密所造成的延迟,因为后台服务器在验证大数字密钥时候需要耗费大量的计算资源。有数据显示,在同等硬件条件下,2048bit Https比Http并发性能要弱5-10倍,甚至更多。而据小米公司实测,正常情况下,一个16核的CPU能够达到300OPS(每秒3000次RSA操作)就算不错的成绩了。但是,每个网站不仅包括一个页面,比如主页面、登录页面、子页面等等,这些都需要通过SSL进行加密传输数据,因此通用x86服务器做SSL加解密会造成较高的延时,并且在高并发访问时容易造成服务器宕机。

有方法!浪潮SSL加解密解决方案

那么,面对如此严峻的网络安全环境和不断提升的加解密计算性能消耗,如何更高效的进行SSL加解密?答案是采用更有的计算解决方案,比如浪潮SSL加解密解决方案。

既然依靠CPU的通用计算不能很好地进行SSL加解密的高速运算,那么是不是能够通过专用的加速卡来实现?就像用GPU来实现图像运算那样,答案是肯定的。SSL专用加速卡,相比x86架构的CPU,虽然不能胜任通用计算应用需求,但是经过专门的算法和架构优化,在进行RSA加密计算时的性能大大优于传统架构。

浪潮基于SA5212M4的、专门面向SSL加解密加速的软硬一体化解决方案,支持2块SSL加速卡,支持IPsec、SSL 加速和压缩功能,可提供高达50 Gbps 的加密速度和高达24 Gbps 的压缩性能。在单卡情况下即可实现在RSA1024操作中190K OPS(每秒运算次数),而在RSA2048时也能达到35K的速度,与通用服务器相比能够有10倍以上的性能提升。

在网络安全问题频发的今天,为了自身网站的正常运转以及用户的隐私安全,越来越多的网站启用Https。浪潮SSL加解密解决方案则通过高效的计算加速技术,让Https的延迟更低,用户体验更优。

(文章转载自网络,有版权问题请联系邮箱tougao@22.cn)

本文章素材来自互联网

赞(0)
分享到: 更多 (0)

中国专业的网站域名及网站空间提供商

买域名买空间