图片来自Pexels。网上有很多关于HTTPS的介绍，但我发现总有或多或少的遗漏点，我也没有全部覆盖。今天尝试由浅入深地讲解HTTPS。相信大家看完之后，一定能够掌握HTTPS的原理。本文提纲如下：为什么HTTP不安全安全通信的四大原则HTTPS通信原理简介其他HTTPS相关问题为什么HTTP不安全HTTP因为是明文传输，主要存在三个风险。①窃听风险中介可以获得通信内容。由于内容为明文，获取明文后存在安全隐患。②篡改风险中介可以篡改消息内容再发送给对方，风险极大。③冒名顶替的风险例如，您认为您正在与某宝通信，但实际上您正在与钓鱼网站通信。HTTPS显然是为了解决这三大风险而存在的。接下来我们看看HTTPS解决了哪些问题。安全通信的四大原则看完上一节，不难猜到HTTPS就是为解决以上三个风险而诞生的。通常，我们认为安全通信需要包括以下四个原则：机密性、完整性、身份认证和不可否认性。如下：保密性：即数据加密解决了被窃听的风险，因为即使中间人窃听，由于数据是加密的，他也无法得到明文。完整性：是指数据在传输过程中没有被篡改，不多不少，保持原样，即使中途改变了一个标点符号，接收方也能识别出来，从不判断收到的消息是非法的。身份认证：确认对方的真实身份，即证明“你妈就是你妈”的问题，解决了冒名顶替的风险，用户不用担心访问某某的问题宝物却与钓鱼网站通信。不可否认：不可否认已经发生的行为，比如小明向小红借了1000元，但没有打欠条，或者打了欠条但没有签字，会造成小红的资金损失。接下来，我们就来一步一步的看一下HTTPS是如何实现的，以满足以上安全通信的四大原则。HTTPS通信原理简介对称加密：HTTPS的最终加密形式由于HTTP是明文传输的，所以我们对报文进行加密是不够的。既然要加密，那肯定需要双方协商密钥。一种是通信的双方使用相同的密钥，即对称加密，对消息进行加密和解密。如图：使用对称加密的通信双方使用相同的密钥进行加密和解密。对称加密具有加解密速度快、性能高等特点。也是HTTPS最终采用的加密形式。但是，这里有一个关键问题。对称加密通信的双方需要使用相同的密钥。这个密钥是如何协商的？如果直接通过消息传递key，后面的通信其实就是裸奔，因为key会被中间人截获甚至替换，这样中间人就可以用截获的key解密消息，甚至替换key达到篡改消息的目的。有人说加密这个key还不行，但是如果对方要解密这个key，还是要把加密key传给对方，还是会被中间人截取。看来直接传送钥匙无论如何也摆脱不了俄罗斯人的圈套。宝宝的问题是不可行的。非对称加密：解决单向对称密钥传输问题无论从哪一端直接传输密钥。从上一节的分析来看，还不够。下面我们来看另一种加密方式：非对称加密。非对称加密是指加解密双方使用不同的密钥，一个作为公钥，可以公开，另一个作为私钥，不能公开。用公钥加密的密文只能用私钥解密，用私钥加密的内容，也只有公钥才能解密。注意：其实这种私钥加密的说法并不严谨。私钥加密，准确的说应该叫私钥签名，因为私密加密信息的公钥是可以解密的，而且公钥是公开的，任何人都可以获得。,用公钥解密称为签名验证。在这种情况下，对于服务端来说，保留私钥，将公钥发布给其他客户端，其他客户端只需要将对称加密密钥加密后传递给服务端即可。这样只有私钥才能解密公钥加密，只有服务端有私钥，所以可以保证客户端到服务端的传输是安全的，服务端可以获得对称加密密钥解密后，交换密钥后，现在可以使用对称加密密钥进行通信。但是问题又来了，服务端如何安全地将公钥传给客户端呢？如果直接传递公钥，也存在被中介转移的风险。数字证书解决公钥传输的信任问题如何解决公钥传输的问题？从现实生活场景中寻找答案。员工入职时，公司一般要求学历证明。很显然，并不是所有的猫狗书都能称为学历。这个学历必须由第三方权威机构（CertificateAuthority，简称CA）颁发，即教育部。同样，服务端也可以向CA申请证书，将公钥附在证书上，然后将证书传递给客户端。站点管理员向CA申请证书。申请时，服务器会提交DNS主机名等信息，CA会使用这些信息生成证书。这样客户端在拿到证书的时候，就可以得到证书上的公钥，然后用这个公钥加密对称加密密钥，发送给服务器端。看起来很完美，但是这里你要考虑两个问题。问题一：如何验证证书的真伪，如何防止证书被篡改您可以在学信网站上查询学籍号，了解证书的真伪。学籍号其实就是我们常说的数字签名，可以防止证书造假。回到HTTPS，如何生成证书的数字签名？一图抵千言：步骤如下：①首先使用某种摘要算法（如MD5）对证书明文（如证书序列号、DNS主机名等）生成摘要，然后使用第三方机构的私钥对生成的摘要进行加密（签名）。消息摘要是一种将任意长度的输入组合起来生成固定长度的伪随机输入的算法。不管输入的消息有多长，计算出的消息摘要的长度总是固定的。一般来说，只要内容不同，生成的摘要一定不同（相同的概率可以认为接近于0），因此可以验证内容是否被篡改。为什么要先生成摘要再加密，而不是直接加密呢？因为使用非对称加密非常耗时。如果将整个证书内容加密生成签名，则客户端需要对签名进行解密以验证签名。Long，客户端验证签名需要很长时间。但是，如果使用摘要，那么长的明文会被压缩成更小的定长字符串，客户端验证签名的速度也会快很多。②客户端拿到证书后，也使用同样的摘要算法计算出证书明文的摘要。如果两者匹配，则可以发现消息是否被篡改。那为什么要用第三方机构（CertificateAuthority，简称CA）的私钥来加密摘要呢？因为摘要算法是公开的，中间人可以替换证书的明文，然后根据证书上的摘要算法计算出摘要，再替换证书上的摘要！这样客户端就拿到了证书，计算出摘要。同样，如果你误认为这个证书是合法的，你也会被录用。因此，需要使用CA的私钥对摘要进行加密生成签名。这种情况下，客户端必须使用CA的公钥对签名进行解密，得到的是未经篡改的合法摘要（私钥签名，公钥可以解密）。服务器将证书发送给客户端后，客户端的签名验证过程如下：在这种情况下，由于只有CA的公钥才能解密签名，如果客户端收到假证书，则无法使用CA的公钥。如果端收到的是真正的证书，但是证书上的内容被篡改过，如果摘要比较失败，客户端也会认为证书是非法的。如果你细心，你一定已经发现问题了。如何安全地将CA公钥传输给客户端？如果还是从服务端传输到客户端，仍然无法解决公钥被打包的风险。其实这个公钥是存在于CA证书上的，这个证书（也叫RootCA证书）是被操作系统信任的，内置在操作系统中，不需要传输。如果你使用的是Mac，你可以打开keychain查看，可以看到很多内置的可信证书。服务器传输CA颁发的证书。客户端收到证书后，使用内置CA证书中的公钥解密签名，验证签名。这样就解决了公钥传输过程中被打包的风险。问题2：如何防止证书被转移。其实任何网站都可以向第三方权威机构申请证书，中间商也不例外。普通站点和中介机构都可以向CA申请证书，经过认证的证书都是合法的，因为它们是由CA颁发的。那么这个时候，中介是否可以在传输过程中，用自己的证书代替正常站点给客户端颁发的证书呢？如下图：答案是否定的，因为客户端不仅要通过签名验证的方式来验证证书是否合法，还需要验证证书上的域名是否和你请求的域名相同。虽然中间人可以更换自己向CA申请的合法证书，但是证书中的域名与客户端请求的域名不一致，客户端会认为失败！但是上面的证书传输包给了我们一个思路，什么方式呢？大家觉得我觉得，既然HTTPS是加密的，为什么Charles这些“中间人”能抓到明文包呢？实际上，他们使用的是证书切换的方法。想一想，我们在使用charles抓取HTTPS包之前需要做的，当然是安装charles证书：这个证书包含了charles的公钥，这样charles就可以将服务端发送的证书传给客户端到它自己的证书中。客户端获取后，可以使用你安装的Charles证书来验证签名等，验证通过后，会使用Charles证书中的公钥对对称密钥进行加密。整个过程是这样的：由此可见，像charles这样的中间人能抓到HTTPS包的前提是信任他们的CA证书，然后他们就可以通过更换证书的方式隐藏真相，所以一定不能信任第三方随便证书，以避免安全风险。其他HTTPS相关问题什么是双向认证在上面的描述中，我们只是在客户端验证了服务端传输证书的合法性，那么服务端如何验证客户端的合法性呢？想想看，是不是要把银行发给我们的U盘先插到电脑上？其实是因为usb-shield内置了证书，在通信时将证书发送给服务器，服务器验证通过后才能开始通信。画外音：身份认证只是U盾的其中一项功能，还有其他的功能，比如加解密，都是在U盾中进行，保证密钥不会出现在内存中.什么是证书信任链？CA申请证书，但世界上只有少数几家顶级CA（RootCA）。每天都有很多人在上面申请证书，忙不过来。我应该怎么办？想一想在一个公司，如果大家找CEO做事，他是不是疯了？他能做什么？授权，他会把权力交给CTO、CFO等，所以你只需要分配CTO之类的就可以了。如果CTO太忙，继续授权。同样，由于顶级CA太忙，它可以授权给下级CA，这样我们只需要找到一级/二级/三级CA申请证书即可。如何证明这些证书已经被RootCA授权？较小的CA可以允许较大的CA进行签名和身份验证。例如，一级CA向根CA申请签名认证，二级CA向一级CA申请签名认证。RootCA没有人可以代签，只能证明自己。该证书称为“自签名证书”或“根证书”。我们必须信任它，否则证书信任链无法继续下去（这个根证书，我们前面说了，其实是操作系统内置的）。证书信任链现在我们看看如果站点申请了二级CA签发的证书，客户端收到证书后如何验证呢？实际上，服务不仅会把证书传递给二级CA，还会把证书信任链也一起传递给客户端。这样，客户端就会按照以下步骤进行验证：浏览器使用可信的根证书（根公钥）解析证书链的根证书，得到一级证书的公钥+摘要签名.用一级证书的公钥解密一级证书，得到二级证书的公钥和摘要进行签名验证。然后使用二级证书的公钥解密服务器发送的二级证书，得到服务器的公钥和摘要验证，验证过程结束。结语相信看完这篇文章，你应该对HTTPS的原理有了一个清晰的认识。HTTPS无非就是HTTP+SSL/TLS。SSL/TLS的作用其实就是如何协商出一个安全的对称加密密钥来使用这个密钥进行后续通信的过程。带着这个疑问，相信大家可以很容易地理解数字证书和数字签名这两个令人费解的问题。意义。了解了这些，你就明白为什么HTTPS是加密的了，但是charles等工具可以明文抓包。作者：码海编辑：陶家龙来源：转载自公众号码海（ID：seofcode）
