Tag:https

Tag (https)'s result:

HTTPS浅析与抓包分析

0x00 HTTP之殇 数据明文传输,易嗅探 数据完整性无验证,易篡改 网站身份无认证,易假冒 由此诞生HTTPS。   0x01 什么是HTTPS HTTP + SSL/TLS TLS是SSL的升级版 二图胜千言: //图片来源于网络   作用:防嗅探,防篡改,身份认证   0x02 https握手过程 建立https连接(明文),再用对称加密传输数据。 TCP三次握手 C->S:[client hello] C发送hello消息(协议版本,随机数c,加密组件列表等)给S,请求建立SSL会话。 S->C: [server hello]返回响应(确认加密组件,随机数s等)。 S->C: [certificate]返回响应certificate(网站证书)。 S->C: [server key exchange]指定密钥协商(交换)协议(密钥协商方式),发送密钥协商(交换)算法的公钥给C。 S->C: [server hello done]发送serverhellodone,开始C的密钥协商。 C->S: [clientkeyexchange]C生成密钥协商(交换)算法公私钥,发送公钥给S,此时C和S可以协商出相同的密钥pre master secret,现在C和S可以通过c,s,pre master三个随机数算出对称加密的密钥。(这里本人还看到一个版本是C生成pre master secret 后用密钥交换/协商算法加密发送到S,本人认为不需要发送,S通过C发送的密钥协商的公钥和自己生成的一个随机数xs可以自己计算出这个pre master secret。还有一个版本是对称加密的密钥是C用S的证书公钥加密给S用私钥解密获得,这里本人认为此对称密钥S也可由c,s,pre master自己生成不需要C发送。) C->S: [changecipherspec]通知S此消息以后C以加密方式发送数据。 C->S: C用生成的对称密钥加密之前所有握手消息hash,发送给S解密验证hash。 S->C: [changecipherspec]通知C此消息后S以加密方式发送数据。 S->C: S用对称密钥加密之前所有握手消息hash,发送给C进行解密验证hash。 ======================================== 开始对称加密传输数据……(Application Data) ========================================   0x03 抓包分析https握手流程 以浏览器打开https://www.52pojie.cn为例 1. dns解析和tcp三次握手 2. clienthello: 可以看出浏览器发送了支持的协议版本TLS1.2,32字节随机数c,加密组件cipher等信息给S。 3. serverhello: 可以看出S选择了TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384加密组件,解释如下: 密钥交换算法,用于决定客户端与服务器之间在握手的过程中如何认证,用到的算法包括RSA,Diffie-Hellman,ECDH,PSK等,这里选择了ECDHE。 加密算法,用于加密消息流,该名称后通常会带有两个数字,分别表示密钥的长度和初始向量的长度,比如DES 56/56, RC2 56/128, RC4 128/128, AES 128/128, AES 256/256。这里选择了AES。 报文认证信息码(MAC)算法,用于创建报文摘要,确保消息的完整性(没有被篡改),算法包括MD5,SHA等。这里选择了SHA384。 PRF(伪随机数函数),用于生成“master secret”。 S还发送了32字节随机数s。 4.certificate: 第一个cert是52pojie网站的证书,第二个cert是颁发者trustasia机构的证书。 这里可以获得证书的详细信息,详情参考浅析数字签名和数字证书 5. serverkeyexchange和serverhellodone: 可以看出使用ECDH密钥交换算法,指定椭圆曲线secp256r1,还有发送了DH算法协商的公钥给C。 6. Clientkeyexchange和client change cipher spec: 这里C发送了DH算法协商的公钥给S,以及加密了握手消息给S进行验证。 7. server change cipher spec: 服务端使用Ticket方式存储session状态,在Server Change Cipher Spec之前就需要发送New Session Ticket消息,这部分就不细说了。这里S加密握手消息给C进行验证。 8. application data: 这里可以看出双方握手完毕,以后的消息都进行对称加密,已经无法看出明文了。   0x04 其他 由于握手流程导致https速度比http慢,本人认为其带来的安全性更为重要,而速度虽然较慢,但是用户几乎感觉不到,而且有很多优化措施可以提升速度。 有了https并不能完全保证网站安全,安全是多因素,多环节的,即使有https,某个‘短板’就可以沦陷一个网站,并且https自身也非安全,如著名的心脏出血漏洞。 https也非绝对防止MITM,如伪造证书,导出明文密码等。   0x05 结语 简言之,能用https还是用https吧。由于时间仓促,可能有些细节遗漏或不准确,欢迎指正!   0x06 参考资料 https://xianzhi.aliyun.com/forum/read/2037.html www.droidsec.cn/浅析https中间人攻击与证书校验/ https://klionsec.github.io/2017/07/31/https-learn/ kb.cnblogs.com/page/530044/  

(转)Why HTTP is Sometimes Better than HTTPS

本文转载自:https://stormpath.com/blog/why-http-is-sometimes-better-than-https //来自LSA的温馨建议:看此文切不可半途而废,即使快进也要看完,剧情有反转! UPDATED April 2, 2015: This was an April Fools Joke. Read. Laugh. Learn. If you’re building web services, you should most definitely be using HTTPS. As a security company, we frequently get questions here at Stormpath from developers regarding security best practices. One of the most common questions we get is: Should I run my site over HTTPS? Unfortunately, regardless of where you go on the internet, you’ll mostly ready the same advice: encrypt everything!, use SSL for all sites!, etc. The reality, of course, is that this is not usually good advice. There are many circumstances where HTTP is better than HTTPS. HTTP is, in fact, a much better and more useful protocol than HTTPS, which is why we often recommend it to our customers. Here’s why… The Problems with HTTPS HTTPS as a protocol is riddled with problems. Numerous, well-known issues with the protocol and popular implementations make it unsuitable for a wide variety of web services. HTTPS is Painfully Slow One of the primary blockers……

(转)Top 7 Myths about HTTPS

