区块链技术博客
www.b2bchain.cn

Https 为什么是安全的?(上)求职学习资料

本文介绍了Https 为什么是安全的?(上)求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

对技术面试,学习经验等有一些体会,在此分享。

Https 为什么是安全的? 这可以说是一个高频面试题了。但要完全说明白这个问题,你需要具备一些前置知识。所以在本篇中,暂时不会涉及到 Https 的具体通信流程。

让我们先思考一个问题,如何安全的传输信息

  • 保证传输内容的安全,即不传输明文

  • 防止传输内容被篡改,即可以识别篡改

  • 确认对方真的是对方,即通信双方身份的认证

围绕这几点,我们来看一看常见的加密通信方法以及存在的问题。

最古典的加密

加密技术最初起源于战争。比如著名的 凯撒密码 ,它的原理很简单,如下图所示:

Https 为什么是安全的?(上)

2068242063

将明文字母按照一定的 数字 向右平移,得到相应的 密文 。拿上图来说 ,就是把每个字母都往后挪两位,明文 BAG ,经过变换之后就是 DCH 。这样即使信息被拦截,敌人也无法获知真正的信息。

凯撒密码的密钥就是 字母向右移动的位数(上图中的 2 ) 。密钥和明文的重要程度其实是一样的,丢失密钥和丢失明文并没有什么区别。显而易见,这样的密钥强度太低了。即使后来出现了 乱序对应的字母表 ,仍然很容易被破译。

随着科学技术的进步,依托计算机发展的现代密码学提供了经过数学验证的加密方法和(伪) 随机生成的密钥,使得加密一段信息变得快速而安全。

对称加密

Https 为什么是安全的?(上)

人如其名,对称加密的 加密解密 是对称的,加密密钥和解密密钥是同一个密钥。典型的对称加密算法有 DES 和 AES 。

DES 是 1977 年美国联邦信息处理标准中所采用的一种对称加密,现在已经可以被暴力破解,所以除了考虑到兼容性问题以外,不应该再继续使用 DES 。 此外,还有为了加强 DES 强度的 三重 DES,即将 DES 重复三次。由于其处理速度不高,除了特别重视向下兼容性的情况下,很少被用于新的用途。

现在使用最为广泛的对称加密是在全世界范围内公开选拔出来的 AES 加密。经过全世界密码学家的共同论证,其安全性是毋庸置疑的。那么,我们直接使用 AES 加密通信内容不就可以了吗?

对称加密的一个致命问题就是 密钥的传输问题 。由于加解密过程都使用同一个密钥,所以通信一方必须将密钥首先传给另一方,双方才能正常的进行通信。可是,如果有可靠的方法来传输密钥,那么用同样的方法就可以安全的传递通信内容。使用对称加密,只是把 如何安全的传输通信内容 转化为了 如何安全的传输密钥 ,本质上并没有解决任何问题。

那么,如何解决密钥传输问题呢 ?

非对称加密

Https 为什么是安全的?(上)

要解决密钥传输问题,我们可以 “不传输” 密钥。

非对称加密通过公私钥完美解决了密钥传输问题。发送方使用公钥进行加密,接收方使用私钥进行解密。公钥可以公开存在于网络中,私钥由接收方保管,不能泄露。私钥是通信安全的重要保障,一旦泄露,加密通信都会被破解。我们最常使用的非对称加密是 RSA 。

看似完美解决密钥传输问题的非对称加密,仍然存在明显的问题。

非对称加密的性能只有对称加密的几百分之一。在浏览器或者即时聊天的场景下,这个速度可能是用户所接受不了的。所以真正使用时,往往是对称加密和非对称加密结合使用,如下图所示。

Https 为什么是安全的?(上)

用非对称加密来保护对称加密的密钥 ,既解决了对称加密的密钥传输问题,又解决了非对称加密速度慢的问题。

现在已经解决了通信内容的加密问题。即使通信内容和加密过的对称密钥被拦截,由于没有私钥,也无法解密查看。那么,现在的通信流程是安全的吗?并不是,目前还有一个核心问题,在缤纷繁杂的互联网上,对方真的是对方吗? 就好比和你语音聊天的萌妹子,其实可能是个抠脚大汉。中间人攻击 就是典型的例子,下面这张图描述了中间人攻击的基本流程。

Https 为什么是安全的?(上)

中间人通过特定技术手段拦截了双方的通信链路,然后调包了发送给发送者的公钥,神不知鬼不觉的拦截并伪造了通信内容。发送方无法确定收到的公钥到底是不是接收方的,接收方也无法识别到消息被篡改。

