新葡亰496net Web前端 黑客传道:解析中间人攻击之SSL欺骗

黑客传道:解析中间人攻击之SSL欺骗



为什么 HTTP 有时候比 HTTPS 好?

2015/05/15 · HTML5 · 3
评论 ·
HTTP,
HTTPS

原文出处:
stormpath   译文出处:开源中国社区   

做为一家安全公司,我们在站点Stormpath上经常被开发者问到的是有关安全方面最优做法的问题。其中一个被经常问到的问题是:

我是否应当在站点上运行HTTPS?

很不幸,查遍整个因特网,你大多数情况下会得到同样的建议:加密所有的东西!对所有站点进行SSL加密等等!然而,现实情况表明这通常不是一个好的建议。

许多情况下使用HTTP比使用HTTPS要好很多。事实上,HTTP是一个在性能上和可用性上比HTTPS更好的一种协议,这也就是我们经常推荐客户使用HTTP的原因。下面我们说一说我们的理由……

使用 HTTPS 会出现的问题

HTTPS 是一个错漏百出的协议.
此协议及其现今流行的实现中许许多多众所周知的问题使得它不适用于许多各种各样的web服务。

HTTPS 十分缓慢

图片 1

应用 HTTPS 的主要阻碍之一就是 HTTPS 协议十分缓慢的这一事实。

就其特性而言,HTTPS
就是在两端之间进行安全的加密通信。这需要两端都持续耗费宝贵的CPU时间周期:

●一开始说“hello”就决定使用哪种类型的加密方式 (暗号方案套件)

●验证SSL证书

●为每一个请求的验证以及对请求/回应的验证核实,运行加密代码

而这听起来不是特别形象,其实就是加密代码运行的是CPU密集型的操作。它会重度使用浮点运算的CPU寄存器,会征用你的CPU从而使得请求的处理变慢。

这里有一个内容十分丰富的 ServerFault 线程,展示了在使用代用 Apache2
的一个 Ubuntu
服务器时,相比之下的处理速度你所能预计会有多大的降低:

如下是结果:

图片 2

即使是像上面所展示的一个非常简单的示例,HTTPS也能将你的Web服务器的速度拖慢超过40倍!
这可拖了web性能很大的后腿.

在今天的环境中, 将你的应用程序作为 REST API
的一个组成部分来构建是很普遍的 — 使用 HTTPS
确实是会拖慢你的网站、影响你的应用程序性能并给你的服务器CPU带来不必要的冲击的一种方式,而且通常会惹恼你的用户。

对于许多对速度敏感的应用程序而言,使用原始的 HTTP 常常要好很多。

HTTPS 不是一个放之四海而皆准的安全保障

图片 3

许多人都会抱有 HTTPS
会让他们的站点更安全,这样一种印象。这其实不是真的。

HTTPS 只是对你和服务器之间的流量进行了加密 —
一旦HTTPS信息的传输中断了,一切就又都是一场公平的游戏。

这意味着如果你的计算机已经感染的了恶意软件,或者你已经被受到欺骗运行了某些恶意软件
— 这个世界上所有的HTTPS对于你而言也都无能为力了。

此外,如果 HTTPS 服务器上存在任何的漏洞,某些攻击者就能够简单的等到
HTTPS 已经处理结束,然后再在其它的层(例如 web
服务这一层)抓取到不管什么数据。

SSL 证书本身也经常被滥用。比如,其在浏览器上的处理方式就很容易发生错误:

●每种浏览器(Mozilla,google
等)都是独立审计并核准根证书提供商来保证他们安全地处理SSL证书

●一旦核准通过,这些根 SSL
证书就会被添加到浏览器的可信证书列表,这意味任何由根证书提供商签名的证书都是默认可信的。

●这些提供商因此可随意乱搞,导致各类安全问题频发,比如2011年发生的
DigiNostar 事件。

以上种种,著名证书授权机构错误地签名了大量的伪造和欺诈的证书,直接损害数以万计的Mozilla用户的安全。

