如何全方位打造安全高效的HTTPS站点(一)
如何全方位打造安全高效的HTTPS站点(一)
本文作者--探花郎
又是一年双十一,如果你是卖家,你是否已经万事俱备呢?如果你是买家,你是否已经擦亮眼睛。不会被钓鱼网站或链接欺骗呢?今天我们就来聊一聊Web站点。和大家分享一下如何全方位的来打造一个安全而又高效的Web站点。如果你只是非专业人员,那么这篇文章对你来说就更重要了。了解了这些知识后,你也会变成火眼金睛,一眼看穿各种钓鱼网站,不论你遇到的是拼夕夕,还是砍多多。特别是单身的小哥哥更是一定要仔细的看,仔细的品。下次如果你微信里心仪已久的小姐姐再让你帮忙拼团、砍价的时候。你就通过自己的分析和判断,帮她辨别真伪。不仅能展现你的博学多才,还能促进你们的交流。如此一来,爱情不就来了嘛!
一、密钥的安全性
闲话少说,言归正传。我们先从秘钥来开始我们今天的内容。密钥和证书是整个TLS加密的基石。只有拥有健壮的秘钥才能防止攻击者进行模拟攻击。目前来说对于秘钥的使用,RSA密钥普遍使用2048位,而ECC秘钥普遍使用256位。行业里也默认采用2048位RSA秘钥和256位的秘钥是安全的。RSA加密算法和ECC加密算法都属于非对称加密算法。理解起来比较可能比较抽象,我们来进行一个简单对比。比如:2048位的RSA算法加密其安全性相当于112位的对称密钥加密。加密位数越高,其安全性越高,这是肯定的。与此同时,位数越高,其运算速度就会越慢。现在ECC算法的使用也逐渐兴起,其算法速度比RSA的更快,效率更高。国密局推出的SM2算法也是属于ECC算法,属于众多椭圆曲线中的一条国产的椭圆曲线。为了方便大家更好的对比,下面列举一个算法安全性对比简图。
使用安全性高的密钥是最基本的要求。有了安全的密钥,如何保证你的密钥安全使用也是非常重要的一环。在你申请SSL证书的时候,CA机构都会要你递交证书请求文件CSR( Certificate Signing Request ),这就是为了确保密钥文件(私钥)是你自己产生的。在我们使用过程中可以通过给私钥配置密码保护。这样在私钥备份传输中也能进一步提高其安全性。如果有CA机构在你申请证书的时候帮你产生私钥,那么还是尽早远离它,太不专业了!
一般的个人用户使用加密的私钥就比较安全了,但是如果你对私钥的安全性要求非常高,那么给私钥加密这种方法也是不够的。厉害的的攻击者可以从进程内存中检索出你的私钥。这时候就需要做进一步的升级--采用硬件安全设备(HSM)。这种设备一般都比较昂贵,几w到几十w不等。像金融和政府机构这种安全性需求高的组织都需要使用这种硬件安全设备。对于普通的用户来说给私钥加密就足够了。
关于密钥的安全性就介绍这么多,其一是让大家了解密钥的安全属性,其二是为了提醒大家将自己的私钥视为珍宝,妥善保管。
好了,讲了这么多概念性的东西,接下来我们看看如何查你访问的站点证书的密钥位数。以(360浏览器为例,见下图),在浏览器里面点击域名前面的小锁标记,就可以看到证书信息选项,点击后即可查看证书的详细内容,在这里面就会有描述证书的密钥位数,是不是很简单,各个浏览器对于证书查看和展示稍微有点不一样,但基本上都是大同小异。
二、证书的选择
聊到了证书,我们就继续往下看看证书在使用的过程中有哪些安全性是值得注意的。
首先,申请证书的时候选择正规可信CA机构是肯定的。因为CA机构都需要定期经过审计机构的审核。正规CA提供的证书的兼容性和安全性都有保障。而且,正规的CA机构对证书的吊销列表(CRL)和在线证书状态协议(OCSP)都会提供更稳定和可靠的服务。
其次,在申请证书的时候,要尽可能覆盖DNS所对应的所有域名。比如要申请了www.aa.com域名的的证书,那么在证书的备用名称里面最好要包括aa.com这个域名。因为你不能保证你的客户只从www.aa.com这个域名请求你的站点。如果没有包含在内,在访问该站点的时候浏览器就会弹出警告信息,影响用户的体验。当然,使用通配符证书(如*.aa.com)是一种很好的方式。使用起来会方便许多。但是需要特别提醒的是,证书对应的私钥越少人知道就会越安全,对于子域很多的分级部署,尤其要考虑其使用过程中的安全性。在考虑使用便捷的同时,安全这根弦一定要时时刻刻的崩住。
再者,那就是对于证书类型的选择。我们上文中也提到了一些ECC算法效率的优越性,所以可以选择ECC证书。使用ECC证书的好处不也仅仅与此。但是ECC证书的兼容性没有RSA证书的好。 在很多平台和客户端设备并不支持ECC证书的握手通信。所以,用户需要根据自己的业务场景进行选择。当然,采用RSA+SM2国密双证书体系,更是一个很不错的选择。
好了,做好了以上两步我们就算成功的迈出了第一步。接下来看怎么使用申请到的证书,如何才能更好的完成Web站点的HTTPS配置。
三、使用完整的证书链
在配置服务端证书的时候,仅配置我们申请到的证书是不够的。需要配置完整的证书链才能保证我们的部署是完整的。因为浏览器在验证证书是否可信的时候,是通过证书链来验证的。用中级证书验证你申请的服务器证书是否可信,用顶级根验证中级根是否可信。验证的逻辑是逐级进行。顶级根的可信性则来源于浏览器或者操作系统中预置的根证书。以Edge浏览器为例,你在浏览器设置里就有受信任的根证书颁发机构(见下图),这里面就可以查看到预置的根证书。
如果在配置服务端证书的时候,有的浏览器会通过预置的中级根通过验证,有的则会提示告警信息。所以,为了用户更好的体验,需要配置完整的证书链。
四、使用安全的协议
在我们SSL / TLS系列中共有六种协议:SSL v2,SSL v3,TLS v1.0,TLS v1.1,TLS v1.2和TLS v1.3。
其中
- SSL v2:不安全(DROWN攻击),因此不能使用。
- SSL v3:与HTTP(POODLE攻击)一起使用时不安全。现在也已经过时,也不建议使用。
- TLS v1.0:它的主要缺点(BEAST)在现代浏览器中已得到缓解,也是属于不建议使用的旧协议。
- TLS v1.1和v1.2: 都没有已知的安全问题,但是只有v1.2提供了现代加密算法。
- TLS v1.3:是一个全新的增加,它是一个完全现代化的协议,正在已经成为正式标准。
TLS v1.2应该现在最主流,使用最广泛的协议,因为它提供了现代身份验证加密的版本(也称为AEAD)。如果不支持TLS v1.2,则说明缺乏安全性。当然为了兼容老的客户端,可能需要继续支持TLS v1.0和TLS v1.1。但是,这些老协议将要被新协议取代那是肯定的。例如,PCI DSS标准中将要求所有接受信用卡付款的站点在2018年6月之前删除对TLS v1.0的支持。
TLS v1.3属于新生代协议,如今,很多新版本的浏览器都已经支持。所以如果你的站点服务支持TLSv1.3协议,大胆的使用它。
五 、使用安全密码套件
加密套件的选择与配置也非常重要,因为加密套件是客户端与服务端握手通信的桥梁。建议配置具有向前安全性(Forward Secrecy)的加密套件,以及对称秘钥的长度至少在128位。而且支持AEAD的加密套件更是首先。同样的,如果需要兼容一些老的客户端版本也可以配置安全性较弱的加密套件,但是可以调整其优先级,比如可以在服务端配置端优先,这样在客户端和服务端选择套件的时候会根据服务端的优先顺序而来协商使用哪一种加密套件。还有一点需要注意的是需要在配置中需要屏蔽哪些不安全的加密套件。比如加密位数低的、包含 RC4、3DES算法的加密套件。
下面是加密供参考配置的加密套件:
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
把握好了上面几点,我们就有了最的站点就有了基本的安全保障。但是新的问题又出现了,将站点从http升级https后,安全是有了保障,但是性能又是不得不考虑的问题。特别是像遇到双十一这种购物狂欢节,更是程序员和相关运维人员一年一度的大考。如何提升https站点的性能,我们下文接着聊。