防止通信内容被篡改认证对方身份 的问题上,此时依然无法解决。

哈希算法

聊到防止通信内容被篡改,很容易想到哈希算法。输入任意长度的内容,计算出固定长度的哈希值 ,也可以叫 散列值消息摘要。哈希算法并不是加密算法,它只是用来校验消息的完整性,例如在官网上下载软件,通常会提供哈希值供用户比对。

常见的 MD4/MD5,包括 SHA1,都已经不再安全,不建议使用。目前推荐使用 SHA2/SHA3。

其实哈希算法很少被直接单独使用在加密通信中,因为它仍然无法解决上一节的问题。如果发送方把消息和消息的哈希值一起发送过来,中间人要做的无非就是把哈希值也替换了,仍然无济于事。这时候就得把哈希算法揉进既有体系中使用。

消息验证码

消息验证码其实和哈希很像,它也是输入任意长度的内容,计算出固定长度的验证码。但是这个计算过程需要一个发送者和接收者共享的密钥。消息认证码是一种和密钥相关联的哈希算法

Https 为什么是安全的?(上)

发送者在发送数据的同时,使用共享密钥计算出消息验证码,和数据一起发送。接收方接收到数据后,使用共享密钥计算出消息认证码,再和发送方发送过来的消息验证码进行比对。比较常见的消息认证码有 HMAC 算法。

由于共享密钥只有通信双方才有,所以即使中间人拦截并修改了消息,接收方通过计算消息认证码也可以识别到篡改。

Https 为什么是安全的? 这可以说是一个高频面试题了。但要完全说明白这个问题,你需要具备一些前置知识。所以在本篇中,暂时不会涉及到 Https 的具体通信流程。

让我们先思考一个问题,如何安全的传输信息

  • 保证传输内容的安全,即不传输明文

  • 防止传输内容被篡改,即可以识别篡改

  • 确认对方真的是对方,即通信双方身份的认证

围绕这几点,我们来看一看常见的加密通信方法以及存在的问题。

最古典的加密

加密技术最初起源于战争。比如著名的 凯撒密码 ,它的原理很简单,如下图所示:

Https 为什么是安全的?(上)

2068242063

将明文字母按照一定的 数字 向右平移,得到相应的 密文 。拿上图来说 ,就是把每个字母都往后挪两位,明文 BAG ,经过变换之后就是 DCH 。这样即使信息被拦截,敌人也无法获知真正的信息。

凯撒密码的密钥就是 字母向右移动的位数(上图中的 2 ) 。密钥和明文的重要程度其实是一样的,丢失密钥和丢失明文并没有什么区别。显而易见,这样的密钥强度太低了。即使后来出现了 乱序对应的字母表 ,仍然很容易被破译。

随着科学技术的进步,依托计算机发展的现代密码学提供了经过数学验证的加密方法和(伪) 随机生成的密钥,使得加密一段信息变得快速而安全。

对称加密

Https 为什么是安全的?(上)

人如其名,对称加密的 加密解密 是对称的,加密密钥和解密密钥是同一个密钥。典型的对称加密算法有 DES 和 AES 。

DES 是 1977 年美国联邦信息处理标准中所采用的一种对称加密,现在已经可以被暴力破解,所以除了考虑到兼容性问题以外,不应该再继续使用 DES 。 此外,还有为了加强 DES 强度的 三重 DES,即将 DES 重复三次。由于其处理速度不高,除了特别重视向下兼容性的情况下,很少被用于新的用途。

现在使用最为广泛的对称加密是在全世界范围内公开选拔出来的 AES 加密。经过全世界密码学家的共同论证,其安全性是毋庸置疑的。那么,我们直接使用 AES 加密通信内容不就可以了吗?

对称加密的一个致命问题就是 密钥的传输问题 。由于加解密过程都使用同一个密钥,所以通信一方必须将密钥首先传给另一方,双方才能正常的进行通信。可是,如果有可靠的方法来传输密钥,那么用同样的方法就可以安全的传递通信内容。使用对称加密,只是把 如何安全的传输通信内容 转化为了 如何安全的传输密钥 ,本质上并没有解决任何问题。

那么,如何解决密钥传输问题呢 ?

非对称加密

Https 为什么是安全的?(上)

要解决密钥传输问题,我们可以 “不传输” 密钥。