而 HTTP 并没有提供任何形式的加密服务,至少你知道你正在处理什么东西。

HTTPS流量很容易被监听

如果你正在构建一个需要被不安全的设备(比如移动 app)使用的 web
服务,你可能觉得因为你的服务运行于 HTTPS 上,通信就不会被监听了。

如果真这么想的话,你就错了。

其他人可以轻松地在电脑上设置代理来截获并查看HTTPS流量,也就越过了SSL证书检查,这就直接泄漏了你的私人信息。

这篇博文就演示了移动设备上的 https 消息监听。

你觉得没多大事?别做梦了!就连Uber这种大公司的移动应用都被逆向了,它们也用了
HTTPS。如果你灰心了,我劝你还是别看这篇文章了。

好了,接受现实吧,不管你怎么做,攻击者都能用这样或那样的方法来监听你的网络流量。与其把时间浪费在修复
SSL 的问题上,还不如花点时间想想如何明智地使用 HTTP 吧。

HTTPS 有漏洞

大家都知道 HTTPS 并不是铁板一块。多年来 HTTPS 被曝出了不少漏洞:

●POODLE (pdf)

●BEAST

●CRIME

●Heartbleed

●…

以后的攻击会越来越多。再加上 NSA 为了解密,正不遗余力地收集着 SSL
流量——使用 HTTPS 似乎一点用处都没有,因为不定什么时候你的 HTTPS
流量就会被一览无余。

HTTPS 太贵

最后要说的一点是 HTTPS
太贵了。你需要从根证书颁发机构购买浏览器和客户端能够识别的 SSL 证书。

这可不便宜啊。

SSL证书年费从几美刀到几千不等——如果你正在构建基于多个微服务(multiple
microservices)的分布式应用,你需要买的证书可不只一个。

对于小项目或预算紧张的人来说成本一下子就抬高了不少。

为什么 HTTP 是一个不错的选择

在另一方面,让我们稍稍不那么消极片刻,而是专注于积极的东西 :
是什么使得HTTP很棒的。大多数开发者并不欣赏它的好处。

正确条件下的安全

当然HTTP本身没有提供任何安全性,通过正确的设置你的基础设施和网络,你可以避免几乎所有的安全问题。

首先,对于所有的你可能会用到的内部HTTP服务,
要确保你的网络是私有的,不能从公共的外部环境嗅探到数据包.
这意味着你将可能徐昂要将你的HTTP服务部署在一个像Amazon
EC2这样的非常安全的网络里面.

通过在 EC2 部署公共的云服务器,就能保证你拥有一流的网络安全,
防止任何其他的AWS用户嗅探到你的网络流量.

使用 HTTP 的不安全性来扩展

人们过多的关注于 HTTP
缺乏安全和加密特点的时候,许多人没有想到的是,这种协议可以提供很好的扩展性。

大部分现代的Web应用程序通过队列来扩展。

你有一个Web服务器接受请求,然后用处在相同网络上的服务器集群运行单独的jobs来处理更多的CPU和内存密集型任务。

为了处理任务的排队,人们通常使用一个诸如 RabbitMQ or Redis
这样的系统。两个都是不错的选择,但是否可以除了你的网络外不使用任何基础设施组件而获得任务队列的好处呢?

使用HTTP,你可以!

它是这样工作的:

●建立Web服务器和所有处理服务器共享子网的一个网络。

●让你的处理服务器侦听网络上的所有数据包,和被动嗅探网络流量。

●当Web服务器收到HTTP流量,那些处理服务器可以简单地读取进来的请求(纯文本,因为HTTP不加密),并立即开始处理工作!

上述系统的工作原理就像一个分布式队列,快速,高效,简单。

使用 HTTPS,上述情况是不可能的,但是,通过使用
HTTP,可以大大加快您的应用程序同时去除(不必要的)基础设施–这是一个大的胜利。

不安全和自负

最后一个我建议使用HTTP而不是HTTPS的原因:不安全。

是的,HTTP 没有给你的用户提供安全,但是,安全真的有必要吗?

不仅大部分 ISP
监控网络通信,过去数年的很长一段时间里,很明显的是政府已经存储并解密了大量网络通信。

使用 HTTPS
的顾虑正好比将一个挂锁来放在一尺高的篱笆上,大致来说,你不可能保证应用的安全。所以,何必这么麻烦呢?

开发仅依靠 HTTP
的服务,这并没有给你的用户一种安全的错觉,或者欺骗用户认为自身很安全。事实上,他们很有可能认为是不安全的,

开发基于 HTTP 的程序,你的生活将得到简化,并增强和你用户的透明。

考虑一下吧。

在逗你玩呢 !! >:)

愚人节快乐哦 !

我喜欢你不会真的任务我会建议你不去使用HTTPs ! 我想要非常明确的告诉你 :
如果你要构建任何什么类型的web应用, 要使用 HTTPS 哦!

你要构建什么类型的应用程序或者服务并不重要,而如果它没有用到HTTPS,你就做错了.

现在,让我们来聊聊HTTPS为什么很棒.

HTTPS 是安全的

图片 4

HTTPS 是一个业绩优良的很棒的协议.
虽然这些年来有过几次针对其漏洞的利用事件发生,
但它们一直都是相对较为轻微的问题,而且也很快被修复了.

而诚然,NSA确实在某个阴暗的角落收集着SSL流量,
但他们能够解密即使是很少量SSL流量的可能性都是极小的 —
这会需要快速的,功能齐全的量子计算机,并耗费数量惊人的钞票.
这玩意存在的可能性貌似不存在,因此你可以高枕无忧了,因为你知道你的站点上的SSL确实在为你的用户数据传输保驾护航.

HTTPS 速度是快的

上面我曾提到HTTPS“遭罪似的慢” , 但事实则几乎完全相反.

HTTPS 确实需要更多的CPU来中断 SSL 连接 —
这需要的处理能力对于现代计算机而言是小菜一碟了.
你会遇到SSL性能瓶颈的可能性完全为0.

目前你更有可能在你的应用程序或者web服务器性能上遇到瓶颈.

HTTPS 是一个重要的保障

虽然 HTTPS 并不放之四海而皆准的web安全方案,但是没有它你就不能以策万全.

所有的web安全都倚赖你拥有了 HTTPS. 如果你没有它,
那么不管你对你的密码做了多强的哈希加密,或者做了多少数据加密,攻击者都可以简单的模拟一个客户端的网络连接,读取它们的安全凭证——然后轰的一声——你的安全小把戏结束了.

因此 —
虽然你不能有赖于HTTPS解决所有的安全问题,你绝对100%需要将其应用于你构建的所有服务上
— 否则完全没有任何办法保证你的应用程序的安全.

此外,虽然证书签名很显然不是一个完美的实践,但每一种浏览器厂商针对认证机构都有相当严格和严谨的规则.
要成为一个受到信任的认证机构是非常难的,而且要保持自己良好的信誉也同样是困难的.

Mozilla (以及其其他厂商)
在将不良根认证机构踢出局这项工作方面表现相当出色,而且一般也真正是互联网安全的好管家.

HTTPS 流量拦截是可以避免的

先前我提到过,可以很容易的通过创建属于你自己的SSL证书、信任它们,从而在SSL通讯的中途拦截到流量.

虽然这绝对有可能,但也很容易可以通过 SSL 证书钢钉 来避免 .

本质上讲,依照上面链接的文章中给出的准则,
你可以是的你的客户只去信任真正可用的SSL证书,有效的阻挡所有类型的SSL
MITM攻击,甚至在它们开始之前 =)

如果你是要把SSL服务部署到一个不受信任的位置(像是一个移动或者桌面应用),
你最应该考虑使用SSL证书钢钉.

HTTPS(再也)不贵了

虽然历史上HTTPS曾经昂贵过,而这是事实 — 但再也不是这样了.
如今你能够从许许多多的web主机那里买到非常便宜的SSL证书.

