网站制作百科

联系我们

相关推荐

网站制作百科

首页 > 新闻动态 > 网站制作百科 > >

为什么超过百分之六十的网站不支持HTTPS?

发布日期:2017-02-20来源:www.cecom.cn

        HTTPS很安全,很古老也很成熟,为什么一直到今天我们还有66%的网站不支持HTTPS呢?原因有两点:
       

网站优化

1、慢,HTTPS未经任何优化的情况下要比HTTP慢几百毫秒以上,特别在移动端可能要慢500毫秒以上,关于HTTPS慢和如何优化已经是一个非常系统和复杂的话题,由于时间的关系,本次分享就不做介绍了。但有一点可以肯定的是,HTTPS的访问速度在经过优化之后是不会比HTTP慢;

        2、贵,特别在计算性能和服务器成本方面。HTTPS为什么会增加服务器的成本?相信大家也都清楚HTTPS要额外计算,要频繁地做加密和解密操作,几乎每一个字节都需要做加解密,这就产生了服务器成本,但也有两点大家可能并不清楚:

        大家也很清楚HTTPS是大势所趋,Google、Facebook和国内诸多互联网公司也已经支持HTTPS,然而这里有两点大家需要注意:

        一、iOS10的ATS政策(App Transport Security)要求2017年1月1日后所有在iOS App Store上架的App都需要支持HTTPS,否则无法上架;

        二、Google的Chrome浏览器54版本已经将HTTP的域名输入框前增加“!”的提示,如下图,所有的HTTP站点都会有这个标识。同样在2017年1月1日后开始,Chrome浏览器会在用户点击“!”的提示符后将该网站不安全的信息显示出来,只要涉及到登录和搜集用户数据的页面,只要是HTTP的都会标注不安全,相信这也会加速HTTPS的推进。

 

    HTTPS主要的计算环节

        首先看HTTPS主要的计算环节,下图是一个协议交互的简要介绍图,它的四种颜色分别代表4种不同的主要计算环节:

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

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

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

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

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

网站建设

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

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

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

         最后我们看热点事件的分析,它也比较简单,我们对系统进行压力测试,用perf record对事件进行记录,然后使用flame graph将它们可视化出来,最后看到一些相关数据和结果。

        1、总结以上计算性能分析:

        2、完全握手的性能不到普通HTTP性能的10%,如果说HTTP的性能是QPS 1万,HTTPS可能只有几百;

        3、为什么会这么低呢?主要是RSA算法,它对性能的影响占了75%左右;

        4、ECC椭圆曲线如果使用最常用的ECDHE算法,这部分约占整体计算量的7%;

        5、对称加解密和MAC计算,它们对性能影响比较小,是微秒级别的。

       

东莞网站建设

有了这些分析结论,如何优化呢?我们总结了三个步骤:

        首先第一步也是最简单的一个优化策略,就是减少完全握手的发生,因为完全握手它非常消耗时间;

        对于不能减少的完全握手,对于必须要发生的完全握手,对于需要直接消耗CPU进行的握手,我们使用代理计算;

        对称加密的优化评论;

        简化握手的原理以及实现
        我们首先来看完全握手和简化握手,这是TLS层的概念,我简单说下简化握手的两个好处:
        首先简化握手相比完全握手要少一个RTT(网络交互),从完全握手大家可以看出来,它需要两个握手交互才能进行第三步应用层的传输,而简化握手只需要一个RTT就能进行应用层的数据传输;