非对称加密通过公私钥完美解决了密钥传输问题。发送方使用公钥进行加密,接收方使用私钥进行解密。公钥可以公开存在于网络中,私钥由接收方保管,不能泄露。私钥是通信安全的重要保障,一旦泄露,加密通信都会被破解。我们最常使用的非对称加密是 RSA 。

看似完美解决密钥传输问题的非对称加密,仍然存在明显的问题。

非对称加密的性能只有对称加密的几百分之一。在浏览器或者即时聊天的场景下,这个速度可能是用户所接受不了的。所以真正使用时,往往是对称加密和非对称加密结合使用,如下图所示。

Https 为什么是安全的?(上)

用非对称加密来保护对称加密的密钥 ,既解决了对称加密的密钥传输问题,又解决了非对称加密速度慢的问题。

现在已经解决了通信内容的加密问题。即使通信内容和加密过的对称密钥被拦截,由于没有私钥,也无法解密查看。那么,现在的通信流程是安全的吗?并不是,目前还有一个核心问题,在缤纷繁杂的互联网上,对方真的是对方吗? 就好比和你语音聊天的萌妹子,其实可能是个抠脚大汉。中间人攻击 就是典型的例子,下面这张图描述了中间人攻击的基本流程。

Https 为什么是安全的?(上)

中间人通过特定技术手段拦截了双方的通信链路,然后调包了发送给发送者的公钥,神不知鬼不觉的拦截并伪造了通信内容。发送方无法确定收到的公钥到底是不是接收方的,接收方也无法识别到消息被篡改。

防止通信内容被篡改认证对方身份 的问题上,此时依然无法解决。

哈希算法

聊到防止通信内容被篡改,很容易想到哈希算法。输入任意长度的内容,计算出固定长度的哈希值 ,也可以叫 散列值消息摘要。哈希算法并不是加密算法,它只是用来校验消息的完整性,例如在官网上下载软件,通常会提供哈希值供用户比对。

常见的 MD4/MD5,包括 SHA1,都已经不再安全,不建议使用。目前推荐使用 SHA2/SHA3。

其实哈希算法很少被直接单独使用在加密通信中,因为它仍然无法解决上一节的问题。如果发送方把消息和消息的哈希值一起发送过来,中间人要做的无非就是把哈希值也替换了,仍然无济于事。这时候就得把哈希算法揉进既有体系中使用。

消息验证码

消息验证码其实和哈希很像,它也是输入任意长度的内容,计算出固定长度的验证码。但是这个计算过程需要一个发送者和接收者共享的密钥。消息认证码是一种和密钥相关联的哈希算法

Https 为什么是安全的?(上)

发送者在发送数据的同时,使用共享密钥计算出消息验证码,和数据一起发送。接收方接收到数据后,使用共享密钥计算出消息认证码,再和发送方发送过来的消息验证码进行比对。比较常见的消息认证码有 HMAC 算法。

由于共享密钥只有通信双方才有,所以即使中间人拦截并修改了消息,接收方通过计算消息认证码也可以识别到篡改。

Https 为什么是安全的? 这可以说是一个高频面试题了。但要完全说明白这个问题,你需要具备一些前置知识。所以在本篇中,暂时不会涉及到 Https 的具体通信流程。

让我们先思考一个问题,如何安全的传输信息

  • 保证传输内容的安全,即不传输明文

  • 防止传输内容被篡改,即可以识别篡改

  • 确认对方真的是对方,即通信双方身份的认证

围绕这几点,我们来看一看常见的加密通信方法以及存在的问题。

最古典的加密

加密技术最初起源于战争。比如著名的 凯撒密码 ,它的原理很简单,如下图所示:

Https 为什么是安全的?(上)

2068242063

将明文字母按照一定的 数字 向右平移,得到相应的 密文 。拿上图来说 ,就是把每个字母都往后挪两位,明文 BAG ,经过变换之后就是 DCH 。这样即使信息被拦截,敌人也无法获知真正的信息。

凯撒密码的密钥就是 字母向右移动的位数(上图中的 2 ) 。密钥和明文的重要程度其实是一样的,丢失密钥和丢失明文并没有什么区别。显而易见,这样的密钥强度太低了。即使后来出现了 乱序对应的字母表 ,仍然很容易被破译。

随着科学技术的进步,依托计算机发展的现代密码学提供了经过数学验证的加密方法和(伪) 随机生成的密钥,使得加密一段信息变得快速而安全。

对称加密

Https 为什么是安全的?(上)