此外, EFF (电子前沿基金会) 正要推出一个完全免费的 SSL 证书提供机构:

它会在 2015 推出, 并必然将改变所有web开发者的游戏规则.
一旦让加密的方案上线,你就能够对你的网站和服务进行100%的加密,完全没有任何花费.

请一定要访问他们的网站,并订阅更新哦!

HTTP 在私有网络上并不是安全的

早些时候,我谈到HTTP的安全性怎么是不重要的,特别是如果你的网络被锁上(这里的意思是切断了同公共网络的联系)
— 我是在骗你。

而网络安全是重要的,传输的加密也是!

如果一个攻击者获得了对你的任何内部服务的访问权限,所有的HTTP流量都将会被拦截和解读,
不管你的网络可能会有多“安全”. 这很不妙哦。

这就是为什么 HTTPS 不管是在公共网络还是私有网络都极其重要的原因。

额外的信息:
如果你是吧服务部署在AWS上面,就不要想让你的网络流量是私有的了! AWS
网络就是公共的,这意味着其它的AWS用户都潜在的能够嗅探到你的网络流量 —
要非常小心了。

我早些时候有提到,HTTP可以用来代替队列,是的,我没说错,但这是一个很可怕的主意!

由于安全原因,放大服务的规模,是一个很可怕的,糟糕的注意。请不要这么做。

(除非这是一个概念证据,只为了造一个很酷的演示产品而已)

总结

如果你正在做网页服务,毫无疑问,你应该使用HTTPS。

它很容易、廉价,且能获得用户信任,没有理由不用它。作为码农,我们必须要承担起保护用户的重任,要做到那点,方法之一就是强制使用HTTPS、

希望你喜欢这篇文章,供君一乐。

赞 1 收藏 3
评论

图片 5

图片 6

图片 7

   4. 服务器向客户端提供包含其电子签名的证书,该证书用于验证网址
  5. 客户端获取该证书,并根据信任证书颁发机构列表来验证该证书

