HTTPS工作原理详解&加密(TLS握手)过程

HTTPS概念

HTTPS就是一个有安全保障的HTTP通信,我们都知道,http是明文传输的,http报文是人肉眼就可识别的ASCII码,在通信过程中,http报文很容易被黑客窃听、篡改、伪造,而在互联网交易中,我们必须保证通信安全,所有就需要像https这样有安全层的协议。

那么,https是怎么保障通信安全的呢?什么样的通信可以被称为是安全的,安全的定义是什么?

通常,如果通信过程具备了四个特性,就可以认为是“安全”的,这四个特性是:机密性、完整性、身份认证和不可否认。而HTTPS正是实现了这四个特性,所以被认为是“安全的”。

HTTPS和HTTP的区别
  • http是超文本传输协议,信息是明文传输,https则是具有安全性的加密传输协议;
  • http是基于tcp协议,tcp三次握手之后即可开始http通信;https是在http与tcp之间加了一个SSL/TLS安全层,在TCP握手之后,还要进行TLS握手,才可以开始通信;
  • http没有身份认证,存在安全隐患;https使用证书系统来进行身份认证,使用https的网站需要到CA申请证书,一般免费证书较少,因而需要一定费用;
  • http默认端口是80,https默认端口443
HTTPS的基本概念

SSL:安全套接层,在OSI模型中处于第5层(会话层);
TLS:1999年,SSL被改名为TLS(传输层安全),正式标准化,所以TLS1.0实际上就是SSLv3.1,目前应用的最广泛的TLS是1.2。

TLS综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术;

浏览器和服务器在使用TLS建立连接时需要选择一组恰当的加密算法来实现安全通信,这些算法的组合被称为“密码套件”;

TLS的密码套件命名:密钥交换算法+签名算法+对称加密算法+摘要算法
如:ECDHE-RSA-AES256-GCM-SHA38

含义:握手时使用ECDHE算法进行密钥交换,用RSA签名和身份认证,握手后的通信使用AES对称算法,密钥长度256位,分组模式是GCM,摘要算法SHA384用于消息认证和产生随机数

机密性实现机制

前置知识

为什么要有机密性?

因为http是明文传输的,明文的意思就是头部字段等信息直接使用ASCII码这种人能看懂的符号传递,很容易被窃取和篡改。当我们使用http进行金钱方面的交易时,是毫无安全性而言的。

实现机密性最常用的手段是“加密”,就是把消息用某种方式转换成谁也看不懂的乱码,只有掌握特殊“钥匙”的人才能再转换出原始文本。

这里的“钥匙”就叫做“密钥”,加密前的消息叫“明文”,加密后的乱码叫“密文”,使用密钥还原明文的过程叫“解密”,是加密的反操作,加密解密的操作过程就是“加密算法”。

按照密钥的使用方式,加密可以分为两大类:对称加密和非对称加密

对称加密

对称加密:加密和解密时使用的密钥都是同一个,是“对称”的。只要保证了密钥的安全,那整个通信过程就可以说具有了机密性。

目前常用加密算法:AES(高级加密标准),密钥长度可以是128、192或256。

对称算法还有一个“分组模式”的概念,它可以让算法用固定长度的密钥加密任意长度的明文,把小秘密(即密钥)转化为大秘密(即密文),常用的是GCM、CCM和Poly1305。

非对称加密

对称加密有一个缺点:就是无法解决“密钥交换”问题,因为在对称加密算法中只要持有密钥就可以解密。如果你和网站约定的密钥在传递途中被黑客窃取,那他就可以在之后随意解密收发的数据,通信过程也就没有机密性而言了;

所以,就出现了非对称加密,也叫公钥加密算法。它有两个密钥,一个叫“公钥”(public key),一个叫“私钥”(private key)。两个密钥是不同的,“不对称”,公钥可以公开给任何人使用,而私钥必须严格保密;

公钥和私钥有个特别的“单向”性,虽然都可以用来加密解密,但公钥加密后只能用私钥解密,反过来,私钥加密后也只能用公钥解密。非对称加密可以解决“密钥交换”的问题。网站秘密保管私钥,在网上任意分发公钥,你想要登录网站只要用公钥加密就行了,密文只能由私钥持有者才能解密。而黑客因为没有私钥,所以就无法破解密文。

