从对称加密和非对称加密讲解HTTP到HTTPS的发展思路

一、传统的HTTP协议

传统的http在进行网络数据传输时,数据信息都是明文的,因此就很容易出现数据在网络的传输过程(中间路由过程)数据被监听或者窃取、替换的危险。因此http是一种不安全的传输协议。

那么就需要对数据进行加密。

主要的加密方式有两种,即对称加密和非对称加密。

对称加密,即站点和浏览器使用共同的密钥对传输的数据进行加密和解密。其优点在于效率比起非对称加密更高。

  1. 监听者若截取经过对称加密的密钥加密后的信息,如不知道通信双方所使用的密钥,那么就无法解密获取网络传输的数据。
  2. 但是单纯使用对称加密的方式仍是不足够安全的,因为不论如何,通信的一端(浏览器)都要在第一次通信中将密钥放到网络中以明文的方式传输(通知)给对端(站点服务器),若被别有用心的监听者截取到了这一次的数据,那么也就获得了通信双端所使用的密钥。

在这里插入图片描述

对称加密
简介:
对称加密算法又称传统加密算法。
加密和解密使用同一个密钥。
加密解密过程:明文->密钥加密->密文,密文->密钥解密->明文


示例:
密钥:www.duoceshi.cn
加密算法:每个字符+www.duoceshi.cn
明文:dcs
密钥为 1时加密结果:abmmx
密钥为 2时加密结果:dwddx


优缺点:
算法公开,计算量小,加密速度快,加密效率高
双方使用相同的钥匙,安全性得不到保证

经典加密算法有三种:

  1. DES(Data Encryption Standard):数据加密标准(现在用的比较少,因为它的加密强度不够,能够暴力破解)
  2. 3DES:原理和DES几乎是一样的,只是使用3个密钥,对相同的数据执行三次加密,增强加密强度。
    (缺点:要维护3个密钥,大大增加了维护成本)
  3. AES(Advanced Encryption Standard):高级加密标准,目前美国国家安全局使用的,苹果的钥匙串访问采用的
    就AES加密。是现在公认的最安全的加密方式,是对称密钥加密中最流行的算法。

非对称加密,即由浏览器保留公钥站点服务器保留私钥,且由公钥加密的数据只能由私钥来解密

但是非对称加密的方式会降低通信的效率,所以一般采用的解决办法是:由浏览器产生一个基于对称加密的密钥A,并使用非对称加密的公钥对密钥A进行加密,然后放到网络环境中传送给站点服务器服务器端使用基于非对称加密的私钥对该加密信息进行解密并获取私钥A,那么在后续的通信过程中,就可以使用效率较高的对称加密方式完成信息的加密传输,即: 只有在浏览器和网站首次商定密钥的时候需要使用非对称加密

但是这样的工作机制实际上还是存在一个安全性的漏洞:浏览器该怎样才能获取到网站的公钥呢?

虽然公钥是属于公开的数据,在网络上传输不怕被别人监听,但是如果公钥被别有用心的监听者篡改了,那么就可以被监听者以对应的私钥进行解密,造成信息的泄露。

在这里插入图片描述

非对称加密RSA
简介:

  1. 对称加密算法又称现代加密算法。
  2. 非对称加密是计算机通信安全的基石,保证了加密数据不会被破解。
  3. 非对称加密算法需要两个密钥:公开密钥(publickey) 和私有密(privatekey)
  4. 公开密钥和私有密钥是一对

特点:
加密的公钥和私钥不同、都是后端服务器生成给到前端的
如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密。
如果用私有密钥对数据进行加密,只有用对应的公开密钥才能解密。
算法强度复杂,安全性依赖于算法与密钥。
加密解密速度慢。


与对称加密算法的对比:
对称加密只有一种密钥,并且是非公开的,如果要解密就得让对方知道密钥。
非对称加密有两种密钥,其中一个是公开的。


RSA 和 AES 双重配合加密
RSA加密复杂安全,但是加解密的性能差,适合对于小数据进行加密
AES加密相对简单,但是加解密的性能强,适合对于大数据进行加密
RSA应用场景: 由于RSA算法的加密解密速度要比对称算法速度慢很多,在实际应用中,
通常采取:数据本身的加密和解密使用对称加密算法(AES)。
用RSA算法加密并传输对称算法所需的密钥。

我们显然也不可能将世界上所有网站的公钥都预置在操作系统当中

由此就引出了CA机构和https协议


二、HTTPS协议

HTTP+ 加密 + 认证 + 完整性保护 =HTTPS
在这里插入图片描述

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL(SecureSocket Layer)和 TLS(Transport Layer Security)协议代替而已。 通常,HTTP 直接和 TCP 通信。