引用作者:经伦,阿里云安全专家,负责阿里云安全证书和加密服务。
欢迎技术投稿、约稿、给文章纠错,请发送邮件至heyc@csdn.net互联网发展20多年,大家都习惯了在浏览器地址里输入HTTP格式的网址。但前两年,HTTPS逐渐取代HTTP,成为传输协议界的“新宠”。早在2014年,由网际网路安全研究组织Internet
Security Research Group(ISRG)负责营运的 “Let’s
Encrypt”项目就成立了,意在推动全球网站的全面HTTPS化;今年6月,苹果也要求所有IOS
Apps在2016年底全部使用HTTPS;11月,Google还宣布,将在明年1月开始,对任何没有妥善加密的网站,竖起“不安全”的小红旗。去年,淘宝、天猫也启动了规模巨大的数据“迁徙”,目标就是将百万计的页面从HTTP切换到HTTPS,实现互联网加密、可信访问。更安全、更可信,是HTTP后面这个“S”最大的意义。HTTPS在HTTP的基础上加入了SSL/TLS协议,依靠SSL证书来验证服务器的身份,并为客户端和服务器端之间建立“SSL加密通道”,确保用户数据在传输过程中处于加密状态,同时防止服务器被钓鱼网站假冒。HTTP为什么过时了?很多网民可能并不明白,为什么自己的访问行为和隐私数据会被人知道,为什么域名没输错,结果却跑到了一个钓鱼网站上?互联网世界暗流涌动,数据泄露、数据篡改、流量劫持、钓鱼攻击等安全事件频发。而未来的互联网网络链路日趋复杂,加重了安全事件发生。可能在星巴克被隔壁桌坐着的黑客嗅探走了口令,或者被黑了家庭路由器任由电子邮件被窃
听,又或者被互联网服务提供商秘密注入了广告。这一切都是由互联网开始之初面向自由互联开放的HTTP传输协议导致的。HTTP数据在网络中裸奔HTTP明文协议的缺陷,是导致数据泄露、数据篡改、流量劫持、钓鱼攻击等安全问题的重要原因。HTTP协议无法加密数据,所有通信数据都在网络中明文“裸奔”。通过网络的嗅探设备及一些技术手段,就可还原HTTP报文内容。网页篡改及劫持无处不在篡改网页推送广告可以谋取商业利益,而窃取用户信息可用于精准推广甚至电信欺诈,以流量劫持、数据贩卖为生的灰色产业链成熟完善。即使是技术强悍的知名互联网企业,在每天数十亿次的数据请求中,都不可避免地会有小部分流量遭到劫持或篡改,更不要提其它的小微网站了。智能手机普及,WIFI接入常态化WIFI热点的普及和移动网络的加入,放大了数据被劫持、篡改的风险。开篇所说的星巴克事件、家庭路由器事件就是一个很有意思的例子。自由的网络无法验证网站身份HTTP协议无法验证通信方身份,任何人都可以伪造虚假服务器欺骗用户,实现“钓鱼欺诈”,用户根本无法察觉。HTTPS,强在哪里?我们可以通过HTTPS化极大的降低上述安全风险。从上图看,加密从客户端出来就已经是密文数据了,那么你的用户在任何网络链路上接入,即使被监听,黑客截获的数据都是密文数据,无法在现有条件下还原出原始数据信息。各类证书部署后浏览器呈现效果,免费SSL数字证书OV
SSL数字证书EV
SSL数字证书全世界都对HTTPS抛出了橄榄枝浏览器们对HTTP页面亮出红牌谷歌、火狐等主流浏览器将对HTTP页面提出警告。火狐浏览器将对“使用非HTTPS提交密码”的页面进行警告,给出一个红色的阻止图标;Google
Chrome浏览器则计划将所有HTTP网站用“Not
secure”显注标识。图片来源:Googleblog对于一般用户来讲,如果是这样标识的网站,可能会直接放弃访问。苹果iOS强制开启ATS标准苹果宣布2017年1月1日起,所有提交到App
Store 的App必须强制开启ATS安全标准(App Transport
Security),所有连接必须使用HTTPS加密。包括Android也提出了对HTTPS的要求。HTTP/2协议只支持HTTPSChrome、火狐、Safari、Opera、IE和Edge都要求使用HTTPS加密连接,才能使用HTTP/2协议。HTTPS提升搜索排名谷歌早在2014年就宣布,将把HTTPS作为影响搜索排名的重要因素,并优先索引HTTPS网页。百度也公告表明,开放收录HTTPS站点,同一个域名的http版和版为一个站点,优先收录版。英美强制要求所有政府网站启用HTTPS美国政府要求所有政府网站都必须在2016年12月31日之前完成全站HTTPS化,截至2016年7月15日,已经有50%政府网站实现全站HTTPS。英国政府要求所有政府网站于2016年10月1日起强制启用全站HTTPS,还计划将service.gov.uk提交至浏览器厂商的HSTS预加载列表,只有通过HTTPS才能访问政府服务网站。超级权限应用禁止使用HTTP连接采用不安全连接访问浏览器特定功能,将被谷歌Chrome浏览器禁止访问,例如地理位置应用、应用程序缓存、获取用户媒体等。从谷歌Chrome
50版本开始,地理定位API没有使用HTTPS的web应用,将无法正常使用。只有部分网页可不够,全站HTTPS才是最佳方案很多网站所有者认为,只有登录页面和交易页面才需要HTTPS保护,而事实上,全站HTTPS化才是确保所有用户数据安全可靠加密传输的最佳方案。局部部署HTTPS,在HTTP跳转或重定向到HTTPS的过程中,仍然存在受到劫持的风险[1]。情况一:从HTTP页面跳转访问HTTPS页面事实上,在
PC 端上网很少有直接进入 HTTPS
网站的。例如:支付宝网站大多是从淘宝跳转过来,如果淘宝使用不安全的 HTTP
协议,通过在淘宝网的页面里注入 XSS,屏蔽跳转到 HTTPS
的页面访问,那么用户也就永远无法进入安全站点了。图片来源:EtherDream《安全科普:流量劫持能有多大危害?》尽管地址栏里没有出现
HTTPS
的字样,但域名看起来也是正确的,大多用户都会认为不是钓鱼网站,因此也就忽视了。也就是说,只要入口页是不安全的,那么之后的页面再安全也无济于事。情况二:HTTP页面重定向到HTTPS页面有一些用户通过输入网址访问网站,他们输入了
就敲回车进入了。然而,浏览器并不知道这是一个 HTTPS
的站点,于是使用默认的 HTTP 去访问。不过这个 HTTP
版的支付宝的确也存在,其唯一功能就是重定向到自己 HTTPS
站点上。劫持流量的中间人一旦发现有重定向到 HTTPS
站点的,于是拦下重定向的命令,自己去获取重定向后的站点内容,然后再回复给用户。于是,用户始终都是在
HTTP
站点上访问,自然就可以无限劫持了。图片来源:EtherDream《安全科普:流量劫持能有多大危害?》而全站HTTPS化可以确保用户在访问网站时全程HTTPS加密,不给中间人跳转劫持的机会。国外各大知名网站都通过Always
on
SSL技术措施来保证用户机密信息和交易安全,防止会话劫持和中间人攻击。图片来源:Symantec《Protect
the Entire Online User Experience: with Always On
SSL》那么问题来了,为什么HTTPS百般好,全世界却还有过一半的网站,还在使用HTTP呢?首先,很多人还是会觉得HTTPS实施有门槛,这个门槛在于需要权威CA颁发的SSL数字证书。从证书的选择、购买到部署,传统的模式下都会比较耗时耗力。目前,主流CSP都集成了多家证书颁发机构的SSL证书,部署过程也相对更容易一些。因“麻烦”和“门槛”而不HTTPS化的现象,预测也将有所缓解。第二是性能。HTTPS普遍认为性能消耗要大于HTTP。但事实并非如此,用户可以通过性能优化、把证书部署在SLB或CDN,来解决此问题。举个实际的例子,“双十一”期间,全站HTTPS的淘宝、天猫依然保证了网站和移动端的访问、浏览、交易等操作的顺畅、平滑。通过测试发现,经过优化后的许多页面性能与HTTP持平甚至还有小幅提升,因此HTTPS经过优化之后其实并不慢。最后是安全意识。相比国内,国外互联网行业的安全意识和技术应用相对成熟,HTTPS部署趋势是由社会、企业、政府共同去推动的。不过,随着国内等保、网络安全、P2P监管措施的普及,HTTPS也有望造福更多网民。[1]参考来源:EtherDream文章《安全科普:流量劫持能有多大危害?》
[2] 参考来源:Symantec文章《Protect the Entire Online User Experience:
with Always On SSL》

图1: HTTPS通信过程

   1. 客户端与web服务器间的流量被拦截

   图1显示的过程并不是特别详细,只是描述了下列几个基本过程:

前面的文章中,我们已经探讨了ARP缓存中毒、DNS欺骗以及会话劫持这四种中间人攻击形式。在本文中,我们将研究SSL欺骗,这也是最厉害的中间人攻击方式,因为SSL欺骗可以通过利用人们信赖的服务来发动攻击。首先我们先讨论SSL连接的理论及其安全性问题,然后看看SSL连接如何被利用来发动攻击,最后与大家分享关于SSL欺骗的检测以及防御技巧。

   在本文中,我们将重点探讨通过HTTP(即HTTPS)对SSL的攻击,因为这是SSL最常用的形式。可能你还没有意识到,你每天都在使用HTTPS。大多数主流电子邮件服务和网上银行程序都是依靠HTTPS来确保用户浏览器和服务器之间的安全通信。如果没有HTTPS技术,任何人使用数据包嗅探器都能窃取用户网络中的用户名、密码和其他隐藏信息。

图2:劫持HTTPS通信

  2. 服务器试用HTTP代码302重定向客户端HTTPS版本的这个网站

标签:

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图