本文转载自:http://blog.httpwatch.com/2011/01/28/top-7-myths-about-https Myth #7 – HTTPS Never Caches People often claim that HTTPS content is never cached by the browser; perhaps because that seems like a sensible idea in terms of security. In reality, HTTPS caching is controllable with response headers just like HTTP. Eric Lawrence explains this succinctly in his IEInternals blog: It comes as a surprise to many that by-default, all versions of Internet Explorer will cache HTTPS content so long as the caching headers allow it. If a resource is sent with a Cache-Control: max-age=600 directive, for instance, IE will cache the resource for ten minutes. The use of HTTPS alone has no impact on whether or not IE decides to cache a resource. (Non-IE browsers may have different default behavior for caching of HTTPS content, depending on which version you’re using, so I won’t be talking about them.) The slight caveat is that Firefox will only cache HTTPS resources in memory by default. If you want persistent caching to disk you’ll need to add the Cache-Control: Public……

(转)“HTTPS”安全在哪里?

本文转载自:http://bugly.qq.com/bbs/forum.php?mod=viewthread&tid=1074&highlight=https 背景 最近基于兴趣学学习了下 HTTPS 相关的知识,在此记录下学习心得。 在上网获取信息的过程中,我们接触最多的信息加密传输方式也莫过于 HTTPS 了。每当访问一个站点,浏览器的地址栏中出现绿色图标时,意味着该站点支持 HTTPS 信息传输方式。我们知道 HTTPS 是我们常见的 HTTP 协议与某个加密协议的混合体,也就是 HTTP+S。这个 S 可以是 TLS(安全传输层协议)、也可以是 SSL(安全套接层),不过我更认可另一个抽象概括的说法,HTTP+Security。不过要谈论 HTTPS 为何安全,还得从 HTTP 为何不安全说起。 假设你现在正坐在教室里上课,现在你非常想和走道旁的迷人的 TA 说一些话,一般这个时候你会用“传纸条”的方式来交流。而这个方式和 TCP/IP 协议基本的工作模式十分相像: 通过小动作引起对方注意; 对方以多种可能的方式(注视、肢体语言等)回应于你; 你确认对方感知到你后,将纸条传给对方; 对方阅读纸条; 对方给予你阅读后的反应; 怎么样,这个流程是不是很熟悉? 如果你要传递纸条的 TA 距离你很远怎么办?HTTP 协议就是指你在纸条上写明你要传给的 TA 是谁,或者 TA 的座位在哪,接着只需要途径的同学拿到纸条后根据纸条上的指示依次将纸条传过去就 OK 了。 这个时候问题来了:途径的同学完全可以观看并知道你在纸条上写了什么。 这就是 HTTP 传输所面临的问题之一:中间人攻击,指消息传递的过程中,处在传递路径上的攻击者可以嗅探或者窃听传输数据的内容。 加密 HTTPS 针对这个问题,采用了“加密”的方式来解决。最著名原始的加密方法就是对称加密算法了,就是双方约定一个暗号,用什么字母替换什么字母之类的。现在一般采用一种叫 AES(高级加密算法)的对称算法。 对称加密算法既指加密和解密需要使用的密钥 key 是一样的。 AES 在数学上保证了,只要你使用的 key 足够长,破解几乎是不可能的(除非光子计算机造出来了) 我们先假设在没有密钥 key 的情况下,密文是无法被破解的,然后再回到这个教室。你将用 AES 加密后的内容噌噌噌地写在了纸条上,正要传出去的时候你突然想到,TA 没有 key 怎么解密内容呀,或者说,应该怎么把 key 给TA? 如果把 key 也写在纸条上,那么中间人照样可以破解窃听纸条内容。也许在现实环境中你有其他办法可以把 key 通过某种安全的渠道送到 TA 的手里,但是互联网上的实现难度就比较大了,毕竟不管怎样,数据都要经过那些路由。 于是聪明的人类发明了另一种加密算法——非对称加密算法。这种加密算法会生成两个密钥(key1 和 key2)。凡是 key1 加密的数据,key1 自身不能解密,需要 key2 才能解密;凡事 key2 加密的数据,key2 自身不能解密,只有 key1 才能解密。 目前这种算法有很多中,最常用的是 RSA。其基于的数学原理是: 两个大素数的乘积很容易算,但是用这个乘积去算出是哪两个素数相乘就很复杂了。好在以目前的技术,分解大数的素因确实比较困难,尤其是当这个大数足够大的时候(通常使用2的10次方个二进制位那么大),就算是超级计算机,解密也需要非常长的时间。 现在就把这种非对称加密的方法应用在我们教室传纸条的场景里。   你在写纸条内容之前先用 RSA 技术生成了一对密钥 k1 和 k2。 你把 k1 用明文传了出去,路经也许有人会截取,但是没有用,k1 加密的数据需要 k2 才可以破解,而 k2 在你自己手中。 k1 传到了目的人,目的人会去准备一个接下来准备用于对称加密(AES)的传输密钥 key,然后用收到的 k1 把 key 加密,传给你。 你用手上的 k2 解出 key 后,全教室只有你和你的目的人拥有这个对称加密的 key,你们俩就可以尽情聊天不怕窃听啦~ 这里也许你会有问题,为什么不直接用非对称加密来加密信息,而是加密 AES 的 key 呢? 因为非对称加密和解密的平均消耗时间比较长,为了节省时间提高效率,我们通常只是用它来交换密钥,而非直接传输数据。 然而使用非对称加密真的可以防范中间人攻击吗? 虽然看上去很安全,但是实际上却挡不住可恶的中间人攻击。 假设你是 A,你的目的地是 B,现在要途径一个恶意同学M。 中间人的恶意之处在于它会伪装成你的目标。   当你要和 B 完成第一次密钥交换的时候,M 把纸条扣了下来,假装自己是B并伪造了一个 key,然后用你发来的 k1 加密了 key 发还给你。 你以为你和 B 完成了密钥交换,实际上你是和 M 完成了密钥交换。 同事 M 和 B 完成一次密钥交换,让 B 以为和 A 你完成了密钥交换。 现在整体的加密流程变成了A(加密链接1)->M(明文)->B(加密链接2)的情况了,这时候 M 依然可以知道A和B传输的全部消息。 这个时候就是体现 HTTPS 和传纸条的区别了。在教室里,你是和一位与你身份几乎对等的的对象来通信;而在访问网站时,对方往往是一个比较大(或者知名)的服务者,他们有充沛的资源,或许他们可以向你证明他们的合法性。 此时我们需要引入一个非常权威的第三方,一个专门用来认证网站合法性的组织,可以叫做 CA(Certificate Authority)。各个网站服务商可以向 CA 申请证书,使得他们在建立安全连接时可以带上 CA 的签名。而……