RSA是最著名的非对称加密算法,它的安全性基于“整数分解”的数学难题,使用两个超大素数的乘积作为生成密钥的材料,想要从公钥推算出私钥是非常困难的。

ECC是非对称加密里的“后起之秀”,它基于“椭圆曲线离散对数”的数学难题,使用特定的曲线方程和基点生成公钥和私钥,子算法ECDHE用于密钥交换,ECDSA用于数字签名。

HTTPS的加密方式

混合加密
  • 在通信刚开始的时候使用非对称加密算法,比如RSA、ECDHE,首先解决密钥交换的问题;【用随机数产生对称加密算法使用的“会话密钥”(session key),再用公钥加密。因为会话密钥很短,通常只有16字节或32字节,所以慢一点也无所谓。对方拿到密文后用私钥解密,取出会话密钥。这样,双方就实现了对称密钥的安全交换。】
  • 后续全都使用对称加密进行通信

完整性实现机制

完整性用来保证通信数据没有被篡改过。

摘要

实现完整性的手段主要是摘要算法,也就是常说的散列函数、哈希函数。

摘要算法保证了“数字摘要”和原文是完全等价的。所以,我们只要在原文后附上它的摘要,就能够保证数据的完整性。

身份认证和不可否认

数字签名

数字签名就是经过私钥加密后的摘要。
在这里插入图片描述#### 数字签名

还有一个问题,就是黑客冒充某网站给客户端一个假的公钥,如果你拿到了假的公钥,混合加密就完全失效了。所以,为了解决公钥的信任问题,需要引入“数字证书”。
在这里插入图片描述

通信过程

服务器需提供:

  • 数据内容(会话密钥加密)
  • 数字签名(服务器私钥加密后的摘要)
  • 数字证书(CA私钥加密的服务器公钥)

客户端收到后:

  • 先用CA公钥解密证书,把服务器公钥拿出来
  • 使用服务器公钥解密数字签名,得到摘要
  • 使用摘要算法对内容进行计算,算出的摘要与刚才解密出的摘要进行对比,如果一模一样,说明数据是完整的,没被篡改过

TLS握手过程

在http协议中,TCP三次握手成功后,浏览器会立即发送请求报文;但是https协议,它还需要另一个握手过程(TLS握手),在TCP上建立安全连接,之后才是收发报文。TLS握手的主要目的是使用非对称加密交换对称密钥,这个对称密钥是由三个随机数生成的。

TLS握手一共四个回合

  1. 客户端发出请求
    • 支持的协议版本,比如TLS1.0版
    • 一个客户端生成的随机数,稍后用于生成“会话密钥”
    • 支持的密码套件(支持的加密方法)
  2. 服务器回应
    • 确认使用的加密通信协议版本,比如TLS1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信
    • 一个服务器生成的随机数,稍后用于生成“会话密钥”
    • 确认使用的加密方法,比如RSA公钥加密
    • 服务器证书
  3. 客户端回应
    客户端收到服务器回应以后,开始走证书链逐级验证,确认证书的真实性,如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书可以过期,就会向访问者显示一个警告,尤其选择是否还要继续通信:
    在这里插入图片描述如果证书真实有效,从证书中拿出服务器公钥,向服务器发送下面三项信息:
  • 一个用服务器公钥加密随机数(pre-master key),防止被窃听
  • 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送
  • 客户端握手结束通知(Finished),表示客户端的握手阶段已经结束。这一项是把之前所有发送的数据做个摘要(hash值),再加密一下,供服务器校验
  1. 服务器的最后回应
    服务器收到客户端的第三个随机数pre-master key之后,计算生成本次会话所用的“会话密钥”。

然后,向客户端最后发送下面信息:

  • 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送(Change Cipher Spec)
  • 服务端握手结束通知(Finished),表示服务端的握手阶段已经结束。这一项是把之前所有发送的数据做个摘要(hash值),再加密一下,供客户端校验。
  • 4
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值