当使用 SSL 时,则演变成先和 SSL 通信,再由 SSL和 TCP 通信了。简言之,所谓 HTTPS,其实就是身披 SSL 协议这层外壳的HTTP。

在采用 SSL 后,HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。SSL 是独立于 HTTP 的协议,所以不光是 HTTP 协议,其他运行在应用层的 SMTP和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界上应用最为广泛的网络安全术。

  • SSL/TLS

    SSL 和 TLS 协议可以为通信双方提供识别和认证通道,从而保证通信的机密性和数据完整性。TLS 协议是从 Netscape SSL 3.0协议演变而来的,不过这两种协议并不兼容,SSL 已经逐渐被 TLS 取代。

  • TLS 握手是启动 HTTPS 通信的过程,类似于 TCP 建立连接时的三次握手。 在 TLS 握手的过程中,通信双方交换消息以相互验证,相互确认,并确立它们所要使用的加密算法以及会话密钥 (用于对称加密的密钥)。可以说, TLS 握手是 HTTPS 通信的基础部分

  • TLS握手过程

    1. "client hello"消息:客户端发送握手请求,包含客户端的TLS版本和密码组合和一个随机字符串
    2. "server hello"消息:服务器回应消息证书、选择的密码组合和一个随机字符串
    3. 客户端验证数字证书,主要检查数字签名、证书链、证书有效期、证书的撤回状态
    4. 客户端向服务端发送一个预主密钥,经服务器公钥加密过。
    5. 服务器使用私钥解密出预主密钥 客户端和服务器使用上述的两个随机数和预主密钥,并通过相同密钥算法生成新密钥用于对称加密
    6. 客户端就绪发送"finish"
    7. 服务器发送"finish" 握手完成

CA机构专门用于给各个网站签发数字证书,从而保证浏览器可以安全地获得各个网站的公钥


【重要的前提】世界上的网站是无限多的,而CA机构总共就那么几家。任何正版操作系统都会将所有主流CA机构的公钥内置到操作系统当中

证书的准备:

① 网站管理员向CA机构进行申请,将自己的公钥提交给CA机构;

② CA机构基于提交的公钥,再加上一系列其他的信息,如网站域名、有效时长等,来制作证书;

③ 证书制作完成后,CA机构会使用自己的私钥将该证书加密并返还给网站。

不难看出,证书主要是对公钥的保护。

B/S通信过程:

① 每当有浏览器请求网站时,网站便会将CA机构返还的(含网站自身公钥且被CA机构私钥加密的)证书发送给浏览器;

② 浏览器端通过扫描自身操作系统内置的CA机构的公钥,只要有任何一个公钥能够正常解密出数据,也就是网站的公钥,就说明它是合法的。

而如果无法解密成功,则说明此段加密数据并不是由一个合法的CA机构使用私钥加密而来的,有可能是被篡改了,于是会在浏览器上显示一个异常界面,提示”您的连接不是私密连接“。

③ 若顺利得到了网站的公钥,那么浏览器就会将自己产生的(基于对称加密的)密钥A使用该公钥进行非对称加密并交由网站服务器端使用网站自己的私钥进行解密,这样就成功协商了B/S双端进行安全数据传输所使用的密钥。

可见

  1. CA机构与网站间的非对称加密主要是为了保护网站要发送给浏览器的公钥;
  2. 而网站与浏览器之间的非对称加密主要是为了保护它们在后续的高效安全数据传输过程中使用的对称加密密钥

但是到了这一步,目前的流程还存在一些安全性问题。

因为每一家CA机构都会给成千上万的网站制作证书,假如攻击者知道abc.com使用的是某家CA机构的证书,那么他也可以同样去这家CA机构申请一个合法的证书,然后在浏览器请求abc.com时对返回的加密证书数据进行替换,使得浏览器得到的是虚假的公钥,后期攻击者就可以拦截浏览器使用虚假公钥加密的数据并使用与之对应的私钥进行解密。示意图如下:
在这里插入图片描述

可以看到,由于攻击者申请的证书也是由正规CA机构制作的,因此这段加密数据当然可以成功被解密。

也正是因为这个原因,所有CA机构在制作的证书时除了网站的公钥外,还要包含许多其他数据,用来辅助进行校验,比如说网站的域名就是其中一项重要的数据

【数字证书】

解决中间人攻击的方法是通过受信任的第三方交换公钥,具体做法就是服务器不直接向客户端发送公钥,而是要求受信任的第三方,也就是证书认证机构 (Certificate Authority, 简称 CA)将公钥合并到数字证书中,然后服务器会把公钥连同证书一起发送给客户端,私钥则由服务器自己保存以确保安全。