(转)有https就够安全了吗?

本文转载自:http://rdcqii.hundsun.com/portal/article/421.html 在平时工作和日常生活中, “https=安全”这样的观点在大多数人的思维中根深蒂固,甚至很多人根本不认为自己会被攻击。那这个观点到底对不对呢?难道真的是 too young too simple, sometimes naïve么? 下面就由笔者来打破人们的这些鬼https的信任吧、(注:本文只讨论前端以及中间人的手段来获取信息,因为https主要是为了防止信息被监听。至于黑站等相关问题,本文暂不讨论,大家如有兴趣请持续关注。)   |第一部分 .  https降级攻击| 降级攻击这项技术历史悠久,但由于操作简单便捷,所以使用率一直很高。这项技术与证书伪造殊途同归,为了让读者能直观感受这一类直接劫持类型的攻击,在此做一个简单的演示。 为了让大家对整个演示过程印象深刻,把BAT的产品拿来做演示对象应该是最有效的。另外,个人觉得搜索引擎应该也是大家用的最多的产品,那不妨就让baidu身先士卒,先上笔者的手术台被我解剖下。   工具:一台受害者的电脑或者虚拟机,另一台装有sslstrip或者一堆高度集成的自带sslstrip功能的中间人工具框架。具体操作请看下面演示 :   在受害者电脑上,这个是正常访问baidu的样子。有小锁图标,有https协议,然后我们看看如果受到了降级攻击之后,受害者的百度:   很明显,安全锁图标消失了,地址栏最前面的https 也不见了。其实,很多攻击者会通过注入前端的js,让用户看起来有https,也有安全锁图标。下面,我们登录下试试: 在攻击者的电脑上: 由上图可见,受害者电脑上输入的用户名和加密后的密码都已经被截取到。幸好密码是加密的,攻击者无法直接获取受害者的用户名和密码。由上可知,即使有了https,对密码加密也是必不可少的步骤。紧急关头,这也能给自己加一道最后的防护。 从另一个角度来说:在我们的演示中,密码已经加了密,所以获取到了也没什么用。而且有的同学说,在地址栏里面这么明显的差别,一般人都能看出是受到攻击了;既然都能看出问题的所在,那也就不存在安全失控这样的隐患。 那接下来,我们继续介绍些更隐蔽、更直接地拿到明文密码的方法。   |第二部分 .  js中间人投毒| 这个名字其实是笔者根据攻击原理形象化的描述。其原理是先开展中间人攻击,然后在用户请求的时候修改返回的数据包,插入有攻击性的js代码。具体步骤请看下面的演示: 工具:一台受害者的电脑,一台攻击者的电脑,为了方便,直接使用mitmf这个中间人攻击框架进行操作。 攻击者电脑开启mitmf,调用jskeylogger模块: 看看日志: 已经开始注入恶意的js了。 受害者继续登录baidu: 密码是“xiaobaitu”,攻击者这边已经收到,如下图所示。 登录凭证窃取计划完成,这个方法比第一个方法要方便得多,直接窃取到明文密码,而且https以及安全图标都还在。 除了中间人攻击的方法,攻击者还可以结合xss,js缓存投毒等一系列攻击手段开展类似的攻击,危害不可谓不大。   |第三部分 浏览器恶意插件| 浏览器恶意插件,和中间人关系不大。因为中国有Great Firewall的存在,我们基本可以不用担心一些恶意插件能窃取我们的资料。但是由于习惯原因,很多人喜欢用chrome,并且大家也都知道chrome可以装很多有用的插件,然而由于Great Firewall的存在,通过正常渠道是访问不到谷歌应用商店的。于是,很多有需要的用户会通过各种方法去下载类似的插件。而对插件原理不甚明了的用户,就很有可能下载到带有恶意js的插件。通常来说,大部分的杀毒软件对带有恶意js的插件是没有特别好的检测方案的。而无论是谷歌还是火狐的官方插件商店,都曾经出现过带有恶意代码的插件,造成了巨大的损失。 背景介绍完了,演示如下: 工具:一台受害者的电脑,一个笔者写的chrome插件,一台可以访问接收的web服务器。 首先,攻击者在经不住诱惑的情况下(如“美女图片”插件,“一元钱抢6s”插件等描述),下载了恶意的插件,然后又登录baidu(为了增强大家印象),现在,我们换一个比较“致命”的应用,支付宝。   密码是“woshidahuilang”。 接收服务器: 由上图可以看出,攻击者端已接收到全部的信息。 该方法的原理就是通过浏览器插件,在点击登录时,将登录框的信息通过ajax表单的形式提交的远程服务器,无声无息间账号密码已经泄露。 下面贴个实现代码: 主要是通过监听表单的submit事件来实现。 Http安全问题其实是当前的一个重点问题,很多人的账户密码都是由以上攻击方式而被窃取的。除上三种方式外之外,攻击方法还有很多,本文就不一一列举了。用户必须要理解一个概念:安全是一个需要积累的过程,就像打补丁。一个补丁刚打上时,暂时可以保证安全。但是时间一久,系统仍有可能出现其他的漏洞。你可能认为某个小补丁不起眼,能一击而破,可是别忘了,补丁也不是独自战斗。因此,各项安全工作一起合力,就能很好的延长防护的纵深以及拉长防护的战线,给予我们以及用户更好的保护。  

(转)九个问题从入门到熟悉HTTPS

