the internet is my religion text

在介绍HTTPS之前,首先需要了解为什么要引入HTTPS。简单来说是HTTP协议不安全,在传输过程中传输明文,使得整个传输过程完全透明,如果请求被截获,请求/响应报文都可能被修改,因此数据不具有可信性。

要讨论安全就得先定义安全。通常来讲,如果通信过程具备了四个特性,就可以认为是安全的:

  • 机密性:其他人不可见;
  • 完整性:数据从发送端到接收端保持一致,未被篡改;
  • 身份认证:可确认对方真实身份,保证消息只能发给可信的人;
  • 不可否认:无法否认请求发生;

HTTPS中的SSL/TLS

在HTTPS中,HTTP下层的传输协议由TCP/IP换成了SSL/TLS。SSL(Secure Sockets Layer)发展到v3时改名为TLS(Transport Layer Security),版本号从1.0重新算起,所以TLS1.0实际上就是SSL v3.1。目前主要应用的是1.2,之前的协议都已被认为是不安全的了。

TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成,综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。TLS 的密码套件格式:“密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法”。

当浏览器和服务器在使用TLS建立连接时,需要选择一组恰当的加密算法来实现安全通信。这些算法的组合叫做密码/加密套件(cipher suite)。

SSL/TLS的具体实现,体现在OpenSSL中。OpenSSL是著名的开源密码学工具包,几乎支持所有公开的加密算法和协议,许多应用软件会使用它作为底层库来实现TLS功能。包括常用的Web服务器Apache、Nginx等。

HTTPS中的机密性

实现机密性的常用方法是加密encrypt,就是把为传输的信息上锁(转换成乱码),只有有钥匙的人,才能解锁信息(解密信息)。在这里的描述中,钥匙就是密钥key,加密前的信息叫明文plain text/clear text,加密后的乱码叫密文cipher text,解锁信息的过程叫解密decrypt。整个操作用到的就是加密算法

密钥是一长串数字,如果密钥长度是 128,就是 16 字节的二进制串,如果密钥长度 1024,就是 128 字节的二进制串。

1字节byte = 8位bit

加密方式主要有三种。如果加密和解密使用了同一个密钥,叫对称加密。如果加密和解密使用了不同的密钥,叫非对称加密。如果既使用了对称加密又使用了非对称加密,这种方式叫混合加密

对称加密:有很多加密算法,但大都被证明不安全,目前通常使用AES(Advanced Encryption Standar 密钥长度可以是 128、192 或 256)和ChaCha20(Google设计 密钥长度固定为 256 位)。对称加密算法中还有一个分组模式的概念,即让算法用固定长度的密钥加密任意长度的明文,通常使用的分组模式为GCM、CCM 和 Poly1305。比如,AES128-GCM,意思是密钥长度为 128 位的 AES 算法,使用的分组模式是 GCM。

但是这里存在一个问题,如何把密钥安全地传递给对方,即如何密钥交换?因为如果在传递消息时包含密钥,那被劫持后就可以直接解密信息,加密就没意义了。如果再采用加密密钥的方法,传输加密后的密钥,外层的密钥依然会面临同意的问题。所以只是用对称加密算法,是绝对无法解决密钥交换问题的。

这就出现了非对称加密(公钥加密算法)。非对称加密算法中有两个密钥:公钥public key和私钥private key。

算法规则:公钥加密后只能用私钥解密,私钥加密后只能用公钥解密。

在应用场景中,某服务在网上任意分发公钥,而秘密保管私钥。请求发起时,客户端使用公钥加密信息就可以了,因为除了服务提供商,其他人没有解密的私钥。这就保证了安全传输。非对称加密中目前主要使用的算法是RSA(Rivest–Shamir–Adleman 三位发明者名字)和EEC(Elliptic Curve Cryptography)。

  • RSA:加密解密基于“整数分解”的数学难题,使用两个超大素数的乘积作为生成密钥的材料,想要从公钥推算出私钥是非常困难的。正是这种计算上的困难,确保了解密的困难程度,从而保证了安全性。随着硬件设备算力的提高,目前普遍认为RSA至少要2048位才能安全加密。
  • ECC:加密解密基于“椭圆曲线离散对数”的数学难题,使用特定的曲线方程和基点生成公钥和私钥。比起 RSA,ECC 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的 RSA,而 224 位的 ECC 则相当于 2048 位的 RSA。因为密钥短,所以相应的计算量、消耗的内存和带宽也就少,加密解密的性能就上去了。

