曾经,我非常羡慕那些人见人爱的人,我也想要变成那样,可是后来我才明白人见人爱也是需要天赋的,后来我开始默默努力,我想,就算我不能让每个人都喜欢我,至少因为我做的努力能得到别人的尊重。

更安全的https && https的问题

视频推荐:https的性能优化

推荐文章:腾讯https性能优化实践

更安全的https(内容加密、身份认证、数据完整性)

  https实际上就是在http和tcp之间添加了ssl层或者是TLs层,这两层一般是指相同的层,主要做的工作就是内容加密、身份认证、数据完整性校验。

TLS 的前身是 SSL(Secure Sockets Layer,安全套接字层),由网景公司开发,后来被 IETF 标准化并改名。通常没有特别说明时,SSL 和 TLS 指的是同一个协议,不做严格区分。  

 

故事助记

1、两人聊天,在中国的张大胖,在美国的bill,他们无话不谈。。

 

2、 突然有一天,他们突然意识到有一种被偷窥的感觉 --- 他们的聊天是否被人一直在观察,关键是他们还谈了很多的秘密啊! 以后如果想要说点其他重要的事情,这可不行! 

  于是bill建议能否在大胖发送信息的时候先用一种加密算法加密发送的内容,然后bill在接受到信息之后再使用同样的算法来解密,这样,信息在网络中就是以加密的形式传输,不就不会被偷窥了吗! 如下:

  

注意:这种加密和解密使用同一种算法的方式为对称加密

但是,在秘钥被传输的过程中也被人给偷窥了呢? 这样,你即使加密了,偷窥的人也可以通过偷偷得到的秘钥进行解密啊,这不是功亏一篑了吗? 

 

3、 大胖很不甘心,他觉得不能就这么放弃,于是在网上找到了一种叫做RSA非对称加密算法(RSA是三个人发明的,即三个人的首字母组成RSA),这种算法要求两个钥匙,一个公钥,一个私钥。

私钥只有一把,非常重要;公钥可以有很多,谁都可以使用。但是私钥加密的内容只有公钥可以解密,公钥加密的内容也只有私钥可以解密。

这样,问题就很好解决了,即bill将公钥通过网络发送给大胖,然后大胖拿到这个对文件进行加密发给bill,而只有bill具有私钥,所以就可以使信息保密啦! 

 

 

 

同样的,如果bill给大胖发送信息,通过大胖的公钥进行加密,然后大胖收到信息之后,通过自己的私钥来解密就可以了。

这种加密和解密方式不同的加密方法为非对称加密

 

4、经过几次尝试之后,果然可以。但是大胖发现,这种非对称加密要比对称加密慢了百倍,这是他所不能容忍的,于是他又相出了这么个对称加密和非对称加密(RSA)结合的方法:

 即首先大胖把通过RSA加密方法把对称加密的钥匙发送给bill,这样,bill和大胖在之后的聊天过程中不就可以使用速度更快的对称加密了吗!  好方法!

 

5、 中间人攻击

  后来啊,他们发现这种方法还是存在漏洞的,如当bill给大胖发送公钥的时候,这个公钥被中间人给截住了,然后把中间人的公钥发送给了大胖,那么大胖就会通过这个中间人公钥把对称密钥发送给bill,中间人截取到这个密钥之后就会,使用自己的私钥就会看到里面的信息,接着通过之前截取的公钥再把这个对称密钥发送给bill,后面他们就会通过这个对称密钥聊天,而中间人就可以完全看到他们的信息了,如下:

所以这里的问题是,如何确保大胖接收到的公钥是bill的,而不是中间人的!

 

 

 

