从设计角度思考Https，springcloud面试题2021

那么似乎哪一种加密都能满足，那么我们不禁有个问题，万一有黑客(恶意机器)拦截了我们的请求，并且充当了中间的传输者，我们的这两种加密算法还安全吗？如下图:

可以看到，我们的客户端和服务端中间被未知的恶意机器拦截转发了请求，那么我们之前的加密方式如果是直接传递的加密方式和密钥，如果是对称加密那么结局可想而知，对于中间机器来说，依然可以解密出客户端和服务端的消息，对于黑客来说依然是透明的，安全性仅仅比不加密强上一点点，完全不可以称之为可信任的安全协议，那么使用非对称加密呢？我们都知道非对称加密是一堆密钥，每一端持有自己的私钥，对外公开公钥，而公钥加密仅仅使用私钥才可以解密，这样即使有中间机器拦截，也仅仅能拿到客户端和服务端的公钥，但是我们不要忘记了，客户端应该是持有服务端的公钥，用公钥加密传输给服务端，服务端私钥解密，响应的过程即是客户端的私钥解密服务端持有的客户端公钥，中间机器即使拦截了双方的公钥，也无法解密双方公钥自身加密的信息，这样的话，客户端和服务端数据传输安全的问题似乎完美解决了

新隐患-公钥传输方式

刚刚我们经过对比，确定了使用公私钥方式的非对称加密来作为客户端-服务端传输的加密方式，看起来应该高枕无忧了，那么事实真的如此吗？其实和对称加密一样，非对称加密这样直接传输加密，也仅仅是提高了一点点安全性而已，如果遇到的黑客在拦截到客户端的请求后，将自身的公钥传递给服务端以及客户端，而将客户端/服务端的公钥持有会如何？是的，细极思恐，那样中间机器将拥有解密双端消息的能力！为什么会这样？试想一下，客户端使用所谓服务端的公钥加密消息，发送，被中间机器拦截后，这所谓的服务端公钥是中间机器的，那么私钥岂不是可以解密拿到明文信息？然后再伪装使用拦截到的真实的客户端的公钥加密，转发给服务端，同理，服务端的所谓客户端公钥加密对于中间机器完全形同虚设，那么这种问题如何解决呢？我们可不可以更换一种公钥传输方式，尽量绕开中间机器的拦截，保证安全性呢？

我们可以想下，大概有如下两种方法传输公钥:

1.服务端把公钥发送给每一个连接进来的客户端

2.将公钥放到一个地方(比如独立的服务器，或者文件系统)，客户端需要获取公钥的时候，访问这个地方的公钥来和服务端进行匹配

而第一个方案，即我们刚刚推翻的方案，很明显会存在被拦截调包的可能，那么似乎我们只能使用第二个方案来传输公钥？那么我们不禁有个问题，即客户端是如何知道存放公钥的远程服务器地址以及认证加密方式，而且每次建立连接都要来获取一次，对服务器的抗压能力也有一定的考验？还有如何保证黑客等恶意访问的用户不能通过此种方式拿到公钥，所以安全也是个比较麻烦的问题

引入第三方CA机构

由于上述提到的问题，所以对于个人而言，如果在开发网站的同时，还要再花费大量金钱和精力在开发公钥服务上，是很不合理的，那么有木有专门做这个的公司，我们托管给这个公司帮我们完成，只需要付出金钱的代价就能体验到服务不可以吗？于是，专门负责证书认证的第三方CA机构出现了，我们只需要提前申请好对应的服务端信息，并且提交对应资料，付出报酬，CA就会给我们提供对应的服务端认证服务，大大减少我们的操作和复杂度，但是这个时候我们不禁又有个问题，CA机构能保证只有客户端拿到认证的证书，并且认证通过，拦截对应的非正常客户端吗？如果不能的话，那岂不是黑客也可以拿到认证？现在的问题开始朝着如何认证用户真伪方向发展了

验证证书有效性

其实想要解决认证的问题，我们可以从生活中寻找一些灵感，我们每个人都有一个唯一的id，证明身份，这样可以保证识别出id和对应的人，也能识别不法分子，那么，既然计算机来源于生活，设计出来的东西也应该遵循正常的逻辑，我们何不给每个证书设置类似id的唯一编号呢？当然计算机是死的，没办法简单的将机器和证书编号进行绑定，那么就需要设计一个符合逻辑的证书验证过程。我们不妨思考下，平时开发的软件为了识别被人篡改的软件，我们是如何做的，相信大脑里有个词会一闪而过，MD5/SHA1(签名)？没错，那么我们证书的认证可否按照这个思路设计？

现在我们假设，客户端拿到证书后，能够从证书上拿到公钥信息、证书签名hash和有效期等信息，也就是说证书内置了计算整个证书的签名hash值，如果此时我们根据客户端的签名算法进行一次加签计算，和证书默认计算好的hash比较，发现不一致，那么就说明证书被修改了，肯定不是第三方发布的正式证书，如果一致，说明证书是真实的，没有被篡改，我们可以尝试与服务端连接了，因为证书拿到了，也有了公钥，后续的就是加密通信的过程了

至此，似乎一个安全的加密https简陋的设计出来了，也似乎解决了这些安全问题，但是不得不提的一点是，我们上面有个很重要的一点，即存放证书的服务器一定要保证安全性，第三方机构算不算绝对安全呢？答案是否定的，因为在https至今的历史上，发生过第三方机构被黑客攻击成功，黑客使用的也是正版的证书的事件，只能说计算机的世界不存在绝对安全，而是相对来说，安全系数提高了太多

HTTPS认证过程

前面我们设计了简陋版的HTTPS，那么，我们接下来看看，正版的HTTPS大体认证过程是如何的，首先我们从申请证书开始：

结语

小编也是很有感触，如果一直都是在中小公司，没有接触过大型的互联网架构设计的话，只靠自己看书去提升可能一辈子都很难达到高级架构师的技术和认知高度。向厉害的人去学习是最有效减少时间摸索、精力浪费的方式。

我们选择的这个行业就一直要持续的学习，又很吃青春饭。

虽然大家可能经常见到说程序员年薪几十万，但这样的人毕竟不是大部份，要么是有名校光环，要么是在阿里华为这样的大企业。年龄一大，更有可能被裁。

小编整理的学习资料分享一波！

送给每一位想学习Java小伙伴，用来提升自己。想要资料的可以点击这里免费获取

/java-p7)**
[外链图片转存中…(img-tNSYziUu-1628396180447)]

本文到这里就结束了，喜欢的朋友可以帮忙点赞和评论一下，感谢支持！