typora-root-url: img
typora-copy-images-to: img
从设计角度思考HTTPS
我们了解了HTTP协议的内容后，明白HTTP存在很多安全隐患，所以后来推出了安全协议-HTTPS，我们不妨站在设计角度来设计一个安全的HTTP连接协议，看看HTTP存在哪些问题，我们该如何设计能保证安全性，从而了解HTTPS的安全协议是如何保障的HTTP安全
首先我们需要考虑一下，实现HTTPS所谓的安全，我们需要保证那些地方的安全：
1.首先我们需要保证服务端和客户端之间发送的消息是安全的
2.其次我们要保证服务端和客户端之间的连接是安全的
3.最后我们还要保证服务端不会被其他的伪造客户端连接，并且通过此方式破解加密方式
服务端/客户端信息交互的安全
首先我们先来考虑一下，有什么方法可以保证客户端发送的消息给服务端并且服务端返回结果，这个过程是安全的，大概的过程如下:
这个时候我们最先想到的方案--加密，我们使用加密算法给数据加密了不就行了吗，那么该选择什么加密算法呢？开发过程中最常见的加密算法如：MD5、SHA1这样的摘要算法或者aes、des这样的对称加密算法，又或者rsa这样的非对称算法，看起来每一种都可以实现数据加密传输，但是我们不要忘记了，第三点中我们希望能保证其他客户端连接不会破解此种加密方式，要知道在互联网中，不是仅仅一台客户端和一个服务端交互，可以有无数台客户端同时与服务端交互，这个时候我们如果要防止别的客户端破解加密，看起来摘要算法这种不可逆的算法刚好合适，但是我们不要忘记了，客户端和服务端需要完成交互的，那么也就是说这个加密不能为不可逆算法，否则客户端也无法对服务端数据进行处理，服务端也无法处理客户端数据，那么只能是对称加密算法或者非对称加密算法能满足了，我们继续思考，如果是多台客户端同时连接服务端，如下图:
那么似乎哪一种加密都能满足，那么我们不禁有个问题，万一有黑客(恶意机器)拦截了我们的请求，并且充当了中间的传输者，我们的这两种加密算法还安全吗？如下图:
可以看到，我们的客户端和服务端中间被未知的恶意机器拦截转发了请求，那么我们之前的加密方式如果是直接传递的加密方式和密钥，如果是对称加密那么结局可想而知，对于中间机器来说，依然可以解密出客户端和服务端的消息，对于黑客来说依然是透明的，安全性仅仅比不加密强上一点点，完全不可以称之为可信任的安全协议，那么使用非对称加密呢？我们都知道非对称加密是一堆密钥，每一端持有自己的私钥，对外公开公钥，而公钥加密仅仅使用私钥才可以解密，这样即使有中间机器拦截，也仅仅能拿到客户端和服务端的公钥，但是我们不要忘记了，客户端应该是持有服务端的公钥，用公钥加密传输给服务端，服务端私钥解密，响应的过程即是客户端的私钥解密服务端持有的客户端公钥，中间机器即使拦截了双方的公钥，也无法解密双方公钥自身加密的信息，这样的话，客户端和服务端数据传输安全的问题似乎完美解决了
新隐患-公钥传输方式
刚刚我们经过对比，确定了使用公私钥方式的非对称加密来作为客户端-服务端传输的加密方式，看起来应该高枕无忧了，那么事实真的如此吗？其实和对称加密一样，非对称加密这样直接传输加密，也仅仅是提高了一点点安全性而已，如果遇到的黑客在拦截到客户端的请求后，将自身的公钥传递给服务端以及客户端，而将客户端/服务端的公钥持有会如何？是的，细极思恐，那样中间机器将拥有解密双端消息的能力！为什么会这样？试想一下，客户端使用所谓服务端的公钥加密消息，发送，被中间机器拦截后，这所谓的服务端公钥是中间机器的，那么私钥岂不是可以解密拿到明文信息？然后再伪装使用拦截到的真实的客户端的公钥加密，转发给服务端，同理，服务端的所谓客户端公钥加密对于中间机器完全形同虚设，那么这种问题如何解决呢？我们可不可以更换一种公钥传输方式，尽量绕开中间机器的拦截，保证安全性呢？
我们可以想下，大概有如下两种方法传输公钥:
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协议完成