本文转载自:http://www.jianshu.com/p/072a657337ae 女朋友也是软件工程专业,因为快要毕业了,最近一边做毕设一边学习编程。前两天她问我 HTTPS 的问题,本来想直接扔一篇网上的教程给她。后来想了一下,那些文章大多直接介绍概念, 对新手不太友好,于是我干脆亲自给她解释一下,顺便整理了一份问答录。 Q1: 什么是 HTTPS? BS: HTTPS 是安全的 HTTP HTTP 协议中的内容都是明文传输,HTTPS 的目的是将这些内容加密,确保信息传输安全。最后一个字母 S 指的是 SSL/TLS 协议,它位于 HTTP 协议与 TCP/IP 协议中间。 Q2: 你说的信息传输安全是什么意思 BS: 信息传输的安全有三个方面: 客户端和服务器直接的通信只有自己能看懂,即使第三方拿到数据也看不懂这些信息的真实含义。 第三方虽然看不懂数据,但可以 XJB 改,因此客户端和服务器必须有能力判断数据是否被修改过。 客户端必须避免中间人攻击,即除了真正的服务器,任何第三方都无法冒充服务器。 很遗憾的是,目前的 HTTP 协议还不满足上述三条要求中的任何一条。 Q3: 这么多要求,一个一个去满足是不是很累? BS: 不累,第三个要求可以不用管 是的,我没开玩笑,你可以暂时别管第三个要求,因为它实际上隶属于第一个需求。我们都知道加密需要密码,密码不是天下掉下来,也得需要双方经过通信才能协商出来。所以一个设计良好的加密机制必然会防止第三者的干扰和伪造。等搞明白了加密的具体原理,我们自然可以检验是否满足:“任何第三者无法冒充服务器”这一要求。 Q4: 那怎么加密信息呢 BS: 使用对称加密技术 对称加密可以理解为对原始数据的可逆变换。比如 Hello 可以变换成 Ifmmp,规则就是每个字母变成它在字母表上的后一个字母,这里的秘钥就是 1,另一方拿到 Ifmmp 就可以还原成原来的信息 Hello 了。 引入对称加密后,HTTPS 的握手流程就会多了两步,用来传递对称加密的秘钥: 客户端: 你好,我需要发起一个 HTTPS 请求 服务器: 好的,你的秘钥是 1。 提到了对称加密,那么自然还有非对称加密。它的思想很简单,计算两个质数的乘积很容易,但反过来分解成两个质数的乘积就很难,要经过极为复杂的运算。非对称加密有两个秘钥,一个是公钥,一个是私钥。公钥加密的内容只有私钥可以解密,私钥加密的内容只有公钥可以解密。一般我们把服务器自己留着,不对外公布的密钥称为私钥,所有人都可以获取的称为公钥。 使用对称加密一般要比非对称加密快得多,对服务器的运算压力也小得多。 Q5: 对称秘钥如何传输 服务器直接返回明文的对称加密密钥是不是不安全。如果有监听者拿到这个密钥,不就知道客户端和服务器后续的通信内容了么? BS: 利用非对称加密 是这样,所以不能明文传递对称秘钥,而且也不能用一个新的对称加密算法来加密原来的对称秘钥,否则新的对称秘钥同样无法传输,这就是鸡生蛋、蛋生鸡的悖论。 这里我们引入非对称加密的方式,非对称加密的特性决定了服务器用私钥加密的内容并不是真正的加密,因为公钥所有人都有,所以服务器的密文能被所有人解析。但私钥只掌握在服务器手上,这就带来了两个巨大的优势: 服务器下发的内容不可能被伪造,因为别人都没有私钥,所以无法加密。强行加密的后果是客户端用公钥无法解开。 任何人用公钥加密的内容都是绝对安全的,因为私钥只有服务器有,也就是只有真正的服务器可以看到被加密的原文。 所以传输对称秘钥的问题就迎刃而解了: 秘钥不是由服务器下发,而是由客户端生成并且主动告诉服务器。 所以当引入非对称加密后,HTTPS 的握手流程依然是两步,不过细节略有变化: 客户端: 你好,我需要发起一个 HTTPS 请求,这是我的 (用公钥加密后的) 秘钥。 服务器: 好的,我知道你的秘钥了,后续就用它传输。 Q5: 那公钥怎么传输 你好像还是没有解决鸡生蛋,蛋生鸡的问题。你说客户端发送请求时要用公钥加密对称秘钥,那公钥怎么传输呢? BS: 对公钥加密就行了。。。 每一个使用 HTTPS 的服务器都必须去专门的证书机构注册一个证书,证书中存储了用权威机构私钥加密的公钥。这样客户端用权威机构的公钥解密就可以了。 现在 HTTPS 协议的握手阶段变成了四步: 客户端: 你好,我要发起一个 HTTPS 请求,请给我公钥 服务器: 好的,这是我的证书,里面有加密后的公钥 客户端: 解密成功以后告诉服务器: 这是我的 (用公钥加密后的) 对称秘钥。 服务器: 好的,我知道你的秘钥了,后续就用它传输。 Q6: 你在逗我么。。。。 那权威机构的公钥又怎么传输? BS: 存在电脑里 这个公钥不用传输,会直接内置在各大操作系统(或者浏览器)的出厂设置里。之所以不把每个服务器的公钥内置在电脑里,一方面是因为服务器太多,存不过来。另一方面操作系统也不信任你,凭什么你说你这个就是百度/淘宝的证书呢? 所以各个公司要先去权威机构认证,申请证书,然后操作系统只会存储权威机构的公钥。因为权威机构数量有限,所以操作系统厂商相对来说容易管理。如果这个权威机构不够权威,XJB 发证书,就会取消他的资格,比如可怜的沃通。。。。 Q7: 怎么知道证书有没有被篡改? 你说服务器第一次会返回证书,也就是加密以后的公钥,那我怎么知道这个证书是可靠的? BS: 将信息 hash 值随着信息一起传递 我们都知道哈希算法的特点,它可以压缩数据,如果从函数角度来看,不管多复杂的数据(定义域可以非常大)经过哈希算法都会得到一个值,而且这个值处在某个特定(远小于定义域的范围)值域内。相同数据的哈希结果一定相同,不相同数据的哈希结果一般不同,不过也有小概率会重复,这叫哈希冲突。 为了确保原始证书没有被篡改,我们可以在传递证书的同时传递证书的哈希值。由于第三者无法解析数据,只能 XJB 改,那么修改后的数据在解密后,就不可能通过哈希。 比如说公钥就是之前的例子 Hello,我们假设哈希算法是获取字符串的最后一个字符,那么 Hello 的哈希值就是 o,所以加密字符串是 Ifmmpp。虽然公钥已知,每个人都可以解密,解密完也可以篡改,但是因为没有私钥, 所以无法正确的加密。所以它再返回给客户端的数据是无效数据,用公钥解析后会得到乱码。即使攻击者通过多次尝试碰巧能够解析,也无法通过哈希校验。 Q8: 这样可以防止第三方冒充服务器么 BS: 也许可以 首先真正的服务器下发的内容,无法被别人篡改。他们有权威机构的公钥,所以可以解密,但是因为没有私钥,所以解密以后的信息无法加密。没有加密或者错误加密的信息被客户端用公钥解密以后,必然无法通过哈希校验。 但是,如果你一开始请求的就不是真的服务器,而是一个攻击者,此时的他完全有机会进行中间人攻击。我们知道第一次握手的时候服务器会下发用于证明自己身份的证书,这个证书会用预设在设备上的公钥来解密。所以要么是经过认证的证书用权威机构的私钥加密,再用权威机构解密,要么是用非权威机构的私钥加密,然后找不到公钥解密。 所以如果不小心安装过非权威机构的根证书,比如黑客提供的恶意证书,这时候设备上就多了一个预设的公钥,那么用恶意私钥加密的证书就能被正常解析出来。所以千万不要随便装根证书,这等于是为那些恶意证书留了一扇门。 当然,凡是都有两面性。我们知道 Charles 可以调试 HTTPS 通信,它的原理就是需要用户安装 Charles 的根证书,然后我们的请求会被代理到 Charles 服务器,它下发的 Charles 证书才能被正确解析。另一方面,Charles 会作为客户端,从真正的服务器哪里拿到正确的 https 证书并用于后续通信。幸好 Charles 不是流氓软件,或者它的私钥一旦泄露,对用户都会造成很大的影响。 我可以举一个例子,证书有多个种类,最贵的叫 EV (Extended Validation),它需要公司营业执照等多个文件才能申请人工审核,好处也很明显,可以在浏览器地址栏左侧准确显示公司名称,比如 Bitbucket 的官网: EV 证书左侧的名字 这是客户端直连时候的正常现象。但如果你用 Charles 代理,客户端拿到的是 Charles……