完全握手有ServerKeyExchange的消息(红色框部分),这个消息之前提过需要2.4毫秒,另外完全握手有Certificate证书的消息,而简化握手并不需要。这也就是简化握手第二个好处,它减少了计算量,它不需要CPU消耗太多时间。

        既然简化握手这么好,我们如何实现?首先看协议层如何支持。TLS协议层有两个策略可以实现,第一个是Session ID,Session ID由服务器生成并返回给客户端,客户端再次发起SSL握手时会携带上Session ID,服务端拿到后会从自己的内存查找,如果找到便意味着客户端之前已经发生过完全握手,是可以信任的,然后可以直接进行简化握手。

        第二个策略是Session Ticket,同样它也是客户端发起握手时会携带上的扩展,服务器拿到Session Ticket后会对它进行解密,如果解密成功了就意味着它是值得信任的,从而可以进行简化握手,直接传输应用层数据。

        工程实现上会有什么问题呢?现在最常用的Nginx+OpenSSL有两个局限:

        Nginx只支持单机多进程间共享的Session Cache,假如我们所有接入用的是一台服务器、一台Nginx的话,那ID生成和查找都在一起,肯定是可以命中的,但是我们大部分特别是流量比较大的接入环境都是多台机器接入。比如我们同一个TGW或者说LVS下面有多台Nginx,那么第一台Nginx产生的ID返回给用户,用户可能隔了一个小时候之后再发起SSL握手,它携带上的Session ID肯定会随机地落到某一台Nginx上面(比如落在第三台Nginx上),这样肯定无法查找到之前的Session ID,无法进行简化握手,这是第一个局限,即命中率会比较低;

        OpenSSL提供了一个Session Cache的callback可以回调,但是这个回调函数是同步的,而Nginx是完全异步事件驱动的框架,如果Nginx调用这个callback进行网络查找,假如这个网络查找需要1毫秒,这意味着整体性能不会超过一千次。

        我们如何进行改进?我们看第一个问题(Session Cache)的两个改进方案:

东莞网站优化

        1、 IP Hash,这是最简单的根据IP做Hash的负载均衡策略,相信大家对此都很清楚,这方案的好处是可以保证相同的IP用户永远都在同一台Nginx上面,Session Cache的命中率会提升,但是它有两个缺点:
它容易导致热点,我们有很多Net网关出口IP用户的访问量非常大,也就是说有一些IP请求非常大导致某一台机器负载不均衡;用户IP可能会经常变化,特别在移动端上,在Wi-Fi和4G环境下切换导致的IP变化同样会使Session Cache的命中率降低。

        2、分布式缓存(分布式Session Cache),这是更优的方案,假如用户开始发起握手,我们第一台Nginx生成ID会写入到一个全局的比如redis缓存里,然后返回给用户。用户下一次发起握手的时候,假如他落到第三台Nginx上面,由于我们都是全局的Session Cache查找,这命中率一下就提升上来了。我们实现了这个方案,但暂时还没有开源,在这里可以给大家推荐两个开源方案,大家有兴趣可以了解一下。OpenResty,它提供了SSL Cache全局查找的指令;BoringSSL,这是Google fork OpenSSL的版本,它也在SSL层面上实现了异步的Session Cache查找。

        接下来我们看Session Ticket,由于Session Cache有个缺点是必须在服务端做缓存,会浪费很大内存,而Session Ticket有个好处是它不需要服务端做缓存,但同样它也有个缺点:默认情况下比如三台Nginx各自的Session Ticket加解密密钥是不同(这里的密钥是指Session Ticket的对称加解密的密钥而不是指证书对应的私钥)。举个例子,比如第一台Nginx的Session Ticket用密钥加密返回给用户,用户下一次再访问落到第三台机器,你用第一台机器加密产生的密钥用第三台的密钥去解密肯定会失败。这个问题很好解决,我们将所有的Nginx机器配置成同一个加解密的密钥就可以了,这样也能实现简化握手。

        我们看一下第三个方案:Self Session Ticket。Session ID和Session Cache都有一个共同点:Session基于内存,如果我们的App、浏览器或操作系统如果第一次启动或重启(或者浏览器的Tab关闭后又打开)都有可能导致Session ID和Session Ticket丢失,出于安全角度考虑,这情况下就必须要发起完全握手,怎么解决呢?如果这个App是我们完全自主、独立自主开发,我们可以实现Self Session Ticket,我们将Ticket存储在硬盘里面,而不是在内存里。这显然会带来一定的安全风险,但是我们会做一些限制:Ticket存储在App的私有路径里,对非Root的手机是很难读取到私有路径的数据;我们可以选择对一些安全系数要求不是很高的业务开启这个功能;这个密钥开关我们做到可以随时控制。综上,即使这方案出现最危险的情况,其实是和HTTP方案是一样的,它不会比HTTP方案安全性要差。

        更多资讯请关注华商更多资讯,我们华商网络是一家专业致力于为中国企业提供全方位、多层面的信息化服务的运营商。以40余家分公司为依托,在全国主要城市和二、三级城市建立了庞大的专业服务网络,为客户提供便捷、优质的本地化服务。主要义务有:网站设计,网站优化,东莞网站建设,东莞网站推广,东莞网站制作,东莞网络服务,东莞SEO优化等等

案例推荐: