应用层协议HTTPS

前面我们已经了解HTTP协议HTTP基于明文传输客户端与服务器之间所有请求响应数据都是裸文直接在网络上传输。数据在经过路由器、代理服务器时很容易被窃听、篡改账号密码、会话信息等敏感数据存在泄露风险因此诞生了HTTPS。一、加密与解密在学习https协议之前我们先要了解一组概念叫做加密与解密加密就是把明文(要传输的信息) 进行一系列变换生成密文。解密就是把密文再进行一系列变换还原成明文。在这个加密和解密的过程中往往需要一个或者多个中间的数据辅助进行这个过程这样的数据称为密钥。1.1 为什么要对数据做加密对数据加密是为了将明文转换为密文避免数据在传输、存储过程中被窃取、篡改限制未授权人员查看敏感信息例如常见的运营商劫持会擅自篡改未加密的网络流量植入广告、跳转恶意页面而加密如 HTTPS可让传输内容变为密文运营商无法读取、修改数据能有效抵御此类风险保护个人隐私与企业核心资料同时满足网络安全、个人信息保护相关法规合规要求降低数据泄露带来的损失。1.2 常见的加密方式对称加密对称加密采用单钥密码系统的加密方法同一个密钥可以同时用于信息的加密和解密也叫单密钥加密核心特征是加密和解密所用的密钥是相同的。常见算法DES、3DES、AES、TDEA、Blowfish、RC2 等特点算法公开、计算量小、加密速度快、加密效率高核心原理通过同一个 “密钥”把明文加密成密文也能把密文解密成明文。非对称加密非对称加密需要两个密钥完成加密解密公钥公开密钥 public key、私钥私有密钥 private key公钥与私钥成对配对。常见算法 RSA、DSA、ECDSA了解特点算法逻辑复杂安全性高。但其加密解密速度慢远慢于对称加密。非对称加密有两种使用方式方式一加密通信使用公钥加密明文得到密文再用私钥解密密文得到明文。使用私钥进行解密能进行解密的人非常少。这种方式适用于需要保证数据机密性的场景。发送方使用接收方的公钥对数据进行加密由于公钥是公开的任何人都可以获取但只有持有对应私钥的接收方才能解开密文。即使密文在传输过程中被第三方截获由于第三方没有私钥也无法还原出明文内容。典型应用包括 HTTPS 握手过程中的密钥交换、电子邮件加密传输等。方式二数字签名反向使用使用私钥加密明文得到密文再用公钥解密密文得到明文。这种方式只有持有私钥的人才能对数据进行加密。这种方式与方式一正好相反私钥加密、公钥解密其核心目的不再是保证机密性而是验证数据的完整性和来源真实性。由于私钥只有发送方自己持有用私钥加密后的数据任何持有公钥的人都能解开验证从而确认这份数据确实来自私钥持有者且内容在传输过程中没有被篡改。典型应用包括数字签名、软件发布时的完整性校验、身份认证等场景。1.3 数据摘要数字指纹 (数据摘要)其基本原理是利用单向散列函数 (Hash 函数) 对信息进行运算生成一串固定长度的数字摘要。数据摘要有个典型特征两份完全相同的数据用同一个散列函数计算只要其中一份数据发生微小改动哪怕只修改一个比特位最终生成的数据摘要都会截然不同。所以数字摘要虽然并不是一种加密机制但可以用来判断数据有没有被篡改。摘要常见算法有 MD5、SHA1、SHA256、SHA512 等算法把无限的映射成有限因此可能会有碰撞两个不同的信息算出的摘要相同但是概率非常低摘要特征和加密算法的区别是摘要严格意义不是加密因为没有解密只不过从摘要很难反推原信息通常用来进行数据对比。数据摘要应用案例案例一网盘的秒传机制数据摘要最典型的落地场景就是网盘的秒传机制。用户甲先把视频《战狼》上传到百度云盘。云盘服务器接收文件后使用散列Hash算法对完整文件计算生成唯一的数据摘要同时把原始文件保存在服务器存储池中并记录该摘要与文件的对应关系。李四本地也拥有一份完全一样的《战狼》文件现在李四想要把这份文件上传到自己的网盘账户。李四的网盘客户端就会在本地使用和服务器完全相同的散列算法对本地的《战狼》文件运算生成数据摘要。然后将这个摘要传递到百度云盘。百度云盘服务器拿到这部分摘要去存储记录中做匹配搜索。不需要上传完整文件数据。如果搜索到数据库中已经存在该摘要代表服务器已经保存过这份完全相同的文件。服务器不需要接收文件本体直接在李四的账户下创建文件索引关联到已经存在的那份原始文件。对李四来说文件瞬间就 “上传完成”也就是秒传。如果数据库找不到对应摘要说明服务器没有这份文件此时才会真正接收李四客户端上传的完整文件计算摘要并存入服务器。案例二数据库中的用户密码存储在网站后台存储用户密码不推荐直接在数据库存放明文密码例如直接保存123456到数据库中一旦数据库泄露所有用户的原始密码会直接暴露。所以当用户进行注册操作时需要把用户提交的密码通过散列算法形成数据摘要再保存到数据库中。下一次用户要进行登录操作时将用户本次输入的密码再通过散列算法形成数据摘要。再将本次形成的数据摘要与数据库中保存的数据摘要进行比对如果完全相同则说明用户输入的密码正确如果不同说明用户输入的密码不正确。1.4 数据签名当我们对数据摘要进行加密得到的就是数据签名。二、HTTPS是什么HTTPS并不是全新协议它是HTTP TLS/SSL的组合。当客户端使用https协议向服务器端传输http请求时会先经过SSL或TLS对明文信息进行加密操作然后加密后的数据到达服务器之后再由服务器端的TSL进行解密然后得到解密后的明文数据。这样一来数据在网络传输过程中即便经过路由设备或链路被抓包拦截攻击者也无法获取到账号密码等敏感信息。三、HTTP的工作过程方案一只使用对称加密由于数据是再客户端进行加密所以就需要有一个客户端密钥。但是服务器端如何拿到这个密钥呢如果直接以http 请求的形式传输就会被中间人获取。所以方案一只使用对称加密是不具备可行性的方案二只使用非对称加密假设服务器端有一对公私钥。鉴于非对称加密的机制如果服务器先把公钥以明文方式传输给浏览器之后浏览器向服务器传数据前都先用这个公钥加密好再传从客户端到服务器信道似乎是安全的 (其实有安全问题)因为只有服务器有相应的私钥能解开公钥加密的数据。但是服务器到浏览器的这条路怎么保障安全如果服务器用它的私钥加密数据传给浏览器那么浏览器用公钥可以解密它而这个公钥是一开始通过明文传输给浏览器的若这个公钥被中间人劫持到了那他也能用该公钥解密服务器传来的信息了。所以只使用非对称加密只有浏览器端到服务器单向的数据是安全的貌似是安全的但其实存在安全问题服务器端向浏览器进行数据传输是不安全的。其次整个过程中只使用非对称加密通信速度非常慢。方案三双方都使用非对称加密客户端和服务器端都有自己的一对公钥和私钥。当客户端与服务器端要进行数据传输前客户端先将自己的公钥发送给服务器端服务器端接收到之后再把自己的公钥发送给客户端。这样双方都收到了对方的公钥。接着客户端使用自己的私钥对明文进行加密处理然后发送给服务器端服务器端接收到密文之后使用客户端的公钥对密文进行解密就能获取到客户端发过来的信息了。服务器端发送数据给客户端时也类似上述逻辑。但是这种方案也是不安全的并且双方都使用非对称加密通信速度也非常慢。方案四非对称加密对称加密服务端具有非对称公钥S和私钥S。首先客户端发起https请求获取服务端公钥S。然后客户端在本地生成对称密钥C通过公钥S加密发送给服务器。由于中间的网络设备没有私钥即使截获了数据也无法还原出内部的原文也就无法获取到对称密钥 。服务器通过私钥S 解密还原出客户端发送的对称密钥 C。并且使用这个对称密钥加密给客户端返回的响应数据。后续客户端和服务器的通信都只用对称密钥C来进行对称加密即可。由于该密钥只有客户端和服务器两个主机知道其他主机 / 设备不知道密钥即使截获数据也没有意义。由于对称加密的效率比非对称加密高很多因此只是在开始阶段协商密钥的时候使用非对称加密后续的传输仍然使用对称加密。但是方案2/3/4都存在一个共同的安全问题——中间人攻击四、中间人攻击Man‑in‑the‑MiddleAttack简称 “MITM 攻击”中间人攻击确实在方案 2/3/4 中客户端获取到公钥 S 之后对客户端形成的对称密钥 X 用服务端给客户端的公钥 S 进行加密中间人即使窃取到了数据此时中间人确实无法解出客户端形成的密钥 X因为只有服务器有私钥 S。但是中间人的攻击如果在最开始握手协商的时候就进行了那就不一定了。假设中间人具有非对称加密算法的公钥M私钥M。当客户端向服务器发起请求时服务器明文传送公钥S给客户端。此时再数据传送过程中中间人劫持了数据报文提取公钥S并保存好然后将被劫持报文中的公钥S替换成为自己的公钥 M并将伪造报文发给客户端。客户端收到报文提取公钥M (客户端当然并不知道公钥被更换过了)自己形成对称密钥X用公钥M加密 X并形成报文发送给服务器。这个报文被中间人劫持后直接用自己的私钥M 进行解密得到通信秘钥X再用曾经保存的服务端公钥S加密后将报文推送给服务器。服务器拿到报文用自己的私钥S 解密得到通信秘钥X。双方开始采用X进行对称加密进行通信但是这一切都在中间人的掌握中。后续中间人可以劫持数据进行窃听甚至修改数据。上面的中间人攻击方案同样适用于方案 2方案 3。那为什么会出现这种问题呢原因在于客户端无法甄别自己收到的含有公钥的数据报文就是目标服务器发送过来的五、CA证书与签名我们可以对一份原始数据进行散列化得到散列值。然后使用签名者的私钥对散列值进行加密得到数据签名。再将数据签名与数据结合起来得到数字签名的数据。当我们需要验证数据是否被篡改过时可以提取数字签名的数据中签名并使用公钥进行解密得到原始散列值。然后我们对数据使用同样的散列算法进行散列化得到新散列值。然后对比新旧散列值如果新散列值与原始散列值相等说明签名有效。数据签名的签名权限仅属于签名方。由于只有签名者持有可对散列摘要进行加密的私钥故而只有签名者能够生成合法的数据签名。而这里的签名者我们称之为CA机构。5.1 CA证书服务端在使用HTTPS之前需要向CA 机构数字证书认证机构申领一份数字证书这份证书就叫做CA证书。证书里包含证书申请者信息、服务端的公钥信息等内容。在通信握手阶段服务器会把这份数字证书传输给浏览器浏览器从证书中提取服务端的公钥使用。数字证书的作用类似身份证用来证明服务端公钥的权威性防止公钥被中间人篡改、替换避免中间人攻击。数字证书包含两部分内容一是明文信息二是签名。这里的明文信息就相当于前面所说的原始数据而为了防止明文信息被篡改于是添加了签名。当我们要对CA证书进行验证时首先先将明文信息和签名分离然后使用CA公钥对签名进行解密得到摘要A再在本地将明文信息进行散列化得到摘要B如果摘要A摘要B则说明证书是有效的也就是明文信息没有被篡改过。服务器端生成自身公私钥对构造不含私钥的证书请求文件CSR并提交至CA证书机构完成证书申请。CA机构会对申请者身份信息进行合法性审核然后提取证书明文信息并计算其哈希摘要利用CA自身私钥对该摘要执行签名运算生成具备法律效力的数字证书并下发至服务器。客户端获取服务器传输的数字证书后调用CA公钥对证书签名进行解密以获取原始摘要同时对证书明文信息重新计算哈希摘要完成摘要比对校验同步核验证书域名、有效期限及吊销状态。当全部校验项通过后客户端就能信任证书中封装的服务器公钥进而完成后续会话密钥协商流程建立安全通信链路。由于客户端是从证书中提取出的公钥也就是说只要证书是合法的那么公钥就是合法的、可信的这样就能解决中间人攻击的问题。而所有的浏览器客户端一般都会内置可信的CA机构或其授权的子机构的公钥。如果缺少这套预置根公钥体系客户端就没办法完成对CA签名的解密与证书合法性验证。5.2 最终实现方案方案5-非对称加密 对称加密 证书认证在客户端和服务器刚一建立连接的时候服务器会给客户端返回一个证书证书包含了之前服务端的公钥也包含了网站的身份信息。接着客户端会对该证书进行合法性校验验证通过后提取证书内的服务端公钥。然后客户端会生成随机会话密钥使用服务端公钥对会话密钥进行非对称加密并发送至服务端服务端利用自身私钥解密得到会话密钥。在后续的通信过程中通信双方都采用客户端提供的会话密钥并通过对称加密的方式对业务数据进行加密传输。这样在后续数据的传输中传输速率就大大提高了。