人如其名,对称加密的 加密解密 是对称的,加密密钥和解密密钥是同一个密钥。典型的对称加密算法有 DES 和 AES 。

DES 是 1977 年美国联邦信息处理标准中所采用的一种对称加密,现在已经可以被暴力破解,所以除了考虑到兼容性问题以外,不应该再继续使用 DES 。 此外,还有为了加强 DES 强度的 三重 DES,即将 DES 重复三次。由于其处理速度不高,除了特别重视向下兼容性的情况下,很少被用于新的用途。

现在使用最为广泛的对称加密是在全世界范围内公开选拔出来的 AES 加密。经过全世界密码学家的共同论证,其安全性是毋庸置疑的。那么,我们直接使用 AES 加密通信内容不就可以了吗?

对称加密的一个致命问题就是 密钥的传输问题 。由于加解密过程都使用同一个密钥,所以通信一方必须将密钥首先传给另一方,双方才能正常的进行通信。可是,如果有可靠的方法来传输密钥,那么用同样的方法就可以安全的传递通信内容。使用对称加密,只是把 如何安全的传输通信内容 转化为了 如何安全的传输密钥 ,本质上并没有解决任何问题。

那么,如何解决密钥传输问题呢 ?

非对称加密

Https 为什么是安全的?(上)

要解决密钥传输问题,我们可以 “不传输” 密钥。

非对称加密通过公私钥完美解决了密钥传输问题。发送方使用公钥进行加密,接收方使用私钥进行解密。公钥可以公开存在于网络中,私钥由接收方保管,不能泄露。私钥是通信安全的重要保障,一旦泄露,加密通信都会被破解。我们最常使用的非对称加密是 RSA 。

看似完美解决密钥传输问题的非对称加密,仍然存在明显的问题。

非对称加密的性能只有对称加密的几百分之一。在浏览器或者即时聊天的场景下,这个速度可能是用户所接受不了的。所以真正使用时,往往是对称加密和非对称加密结合使用,如下图所示。

Https 为什么是安全的?(上)

用非对称加密来保护对称加密的密钥 ,既解决了对称加密的密钥传输问题,又解决了非对称加密速度慢的问题。

现在已经解决了通信内容的加密问题。即使通信内容和加密过的对称密钥被拦截,由于没有私钥,也无法解密查看。那么,现在的通信流程是安全的吗?并不是,目前还有一个核心问题,在缤纷繁杂的互联网上,对方真的是对方吗? 就好比和你语音聊天的萌妹子,其实可能是个抠脚大汉。中间人攻击 就是典型的例子,下面这张图描述了中间人攻击的基本流程。

Https 为什么是安全的?(上)

中间人通过特定技术手段拦截了双方的通信链路,然后调包了发送给发送者的公钥,神不知鬼不觉的拦截并伪造了通信内容。发送方无法确定收到的公钥到底是不是接收方的,接收方也无法识别到消息被篡改。

防止通信内容被篡改认证对方身份 的问题上,此时依然无法解决。

哈希算法

聊到防止通信内容被篡改,很容易想到哈希算法。输入任意长度的内容,计算出固定长度的哈希值 ,也可以叫 散列值消息摘要。哈希算法并不是加密算法,它只是用来校验消息的完整性,例如在官网上下载软件,通常会提供哈希值供用户比对。

常见的 MD4/MD5,包括 SHA1,都已经不再安全,不建议使用。目前推荐使用 SHA2/SHA3。

其实哈希算法很少被直接单独使用在加密通信中,因为它仍然无法解决上一节的问题。如果发送方把消息和消息的哈希值一起发送过来,中间人要做的无非就是把哈希值也替换了,仍然无济于事。这时候就得把哈希算法揉进既有体系中使用。

消息验证码

消息验证码其实和哈希很像,它也是输入任意长度的内容,计算出固定长度的验证码。但是这个计算过程需要一个发送者和接收者共享的密钥。消息认证码是一种和密钥相关联的哈希算法

Https 为什么是安全的?(上)

发送者在发送数据的同时,使用共享密钥计算出消息验证码,和数据一起发送。接收方接收到数据后,使用共享密钥计算出消息认证码,再和发送方发送过来的消息验证码进行比对。比较常见的消息认证码有 HMAC 算法。

由于共享密钥只有通信双方才有,所以即使中间人拦截并修改了消息,接收方通过计算消息认证码也可以识别到篡改。

部分转自互联网,侵权删除联系

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » Https 为什么是安全的?(上)求职学习资料
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

b2b链

联系我们联系我们