6、但是大胖很快就又想到了办法,就是找一个第三方来给网络上的人办法一个证书,证明存在这个人,并且这个证书上还要有这个人的公钥,这样,大胖收到第三方的这个证书之后,就可以确认公钥就是bill的了! 但是如果证书也是被修改了呢?  天无绝人之路,很快,大胖就意识到了使用数字签名!  Bill可以把他的公钥和个人信息用一个Hash算法生成一个消息摘要, 这个Hash算法有个极好的特性,只要输入数据有一点点变化,那生成的消息摘要就会有巨变,这样就可以防止别人修改原始内容。

 

 可是作为攻击者的中间人笑了: “虽然我没办法改公钥,但是我可以把整个原始信息都替换了, 生成一个新的消息摘要, 你不还是辨别不出来?

 张大胖说你别得意的太早 , 我们会让有公信力的认证中心(简称CA)用它的私钥对消息摘要加密,形成签名:

这还不算, 还把原始信息和数据签名合并, 形成一个全新的东西,叫做“数字证书”

张大胖接着说:当Bill把他的证书发给我的时候, 我就用同样的Hash 算法, 再次生成消息摘要,然后用CA的公钥对数字签名解密, 得到CA创建的消息摘要, 两者一比,就知道有没有人篡改了!

 

如果没人篡改, 我就可以安全的拿到Bill的公钥喽,有了公钥, 后序的加密工作就可以开始了。

虽然很费劲, 但是为了防范你们这些偷窥者,实在是没办法啊。

 

 

 

 但是中间人还要伪造CA呢? 大胖认为,必须要信任CA,否则就没法玩下去了。

(注:这些CA本身也有证书来证明自己的身份,并且CA的信用是像树一样分级的,高层的CA给底层的CA做信用背书,而操作系统/浏览器中会内置一些顶层的CA的证书,相当于你自动信任了他们。 这些顶层的CA证书一定得安全地放入操作系统/浏览器当中,否则世界大乱。)

 


较为专业的发展历程:

  • 对称加密时代:最开始A向B发送密钥,然后之后的通信都是使用密钥加密,使用相同的密钥解密。
  • 非对称加密时代: 若最开始的时候,密钥被窃取,那么后面的过程都是会被窃取的。
  • 对称加密和非对称加密混合:非对称加密的速度很慢,所以需要一定的时间。 所以,可以先用非对称加密(安全的)发送过去用于对称加密的私钥,然后拿着私钥就可以进行对称加密而言的工作了。
  • 对称加密和非对称加密混合并使用hash值:非对称加密也是存在问题的,即开始发送公钥的时候,中间人就有可能拿到这个公钥,然后发送自己的公钥。所以,可以将想要发送的公钥以及个人信息通过MD5或者是SHA1生成hash值(hash值的特点是不可逆性以及唯一性),即使有很小的改变,那么hash值就会发生巨大的改变。 
  • 对称加密和非对称加密混合并使用hash值并使用数字签名生成数字证书: 之前使用的hash值也是会存在问题的,因为虽然,如果中间人把公钥换成了自己的,这时hash值发生了变化,另一端不再信任;但是,中间人不仅可以替换公钥,还可以生成一个全新的hash然后发送啊,所以,这时单纯的hash也是没有用的了。可以可以使用CA证书,即给每一个站点颁发一个信任证书,然后发送的时候把hash值通过CA私钥进行加密(只有受信任的站点才有CA,只有收信人的站点才有这个CA的私钥),然后把加密后的hash值称之为数字签名,接着把数字签名和之前的公钥以及个人信息组成数字证书一起发送(注意:这个过程只是开始进行通信的时候才会发生的,不可能每次链接都这么麻烦),然后接收端收到之后,会比对本地的CA证书,判断这个证书是否是受信任的,如果不是,就警告,如果是,就拿到这个证书中的公钥将自己的对称密钥发送过去,当对方通过私钥对之进行解密之后就拿到了这个对称密钥,就可以使用对称密钥进行通信了。 如下所示:

 

 

7、 

终于可以介绍https了,前面已经介绍了https的原理, 你把张大胖替换成浏览器, 把Bill 替换成某个网站就行了。

