对于https的简单了解.
我们这一次来讨论一下有关于https的相关知识. 其中最重要的就是有关于加密方式的知识. https中到底是对称加密还是非对称加密? 为什么要选用对称加密, 或者是非对称加密? 玄机何在? 这一小节, 我们一起来看一看.
有关于加密, 我们首先来看一下不加密的情况, 一般在计算机中, 不加密我们成为'裸奔'. 如果数据不加密, 则很容易被黑客窃取到. 如下图所示:
所以针对这样的情况, 我们应该在数据传输的过程中进行对应的加密, 那么问题来了,我们应该选择哪种加密方式呢? 我们知道: 常见的加密方式有对称加密和非对称加密之分, 例如我们这里选择对称加密的形式. 则如下图所示:
我们可以把data数据, 配合秘钥, 进行f()函数运算, 进而得到密文: XXX, 再把XXX传递到服务器端, 从而使数据的传输进行加密, 但是这样也面临一些对应的问题, 我们知道, 对称加密的密钥是由后端生成的, 但是该秘钥往往只有一个, 因为后端不可能为每一个人设置一个秘钥, 否则后端存储的秘钥就太多了. 既然秘钥只有一个, 那么前端想要解密就需要获取该秘钥. 这也就是不安全的地方了. 因为黑客也可以伪装成良民(普通的客户端), 拿取到对应的秘钥, 从而对获取的数据进行解密处理. 所以对称加密的方式其实是不安全的. 虽然进行了加密但是黑客可以很容易就进行解密.
对称加密这么不安全, 那么非对称加密呢? 是不是非常安全. 接下来让我们一起来看一下:
从上图我们可以知道, 使用非对称加密有两种加密方式: 公钥加密,私钥解密, 私钥加密, 公钥解密.
一开始服务端生成一对公私钥(pk, sk). 我们要想进行密文通讯, 需要客户端获取对应的公钥(pk). 所以客户端会发送请求, 请求公钥. 客户端获取到pk后, 会把数据放到f() 方法中进行对应的加密, 所用的秘钥就是刚刚获取的pk. 加密后得到的XXX就是密文. 所以我们可以把数据传输给服务器端.
这个时候, 如果黑客截取了对应的XXX数据, 黑客将没法获取对应的明文数据, 因为他没有获取对应的公钥(pk).
但是非对称加密的缺点来了: 如果服务端想要给客户端传递数据, 也需要加密该怎么办呢? 如果使用私钥加密, 把加密的字段YYY传输给客户端, 看似没有问题, 但是细细想一下, 我们就会知道黑客也是可以充当良民从而获取公钥(pk)的. 也就是说, 只要是使用私钥(sk)加密的方法, 黑客都可以对其进行解密.
总结发现: 单独使用对称加密, 不安全, 单独使用非对称加密, 也不安全. 那么应该怎么解决呢?
经过科学家的努力. 我们就想到了能不能把两者结合到一起呢?
例如下面的图片显示:
通过上面的图片, 我们知道, 先通过请求, 获取服务端的pk, 拿到之后, 我们可以在客户端随机产生一个key, 然后通过f(pk, key) = XXX的方式, 把XXX传输给服务端, 这样服务端就可以通过私钥(sk)对XXX进行解密, 从而得到key. 以后我们就可以通过key, 作为秘钥, 进行对称加密了.
这样的方式是非常棒的. 通过这样的方式我们会觉得数据是非常安全的.
但是真的安全吗?
其实是不对的, 如果我们设想一下. 黑客如果从最开始就对我们的通讯进行了监听. 那么我们获取公钥的过程也会被监听到. 而我们知道, 非对称加密的公钥(pk), 黑客也是可以获取的. 所以一旦公钥泄露. key就会泄露, key泄露, 则后面的全部对称加密都称不上是安全的. 所以后面很安全,但是如何保证pk的传输也是安全的就至关重要了.
那么该如何解决这个问题呢?
我们可以对上面的内容再次进行优化, 例如我们这里引入一个'CA机构', 'CA机构' 是一种信用机构. 主要靠信用赚钱, 一般来说都是全球的大型机构. 这类机构也会有自己的公钥(cpk)和私钥(csk), 可以使用csk对于pk公钥进行加密, 从而得到证书, 我们可以把证书传递给前端, 让前端利用浏览器内部自带的公钥(cpk)对证书进行解密, 如果解密成功, 则可以获取到pk, 随后再利用pk对前端生成的key进行加密. 重复之前的步骤.
通过上面的步骤, 其实我们就能够得到完整的, 安全的通讯方式了. 这个其实就是https通讯方式中的最主要的加密方式介绍.
好了. 通过上面的学习, 我们可以知道https通讯其实使用了非对称加密和对称加密的多种方式来进行的.