【证书内容】

  1. 证书所有者的公钥
  2. 证书所有者的专有名称
  3. 证书颁发机构的专有名称
  4. 证书的有效起始日期
  5. 证书的过期日期
  6. 证书数据格式的版本号
  7. 序列号,这是证书颁发机构为该证书分配的唯一标识符 、

【数字签名】

确保数据发送者的合法身份,也可以确保数据内容未遭到篡改,保证数据完整性。

生成过程

  1. 服务器对证书内容进行信息摘要计算 (常用算法有 SHA-256等),得到摘要信息,再用私钥把摘要信息加密, 就得到了数字签名
  2. 服务器把数字证书连同数字签名一起发送给客户端
  3. 客户端用公钥解密数字签名,得到摘要信息
  4. 客户端用相同的信息摘要算法重新计算证书摘要信息,然后对这两个摘要信息进行比对,如果相同,则说明证书未被篡改,否则证书验证失败

【证书链(certificate chain)】

证书链,也称为证书路径,是用于认证实体合法身份的证书列表,具体到 HTTPS 通信中,就是为了验证服务器的合法身份。之所以使用证书链,是为了保证根证书 (root CA certificate)的安全,中间层可以看做根证书的代理,起到了缓冲的作用。

证书链从根证书开始,并且证书链中的每一级证书所标识的实体都要为其下一级证书签名,而根证书自身则由证书颁发机构签名。客户端在验证证书链时,必须对链中所有证书的数字签名进行验证,直到达到根证书为止。

同样是刚才的例子,如果证书中加入了网站的域名,那么攻击者就只能无功而返了。因为,即使加密数据可以被成功解密,但是最终解密出来的证书中包含的域名和浏览器正在请求的域名对不上,那么此时浏览器仍然会显示异常界面。示意图如下:
在这里插入图片描述

方案设计到这里,其实我们的网络传输就已经做到足够的安全了。当然,这其实也就是https的工作原理。

那么回到一开始的问题:https使用的是对称加密还是非对称加密呢?答案也很明显了,https使用的是对称加密与非对称加密相结合的方式。


MD5

MD5消息摘要算法,属Hash算法一类。MD5算法对输入任意长度的消息进行运行,产生一个128位的消息摘要(32位的数字字母混合码)。

(一个MD5理论上的确是可能对应无数多个原文的,因为MD5是有限多个的而原文可以是无数多个。比如主流使用的MD5将任意长度的“字节串映射为一个128bit的大整数。也就是一共有2128种可能,大概是3.4*1038,这个数字是有限多个的,而但是世界上可以被用来加密的原文则会有无数的可能性)

MD5加密的特点:

1、压缩性:任意长度的数据,算出的MD5值长度都是固定的(相当于超损压缩)。

2、容易计算:从原数据计算出MD5值很容易。

3、抗修改性:对原数据进行任何改动,哪怕只修改1个字节,所得到的MD5值都有很大区别。

4、弱抗碰撞:已知原数据和其MD5值,想找到一个具有相同MD5值的数据(即伪造数据)是非常困难的。

5、强抗碰撞:想找到两个不同的数据,使它们具有相同的MD5值,是非常困难的。

MD5用途:
  1. 防止被篡改:

1)比如发送一个电子文档,发送前,我先得到MD5的输出结果a。然后在对方收到电子文档后,对方也得到一个MD5的输出结果b。如果a与b一样就代表中途未被篡改。

2)比如我提供文件下载,为了防止不法分子在安装程序中添加木马,我可以在网站上公布由安装文件得到的MD5输出结果。

3)SVN在检测文件是否在CheckOut后被修改过,也是用到了MD5.

  1. 防止直接看到明文:

现在很多网站在数据库存储用户的密码的时候都是存储用户密码的MD5值。这样就算不法分子得到数据库的用户密码的MD5值,也无法知道用户的密码。(比如在UNIX系统中用户的密码就是以MD5(或其它类似的算法)经加密后存储在文件系统中。当用户登录的时候,系统把用户输入的密码计算成MD5值,然后再去和保存在文件系统中的MD5值进行比较,进而确定输入的密码是否正确。通过这样的步骤,系统在并不知道用户密码的明码的情况下就可以确定用户登录系统的合法性。这不但可以避免用户的密码被具有系统管理员权限的用户知道,而且还在一定程度上增加了密码被破解的难度。)

  1. 防止抵赖(数字签名):

这需要一个第三方认证机构。例如A写了一个文件,认证机构对此文件用MD5算法产生摘要信息并做好记录。若以后A说这文件不是他写的,权威机构只需对此文件重新产生摘要信息,然后跟记录在册的摘要信息进行比对,相同的话,就证明是A写的了。这就是所谓的“数字签名”。

  • 3
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

狱典司

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值