基于以上对称加密和非堆成加密的比较,似乎只需要使用非对称加密就能满足机密性了,那对称加密存在的意义是什么?其实在非对称加密中,存在一个明显的问题,即他们都是基于非常复杂的数学难题,需要大量计算。如果用非对称加密加密全部信息,那通信速度会受到影响。请看如下不同算法加密解密1000次花费的时间:

对称加密跟非堆成加密差了几百倍。

基于以上的困境,网络/密码专家们结合了以上两种算法,取长补短,采用了混合加密解决方案。即使用非对称加密算法中的公钥加密一个对称算法中的’会话密钥‘,使用这个对称算法中的’会话密钥‘真正加密发送的信息/数据。这样的好处是,解密对称算法上锁的数据/信息会来得比较快,对称算法的’会话密钥‘又被非对称算法中的’公钥‘安全加密。

如此,安全和性能得以兼顾。

HTTPS中完整性、身份认证、不可否认

为什么完整性是必要的?

机密性被保证之后,黑客拿到的的确是密文,但如果黑客收集到了足够多的密文,再将这些密文修改/重组后发送给服务端,如果没有完整性保证,服务端依然会接受黑客的请求,这样,黑客就可能通过服务端的响应来获得线索并破解明文。

为什么身份认证是必要的?

黑客伪造身份发布公钥,你拿到公钥之后加密信息。对于黑客来说相当于没有加密。即黑客可以伪装成服务端/客户端。

解决完整性痛点的方案是引入摘要算法Digest Algorithm(通常有散列函数、哈希函数,目前TLS推荐使用的是SHA-2)。使用摘要算法把传递的信息/数据转换成一个’摘要‘,然后发送传递的信息+摘要。基于摘要算法的雪崩效应,即原文微小的变动就会使得生成的摘要完全不同。这样,在服务端收到信息+摘要之后,只需要使用同样的算法,把信息再转换成摘要,然后和发送过来的摘要进行比较。如果完全相同,则保证了发送数据的完整性。

考虑一种情况,如果不使用加密算法,仅使用摘要算法是否可以保证传输安全?

如果不对信息加密,黑客完全可以修改消息之后把摘要也改了,这样服务端会认为消息是完整的。因此,完整性需要建立在机密性之上。

解决身份认证痛点的方案是引入数字签名。数字签名的原理,就是使用非对称加密里的私钥,加密上面提到的摘要,加密后的结果就是数字签名。私钥加密后的摘要,如果能够使用公钥解密,则就能证明来源/身份,因为私钥是完全保密的。在发送请求时,客户端和服务端互相交换公钥,就可以用“数字签名”和“验签”来确认消息的真实性,如此同时实现“身份认证”和“不可否认”。

但这里存在一个公钥是否可信的问题。比如黑客发布了公钥,我们如何判断这个公钥是否安全?这就引出了数字证书Certificate和CA Certificate Authority 证书认证机构。

证书认证机构CA会对各个公钥签名。格式包含序列号、用途、颁发者、有效时间等等,把这些打成一个包再签名,完整地证明公钥关联的各种信息,形成“数字证书”(Certificate)。换句话说,签名,就是用私钥加密。证书,就是由私钥加密的公钥+相关信息验证,就是能够用公钥解密。

主要的几家CA: DigiCert、VeriSign、Entrust、Let’s Encrypt

小一点的 CA 可以让大 CA 签名认证,但链条的最后,也就是 Root CA,就只能自己证明自己了,这个就叫“自签名证书”(Self-Signed Certificate)或者“根证书”(Root Certificate)。

关于验证证书的过程:
服务器返回的是证书链(不包括根证书,根证书预置在浏览器中和操作系统中),然后浏览器就可以使用信任的根证书(根公钥)解析证书链的根证书(根私钥加密的一级证书的公钥)得到一级证书的公钥+摘要验签,然后拿一级证书的公钥解密一级证书(一级私钥加密的二级证书公钥)拿到二级证书的公钥和摘要验签,再然后拿二级证书的公钥解密二级证书(验证),得到服务器的公钥和摘要验签。验证过程结束。

注意:以上内容全部来自于罗剑锋老师关于HTTP的课程,属于个人学习笔记,切勿用做商业用途。

发表评论

常枳
近期评论
分类