从设计角度思考Https，spring事务实现原理面试

最新推荐文章于 2024-09-27 21:03:59 发布

前端大妹纸

最新推荐文章于 2024-09-27 21:03:59 发布

阅读量345

点赞数 10

分类专栏： 2024年程序员面试文章标签： https spring 面试

本文链接：https://blog.csdn.net/m0_58269070/article/details/136717767

版权

2024年程序员面试专栏收录该内容

13 篇文章 0 订阅

订阅专栏

文章讨论了使用非对称加密在客户端-服务端通信中的安全性问题，指出直接传输公钥存在风险。文章提出了通过第三方CA机构和证书验证来增强安全，并介绍了HTTPS的认证过程，包括证书申请、校验和使用对称加密加强数据交换的过程。

摘要由CSDN通过智能技术生成

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

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

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

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

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

引入第三方CA机构

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

验证证书有效性

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

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

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

HTTPS认证过程

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

可以看到，申请证书的时候，需要提供很多内容，其中域名、签名hash算法、加密算法是最重要的，通过这三项计算生成证书以及确定加密认证算法，并且在这个过程中还需要提供服务端自己的公钥，用来生成证书，CA机构使用自己的私钥加密证书，生成证书传递给服务端

2.证书申请拿到以后，客户端tcp三次握手连接(会携带一个随机数client-random)，这个时候服务端将证书信息(包含过期时间、签名算法、当前证书的hash签名、服务端公钥、颁发证书机构等信息)传递给客户端，并且传递一个random随机数

3.客户端收到证书后，使用浏览器内置的CA认证，对证书的颁发机构逐个/逐层校验，确定证书来源正常，并且校验证书过期时间，确定是否可用，最后根据证书的签名算法，计算出对应的签名hash，和证书内置的签名hash比较，确定是否是未篡改的证书，完全认证通过后，证书认证环节结束

4.客户端生成随机对称密钥( pre-master )，将双端随机数组合通过证书的公钥(服务端的公钥)加密后，发送给服务端，服务端收到后，根据双方生成的随机数组合验证击进行http通信

以上就是HTTPS认证的大体流程，另外需要注意的是，HTTPS使用了签名算法(MD5/SHA256等)、对称加密以及非对称加密完成了整个交互过程，在认证过程中仅仅使用了签名算法和非对称加密保证建立通道的安全稳定，在通道建立过程中，维持了一个sessionid，用来防止频繁创建通道大量消耗资源，尽可能保证通道长期连接复用，并且我们需要知道一点，非对称加密虽然安全，但是相比较对称加密，加密解密步骤复杂导致时间会更久，所以HTTPS在建立通道以后，会选择双端协议使用对称加密来完成后续的数据交互，而上述提到的双方的随机对称密钥组合是用来在建立连接后的第一次交互的过程中，二次确认握手过程是否被篡改(客户端把Client.random + sever.random + pre-master组合后使用公钥加密，并且把握手消息根据证书的签名算法计算hash，发送给服务端确认握手过程是否被窜改)，完成校验后，确定当前是安全连接后，双端之间就会使用约定好的对称加密算法进行数据加密解密传输，至此一个完整的HTTPS协议完成

如果你的技术提升遇到瓶颈了，或者缺高级Android进阶视频学习提升自己，这有大量大厂面试题为你面试做准备！

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。