(转)也许,这样理解HTTPS更容易

本文转载自:http://showme.codes/2017-02-20/understand-https/ 摘要:本文尝试一步步还原HTTPS的设计过程,以理解为什么HTTPS最终会是这副模样。但是这并不代表HTTPS的真实设计过程。在阅读本文时,你可以尝试放下已有的对HTTPS的理解,这样更利于“还原”过程。 我们先不了聊HTTP,HTTPS,我们先从一个聊天软件说起,我们要实现A能发一个hello消息给B: 如果我们要实现这个聊天软件,本文只考虑安全性问题,要实现 A发给B的hello消息包,即使被中间人拦截到了,也无法得知消息的内容 如何做到真正的安全? 这个问题,很多人马上就想到了各种加密算法,什么对称加密、非对称加密、DES、RSA、XX、噼里啪啦~ 而我想说,加密算法只是解决方案,我们首先要做的是理解我们的问题域——什么是安全? 我个人的理解是: A与B通信的内容,有且只有A和B有能力看到通信的真正内容 好,问题域已经定义好了(现实中当然不止这一种定义)。对于解决方案,很容易就想到了对消息进行加密。 题外话,但是只有这一种方法吗?我看未必,说不定在将来会出现一种物质打破当前世界的通信假设,实现真正意义上的保密。 对于A与B这样的简单通信模型,我们很容易做出选择: 这就是对称加密算法,其中图中的密钥S同时扮演加密和解密的角色。具体细节不是本文范畴。 只要这个密钥S不公开给第三者,同时密钥S足够安全,我们就解决了我们一开始所定问题域了。因为世界上有且只有A与B知道如何加密和解密他们之间的消息。 但是,在WWW环境下,我们的Web服务器的通信模型没有这么简单: 如果服务器端对所有的客户端通信都使用同样的对称加密算法,无异于没有加密。那怎么办呢?即能使用对称加密算法,又不公开密钥?请读者思考21秒钟。😜 答案是:Web服务器与每个客户端使用不同的对称加密算法: 如何确定对称加密算法 慢着,另一个问题来了,我们的服务器端怎么告诉客户端该使用哪种对称加密算法? 当然是通过协商。 但是,你协商的过程是没有加密的,还是会被中间人拦截。那我们再对这个协商过程进行对称加密就好了,那你对协商过程加密的加密还是没有加密,怎么办?再加密不就好了……好吧,进行鸡生蛋蛋生鸡的问题了。 如何对协商过程进行加密 新问题来了,如何对协商过程进行加密?密码学领域中,有一种称为“非对称加密”的加密算法,特点是私钥加密后的密文,只要是公钥,都可以解密,但是公钥加密后的密文,只有私钥可以解密。私钥只有一个人有,而公钥可以发给所有的人。 虽然服务器端向A、B……的方向还是不安全的,但是至少A、B向服务器端方向是安全的。 好了,如何协商加密算法的问题,我们解决了:使用非对称加密算法进行对称加密算法协商过程。 这下,你明白为什么HTTPS同时需要对称加密算法和非对称加密算法了吧? 协商什么加密算法 要达到Web服务器针对每个客户端使用不同的对称加密算法,同时,我们也不能让第三者知道这个对称加密算法是什么,怎么办? 使用随机数,就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才确定加密算法。 这下,你明白为什么HTTPS协议握手阶段会有这么多的随机数了吧。 如何得到公钥? 细心的人可能已经注意到了如果使用非对称加密算法,我们的客户端A,B需要一开始就持有公钥,要不没法开展加密行为啊。 这下,我们又遇到新问题了,如何让A、B客户端安全地得到公钥? 我能想到的方案只有这些: 方案1. 服务器端将公钥发送给每一个客户端 方案2. 服务器端将公钥放到一个远程服务器,客户端可以请求得到 我们选择方案1,因为方案2又多了一次请求,还要另外处理公钥的放置问题。 公钥被调包了怎么办?又是一个鸡生蛋蛋生鸡问题? 但是方案1有个问题:如果服务器端发送公钥给客户端时,被中间人调包了,怎么办? 我画了张图方便理解: 显然,让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。 使用第三方机构的公钥解决鸡生蛋蛋生鸡问题 公钥被调包的问题出现,是因为我们的客户端无法分辨返回公钥的人到底是中间人,还是真的服务器。这其实就是密码学中提的身份验证问题。 如果让你来解决,你怎么解决?如果你了解过HTTPS,会知道使用数字证书来解决。但是你想过证书的本质是什么么?请放下你对HTTPS已有的知识,自己尝试找到解决方案。 我是这样解决的。既然服务器需要将公钥传给客户端,这个过程本身是不安全,那么我们为什么不对这个过程本身再加密一次?可是,你是使用对称加密,还是非对称加密?这下好了,我感觉又进了鸡生蛋蛋生鸡问题了。 问题的难点是如果我们选择直接将公钥传递给客户端的方案,我们始终无法解决公钥传递被中间人调包的问题。 所以,我们不能直接将服务器的公钥传递给客户端,而是第三方机构使用它的私钥对我们的公钥进行加密后,再传给客户端。客户端再使用第三方机构的公钥进行解密。 下图就是我们设计的第一版“数字证书”,证书中只有服务器交给第三方机构的公钥,而且这个公钥被第三方机构的私钥加密了: 如果能解密,就说明这个公钥没有被中间人调包。因为如果中间人使用自己的私钥加密后的东西传给客户端,客户端是无法使用第三方的公钥进行解密的。 话到此,我以为解决问题了。但是现实中HTTPS,还有一个数字签名的概念,我没法理解它的设计理由。 原来,我漏掉了一个场景:第三方机构不可能只给你一家公司制作证书,它也可能会给中间人这样有坏心思的公司发放证书。这样的,中间人就有机会对你的证书进行调包,客户端在这种情况下是无法分辨出是接收的是你的证书,还是中间人的。因为不论中间人,还是你的证书,都能使用第三方机构的公钥进行解密。像下面这样: 第三方机构向多家公司颁发证书的情况: 客户端能解密同一家第三机构颁发的所有证书: 最终导致其它持有同一家第三方机构证书的中间人可以进行调包: 数字签名,解决同一机构颁发的不同证书被篡改问题 要解决这个问题,我们首先要想清楚一个问题,辨别同一机构下不同证书的这个职责,我们应该放在哪? 只能放到客户端了。意思是,客户端在拿到证书后,自己就有能力分辨证书是否被篡改了。如何才能有这个能力呢? 我们从现实中找灵感。比如你是HR,你手上拿到候选人的学历证书,证书上写了持证人,颁发机构,颁发时间等等,同时证书上,还写有一个最重要的:证书编号!我们怎么鉴别这张证书是的真伪呢?只要拿着这个证书编号上相关机构去查,如果证书上的持证人与现实的这个候选人一致,同时证书编号也能对应上,那么就说明这个证书是真实的。 我们的客户端能不能采用这个机制呢?像这样: 可是,这个“第三方机构”到底是在哪呢?是一个远端服务?不可能吧?如果是个远端服务,整个交互都会慢了。所以,这个第三方机构的验证功能只能放在客户端的本地了。 客户端本地怎么验证证书呢? 客户端本地怎么验证证书呢?答案是证书本身就已经告诉客户端怎么验证证书的真伪。 也就是证书上写着如何根据证书的内容生成证书编号。客户端拿到证书后根据证书上的方法自己生成一个证书编号,如果生成的证书编号与证书上的证书编号相同,那么说明这个证书是真实的。 同时,为避免证书编号本身又被调包,所以使用第三方的私钥进行加密。 这地方有些抽象,我们来个图帮助理解: 证书的制作如图所示。证书中的“编号生成方法MD5”就是告诉客户端:你使用MD5对证书的内容求值就可以得到一个证书编号。 当客户端拿到证书后,开始对证书中的内容进行验证,如果客户端计算出来的证书编号与证书中的证书编号相同,则验证通过: 但是第三方机构的公钥怎么跑到了客户端的机器中呢?世界上这么多机器。 其实呢,现实中,浏览器和操作系统都会维护一个权威的第三方机构列表(包括它们的公钥)。因为客户端接收到的证书中会写有颁发机构,客户端就根据这个颁发机构的值在本地找相应的公钥。 题外话:如果浏览器和操作系统这道防线被破了,就没办法。想想当年自己装过的非常规XP系统,都害怕。 说到这里,想必大家已经知道上文所说的,证书就是HTTPS中数字证书,证书编号就是数字签名,而第三方机构就是指数字证书签发机构(CA)。 CA如何颁发数字证书给服务器端的? 当我听到这个问题时,我误以为,我们的SERVER需要发网络请求到CA部门的服务器来拿这个证书。😭 到底是我理解能力问题,还是。。 其实,问题应该是CA如何颁发给我们的网站管理员,而我们的管理员又如何将这个数字证书放到我们的服务器上。 我们如何向CA申请呢?每个CA机构都大同小异,我在网上找了一个: 拿到证书后,我们就可以将证书配置到自己的服务器上了。那么如何配置?这是具体细节了,留给大家google了。 也许我们需要整理一下思路 我们通过推算的方式尝试还原HTTPS的设计过程。这样,我们也就明白了为什么HTTPS比HTTP多那么多次的交互,为什么HTTPS的性能会差,以及找到HTTPS的性能优化点。 而上面一大堆工作都是为了让客户端与服务器端安全地协商出一个对称加密算法。这就是HTTPS中的SSL/TLS协议主要干的活。剩下的就是通信时双方使用这个对称加密算法进行加密解密。 以下是一张HTTPS协议的真实交互图(从网上copy的,忘了从哪了,如果侵权麻烦告知): 能不能用一句话总结HTTPS? 答案是不能,因为HTTPS本身实在太复杂。但是我还是尝试使用一段话来总结HTTPS: HTTPS要使客户端与服务器端的通信过程得到安全保证,必须使用的对称加密算法,但是协商对称加密算法的过程,需要使用非对称加密算法来保证安全,然而直接使用非对称加密的过程本身也不安全,会有中间人篡改公钥的可能性,所以客户端与服务器不直接使用公钥,而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法,就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。 好长的一段话。 后记 以上是个人为理解HTTPS而编造出来的自圆其说的看法。顶多只能算是HTTPS的科普文章。如有错误,请指出,万分感谢。 那么,我为什么会觉得以这种方式理解HTTPS会更容易呢?我个人给出的答案是:当你自己为一家人做一次菜时,你就会理解妈妈天天做菜的不易了。 学习资料: HTTPS为什么安全 &分析 HTTPS 连接建立全过程 数字证书的基础知识 理解 HTTPS HTTPS 是如何保证安全的? 图解SSL/TLS协议 The First Few Milliseconds of an HTTPS Connection SSL/TLS原理详解

(转)大型网站的 HTTPS 实践(一)—— HTTPS 协议和原理

本文转载自:http://op.baidu.com/2015/04/https-s01a01/ 1 前言 百度已经于近日上线了全站 HTTPS 的安全搜索,默认会将 HTTP 请求跳转成 HTTPS。本文重点介绍 HTTPS 协议, 并简单介绍部署全站 HTTPS 的意义。   2 HTTPS 协议概述 HTTPS 可以认为是 HTTP + TLS。HTTP 协议大家耳熟能详了,目前大部分 WEB 应用和网站都是使用 HTTP 协议传输的。 TLS 是传输层加密协议,它的前身是 SSL 协议,最早由 netscape 公司于 1995 年发布,1999 年经过 IETF 讨论和规范后,改名为 TLS。如果没有特别说明,SSL 和 TLS 说的都是同一个协议。 HTTP 和 TLS 在协议层的位置以及 TLS 协议的组成如下图: TLS 协议主要有五部分:应用数据层协议,握手协议,报警协议,加密消息确认协议,心跳协议。 TLS 协议本身又是由 record 协议传输的,record 协议的格式如上图最右所示。   目前常用的 HTTP 协议是 HTTP1.1,常用的 TLS 协议版本有如下几个:TLS1.2, TLS1.1, TLS1.0 和 SSL3.0。其中 SSL3.0 由于 POODLE 攻击已经被证明不安全,但统计发现依然有不到 1% 的浏览器使用 SSL3.0。TLS1.0 也存在部分安全漏洞,比如 RC4 和 BEAST 攻击。 TLS1.2 和 TLS1.1 暂时没有已知的安全漏洞,比较安全,同时有大量扩展提升速度和性能,推荐大家使用。 需要关注一点的就是 TLS1.3 将会是 TLS 协议一个非常重大的改革。不管是安全性还是用户访问速度都会有质的提升。不过目前没有明确的发布时间。 同时 HTTP2 也已经正式定稿,这个由 SPDY 协议演化而来的协议相比 HTTP1.1 又是一个非常重大的变动,能够明显提升应用层数据的传输效率。   3 HTTPS 功能介绍 百度使用 HTTPS 协议主要是为了保护用户隐私,防止流量劫持。 HTTP 本身是明文传输的,没有经过任何安全处理。例如用户在百度搜索了一个关键字,比如“苹果手机”,中间者完全能够查看到这个信息,并且有可能打电话过来骚扰用户。也有一些用户投诉使用百度时,发现首页或者结果页面浮了一个很长很大的广告,这也肯定是中间者往页面插的广告内容。如果劫持技术比较低劣的话,用户甚至无法访问百度。 这里提到的中间者主要指一些网络节点,是用户数据在浏览器和百度服务器中间传输必须要经过的节点。比如 WIFI 热点,路由器,防火墙,反向代理,缓存服务器等。 在 HTTP 协议下,中间者可以随意嗅探用户搜索内容,窃取隐私甚至篡改网页。不过 HTTPS 是这些劫持行为的克星,能够完全有效地防御。 总体来说,HTTPS 协议提供了三个强大的功能来对抗上述的劫持行为: 1,  内容加密。浏览器到百度服务器的内容都是以加密形式传输,中间者无法直接查看原始内容。 2,  身份认证。保证用户访问的是百度服务,即使被 DNS 劫持到了第三方站点,也会提醒用户没有访问百度服务,有可能被劫持 3,  数据完整性。防止内容被第三方冒充或者篡改。 那 HTTPS 是如何做到上述三点的呢?下面从原理角度介绍一下。   4 HTTPS 原理介绍 4.1 内容加密 加密算法一般分为两种,对称加密和非对称加密。所谓对称加密(也叫密钥加密)就是指加密和解密使用的是相同的密钥。而非对称加密(也叫公钥加密)就是指加密和解密使用了不同的密钥。 对称内容加密强度非常高,一般破解不了。但存在一个很大的问题就是无法安全地生成和保管密钥。假如客户端软件和服务器之间每次会话都使用固定的,相同的密钥加密和解密,肯定存在很大的安全隐患。如果有人从客户端端获取到了对称密钥,整个内容就不存在安全性了,而且管理海量的客户端密钥也是一件很复杂的事情。 非对称加密主要用于密钥交换(也叫密钥协商),能够很好地解决这个问题。浏览器和服务器每次新建会话时都使用非对称密钥交换算法协商出对称密钥,使用这些对称密钥完成应用数据的加解密和验证,整个会话过程中的密钥只在内存中生成和保存,而且每个会话的对称密钥都不相同(除非会话复用),中间者无法窃取。 非对称密钥交换很安全,但同时也是 HTTPS 性能和速度严重降低的“罪魁祸首”。想要知道 HTTPS 为什么影响速度,为什么消耗资源,就一定要理解非对称密钥交换的整个过程。 下面重点介绍一下非对称密钥交换的数学原理及在 TLS 握手过程中的应用。 4.1.1 非对称密钥交换 在非对称密钥交换算法出现以前,对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题,使得对称密钥的生成和使用更加安全。 密钥交换算法本身非常复杂,密钥交换过程涉及到随机数生成,模指数运算,空白补齐,加密,签名等操作。 常见的密钥交换算法有 RSA,ECDHE,DH,DHE 等算法。它们的特性如下:  RSA:算法实现简单,诞生于 1977 年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数(目前常用的是 2048 位)来保证安全强度,很消耗 CPU 运算资源。RSA 是目前唯一一个既能用于密钥交换又能用于证书签名的算法。 DH:diffie-hellman 密钥交换算法,诞生时间比较早(1977 年),但是 1999 年才公开。缺点是比较消耗 CPU 性能。 ECDHE:使用椭圆曲线(ECC)的 DH 算法,优点是能用较小的素数(256 位)实现 RSA 相同的安全等级。缺点是算法实现复杂,用于密钥交换的历史不长,没有经过长时间的安全攻击测试。……

(转)扫盲 HTTPS 和 SSL/TLS 协议[1]:背景知识、协议的需求、设计的难点

本文转载自:https://program-think.blogspot.com/2014/11/https-ssl-tls-1.html 文章目录 ★相关背景知识 ★HTTPS 协议的需求是啥? ★设计 HTTPS 协议的主要难点 ★结尾 ★相关背景知识 要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识。 1. 大致了解几个基本术语(HTTPS、SSL、TLS)的含义 2. 大致了解 HTTP 和 TCP 的关系(尤其是“短连接”VS“长连接”) 3. 大致了解加密算法的概念(尤其是“对称加密与非对称加密”的区别) 4. 大致了解 CA 证书的用途 考虑到很多技术菜鸟可能不了解上述背景,俺先用最简短的文字描述一下。如果你自认为不是菜鸟,请略过本章节,直接去看“HTTPS 协议的需求”。 ◇先澄清几个术语——HTTPS、SSL、TLS 1. “HTTP”是干嘛用滴? 首先,HTTP 是一个网络协议,是专门用来帮你传输 Web 内容滴。关于这个协议,就算你不了解,至少也听说过吧?比如你访问俺的博客的主页,浏览器地址栏会出现如下的网址 http://program-think.blogspot.com/ 俺加了粗体的部分就是指 HTTP 协议。大部分网站都是通过 HTTP 协议来传输 Web 页面、以及 Web 页面上包含的各种东东(图片、CSS 样式、JS 脚本)。 2. “SSL/TLS”是干嘛用滴? SSL 是洋文“Secure Sockets Layer”的缩写,中文叫做“安全套接层”。它是在上世纪90年代中期,由网景公司设计的。(顺便插一句,网景公司不光发明了 SSL,还发明了很多 Web 的基础设施——比如“CSS 样式表”和“JS 脚本”) 为啥要发明 SSL 这个协议捏?因为原先互联网上使用的 HTTP 协议是明文的,存在很多缺点——比如传输内容会被偷窥(嗅探)和篡改。发明 SSL 协议,就是为了解决这些问题。 到了1999年,SSL 因为应用广泛,已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS(是“Transport Layer Security”的缩写),中文叫做“传输层安全协议”。 很多相关的文章都把这两者并列称呼(SSL/TLS),因为这两者可以视作同一个东西的不同阶段。 3. “HTTPS”是啥意思? 解释完 HTTP 和 SSL/TLS,现在就可以来解释 HTTPS 啦。咱们通常所说的 HTTPS 协议,说白了就是“HTTP 协议”和“SSL/TLS 协议”的组合。你可以把 HTTPS 大致理解为——“HTTP over SSL”或“HTTP over TLS”(反正 SSL 和 TLS 差不多)。 ◇再来说说 HTTP 协议的特点 作为背景知识介绍,还需要再稍微谈一下 HTTP 协议本身的特点。HTTP 本身有很多特点,考虑到篇幅有限,俺只谈那些和 HTTPS 相关的特点。 1. HTTP 的版本和历史 如今咱们用的 HTTP 协议,版本号是 1.1(也就是 HTTP 1.1)。这个 1.1 版本是1995年底开始起草的(技术文档是 RFC2068),并在1999年正式发布(技术文档是 RFC2616)。 在 1.1 之前,还有曾经出现过两个版本“0.9 和 1.0”,其中的 HTTP 0.9 【没有】被广泛使用,而 HTTP 1.0 被广泛使用过。 另外,据说明年(2015)IETF 就要发布 HTTP 2.0 的标准了。俺拭目以待。 2. HTTP 和 TCP 之间的关系 简单地说,TCP 协议是 HTTP 协议的基石——HTTP 协议需要依靠 TCP 协议来传输数据。 在网络分层模型中,TCP 被称为“传输层协议”,而 HTTP 被称为“应用层协议”。有很多常见的应用层协议是以 TCP 为基础的,比如“FTP、SMTP、POP、IMAP”等。 TCP 被称为“面向连接”的传输层协议。关于它的具体细节,俺就不展开了(否则篇幅又失控了)。你只需知道:传输层主要有两个协议,分别是 TCP 和 UDP。TCP 比 UDP 更可靠。你可以把 TCP 协议想象成某个水管,发送端这头进水,接收端那头就出水。并且 TCP 协议能够确保,先发送的数据先到达(与之相反,UDP 不保证这点)。 3. HTTP 协议如何使用 TCP……