一个简化的(例如下图没有包含Pre-Master Secret)https流程图是这样的, 如果你理解了前面的原理,这张图就变得非常简单:

 

 

 

 那么这里就很好理解了,客户端发送一个请求希望和服务器建立安全地链接,然后为了建立链接服务器发送了一个数字证书,证明身份并发送过了一个公钥,浏览器端认真身份之后就使用这个公钥加密对称密钥发送,然后服务器就会通过自己的私钥得到对称密钥,这样,双方都知道了对称密钥,就可以用它来进行加密通信了!强!

 

8、那么如何在浏览器端查看证书呢? 

  一般,https协议都是使用的这种证书的方式。比如百度,https://www.baidu.com,我们可以看到如下:

      

  即这里的Secure就是通信是加密了的,然后如果我们希望查看服务器的证书,可以打开开发者工具的security选项,如下:

 

       

  然后,我们可以通过 View Certificate 来查看百度的证书,如左边所示。

  即证书的目的如下:

  • 确保远程服务器的身份。
  • 向远程服务器证明你的身份。 
  • 。。。。

  即这个证书是由 GlobalSign Organization Validation CA  - SHA256 来办法的,之前的介绍中,我们说通过hash,这里就是通过SHA256的算法。证书的有效期是 2017年的6月29日到2018年的4月25日,即十个月的时间。 但是证书的时间不是固定的,我们可以看到360搜索的证书时间长达3年。 所以这个是得多交钱吧。。。

 

 

 https详解

http缺点(三个)

  1.通信使用明文(不加密),内容可能被窃听.(抓包工具可以获取请求和响应内容)

  2.不验证通讯方的身份,可能遭遇伪装.(任何人都能发送请求,不管对方是谁都会返回响应).

  3.无法证明报文的完整性,可能会遭篡改.(没有办法确认发出的请求/响应和接收到的请求/响应前后一致)

 

  HTTP+加密+认证+完整性保护 = HTTPS. (可以认为https比http多了三个功能)

  

  HTTPS的英文全称是: HyperText Transfer Protocol over Secure Socket Layer, 即基于安全套阶层(SSL)的超文本传输协议。 

  近年,google、baidu、facebook等大厂都开始大力推行https,国内外的很多互联网公司全站启动了https,这也是未来互联网的发展趋势。 

  为了鼓励全球网站的https实现,一些互联网公司都提出了自己的要求:

  • Google调整了搜索引擎算法,让使用了https的网站在搜索中排名靠前。
  • 从2017年开始,chrome浏览器已经把采用http协议的网站标记为不安全网站,
  • (提示网站不安全,不能输入一些密码、银行卡等敏感信息)
  • 苹果要求2017年的app store中的所有应用必须使用https加密链接,而微信小程序也要求必须使用https协议。
  • 新一代的http/2协议的支持需要以https为基础。

  

       https协议可以理解为 http + SSL/TLS, 即http下加入ssl层,https的安全基础就是ssl,因此加密的详细内容就需要上来了,如下:

    

 

  所以,ssl层是在tcp层以上,在http层以下的,这样就构成了https。 

 

 SSL(Secure Socket Layer,安全套接字层):1994年为 Netscape 所研发,SSL 协议位于 TCP/IP 协议与各种应用层协议之间,为数据通讯提供安全支持。

 

 TLS(Transport Layer Security,传输层安全):其前身是 SSL,它最初的几个版本(SSL 1.0、SSL 2.0、SSL 3.0)由网景公司开发,1999年从 3.1 开始被 IETF 标准化并改名,发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞,已经很少被使用到。TLS 1.3 改动会比较大,目前还在草案阶段,目前使用最广泛的是TLS 1.1、TLS 1.2。

 

1、对称加密

有流式、分组两种,加密和解密都是使用的同一个密钥

例如:DES、AES-GCM、ChaCha20-Poly1305等

 

2、非对称加密

加密使用的密钥和解密使用的密钥是不相同的,分别称为:公钥、私钥,公钥和算法都是公开的,私钥是保密的。非对称加密算法性能较低,但是安全性超强,由于其加密特性,非对称加密算法能加密的数据长度也是有限的。

例如:RSA、DSA、ECDSA、 DH、ECDHE

 

3、哈希算法

将任意长度的信息转换为较短的固定长度的值,通常其长度要比信息小得多,且算法不可逆。

例如:MD5、SHA-1、SHA-2、SHA-256 等

 

4、数字签名

签名就是在信息的后面再加上一段内容(信息经过hash后的值),可以证明信息没有被修改过。hash值一般都会加密后(也就是签名)再和信息一起发送,以保证这个hash值不被修改。

 

 

 

 

 

 

https的问题

 

https最大的特点就是很慢,一般都是要慢几百毫秒以上,在移动端大概会慢500ms以上。但是通过优化,实际上可以做到

第二点就是贵。

第三点就是https是需要消耗服务器成本,因为加密的过程是需要计算的。

 

缺点一:延时

  https确实是更加安全了,但是https也是存在问题的,一个很大的问题就是https非常慢! 为什么呢? 因为正常的http建立链接的时候,通过三次握手就可以建立链接了,而https除了三次握手的部分,还需要SLL握手,也就是:

http耗时 = TCP握手

https耗时 = TCP握手 + SSL握手

  所以,https肯定是比http耗时的,这个耗时就是SSL延迟

  

  下面,我们通过curl命令来进行测试:

  这里,我们通过curl命令就可以输出了,-w参数为了定义输出格式,使用%{}即为变量形式,time_connect为TCP握手,time_appconnect为SSL握手, 通过测试,发现, SSL握手的时间约为TCP握手时间的3倍。  在尝试连接 https://www.baidu.com 以及 https://www.zhihu.com 的时候,最终得到的大概是TCP握手时间的两倍左右,当然具体数字取决于当前的状态等。

  所以,如果是对安全性要求不高的场合,为了提高网页性能,建议不要采用保密强度很高的数字证书。一般场合下,1024位的证书已经足够了,2048位和4096位的证书将进一步延长SSL握手的耗时。 

  

 

 缺点二:贵

  因为使用https,你就需要买SSL证书,买证书是需要花钱的啊!

  另外,在服务器端要进行大量的加密和解密的工作,所以成本增加是必然的。 

 

 

https的主要的计算环节

    https主要的计算环节包括四个部分:

  1. 红色环节是非对称密钥交换,通过客户端和服务端不一致的信息协商出对称的密钥;

  2. 蓝色环节是证书校验,对证书的签名进行校验,确认网站的身份;

  3. 深绿色环节是对称加解密,通过非对称密钥交换协商出对称密钥来进行加解密;

  4. 浅绿色环节是完整性校验,不仅要加密还要防止内容被篡改,所以要进行自身的完整性校验。

 

  知道这些主要的计算环节之后,每一个计算环节对计算性能的影响分别是多少以及如何分析?这里和大家分享我们计算性能的分析维度,主要分为三部分:算法、协议和系统。

  1. 算法,所谓的算法其实是HTTPS所用到密码学里最基本的算法,包括对称加密、非对称密钥交换、签名算法、一致性校验算法等,对应的分析手段也很简单:openssl speed;

  2. 协议,因为不同的协议版本和消息所对应使用的算法是不一样的,虽然算法的性能很确定,但是和协议关联起来它就不确定了。由于性能和协议相关,我们重点分析的是协议里完全握手的阶段,我们会对完全握手的每个消息和每个函数进行时间的分析;

  3. 系统,比如我们使用Nginx和OpenSSL,我们会对它进行压力测试,然后在高并发压力环境下对热点事件进行分析和优化。

  

 

 

 

 

 

 

 

 

posted @ 2017-08-18 21:12  Wayne-Zhu  阅读(378)  评论(0编辑  收藏

一分耕耘,一分收获。