SSL/TLS 介绍以及如何利用openssl生成证书

介绍

SSL:Secure Socket Layer 安全套接字层。

TLS:Transport layer Security 传输层安全性,是一种加密协议。

发展历程

到2020年,SSL以及TLS1.0,TLS1.1已被弃用

TLS用在哪里?

为什么用TLS?

Authentication:通信双方可以确认双方的身份,不被黑客拦截信息伪造身份。

Confidentiality:通信的内容经过加密,更加安全,不被授权的用户无法识别内容。

Integroty:通讯内容可以查出是否被破坏。

TLS是怎么工作的?

两阶段:

  1. 握手阶段,双方通过非对称加密通信,建立连接,传输用于加密数据的对称秘钥

  1. 通信阶段,双方通过对称秘钥加密数据,互相通信

为什么TLS同时采用了非对称加密和对称加密呢?

  1. 只用对称加密的话,我们不能保证双方在商量秘钥是什么的情况下秘钥在网络传输中不被泄露,也不能确认信息是否被修改了。

  1. 如果只用非对称加密的话,它比对称加密的效率要低上成千上万倍。

对称密码学

一般对称加密方式,发送方和接收方共享一个秘钥,发送方利用秘钥加密,接收方利用秘钥解密。

上述的加密,黑客可以对信息拦截并进行位翻转来进行攻击。请看下面的例子。

由于信息可能会被篡改,所以现在还需要进行验证信息的真伪。

所以要为传输的信息附上验证信息。

带有验证信息的对称加密过程:
  1. 根据秘钥 secret key和初始向量 IV 通过对称加密算法,对明文进行加密。

  1. 将秘钥,初始向量,密文通过MAC算法,生成HASH串,作为验证code。使用MAC算法时我们还可以添加一些附加信息,这些信息是明文的,且应当是双方知道的。

  1. 将验证code附加到密文上,一起传输。

带有验证信息的解密过程:
  1. 将验证信息取出。

  1. 将秘钥 ,IV,附加信息,密文通过MAC算法得到新的hash串。

  1. 比较两个hash串是否一致,一致就可以通过秘钥和IV进行解密得到明文

现在还存在一个问题?双方是怎么共享秘钥的?

为了保证传输过程中秘钥的安全性,我们通过非对称加密来共享秘钥。非对称加密的具体流程在下面有专门的讲述。

首先双方生成各自的私钥和公钥,生成的算法有很多,RSA算法,ECC算法(与椭圆曲线有关)

下面介绍的是Diffile-Hellman Ephemeral(DHE)

g是一个公知的幂的底,p为公知的一个模。g,p是双方都认可的一个值

双方各自选择一个值作为自己的私钥,比如说发送方为a,接收方为b。

然后双方计算出各自的公钥A,B,并且传送给对方。

双方收到后通过计算可以得到S,这个值双方计算出来是一样的。如何计算看下图。

双方就可以通过S这个共享秘钥来进行数据加密。

现在还存在一个问题,S的长度是不固定的,我们还需要用HKDF进行一次转换,把它转换为确切长度的key。

HKDF(H mark base key derivation functon)

p,g,A,B对公众来说都是已知的,黑客是否可以通过p,g,A,B算出a,b的值来呢?

我们可以看到 p有2048bit,a,b各有256bit。

算法很简单,但是很难算出来

但是如果我们多次对话都用同样的a,b的话,早晚会被算出来

所以我们应使用临时秘钥,每一次会话都重新商议秘钥

成熟的非对称加密算法有RSA,EEC

RSA:类似于刚才说的那种生成私钥和公钥的方法。

EEC: 在生成公钥和私钥时,用到的椭圆曲线。具体如何不展开。

下面是EEC,RSA秘钥位数与安全级别的对比

非对称加密算法

通过DHE,ECDHE实现隐秘的共享秘钥的交换

加密是怎么运转的

双方之间公钥的传输,在这个过程中,public key可以被黑客拦截,伪造public key重新发送给接收方。此时当接收方用伪造的public key进行加密时,黑客便可以通过他的私钥进行解密。造成这样现象的原因是因为public key 没有任何的验证信息,接收方无法确认public key到底来自谁。

所以现在我们需要加入适当的验证信息,通过可靠的第三方认证机构,生成数字证书

CA证书的签发过程
  1. 创建一个certificate siging request(CSR),这个CSR中包含public key和发送方的一些身份信息。

  1. 发送方用private key 对CSR进行数字签名。

  1. CA接收到后,根据csr中的public key 对签名进行解签,并且验签。

  1. CA认证完成后,对内容用CA私钥进行签名,最后将签名以及明文的信息返回给申请者。

数字证书的验证

发送方发送证书到接收方,接受方通过CA的public key进行验签便可知道是否安全。

在此过程中,如果黑客修改了证书内容,那么接受方在验签的过程中就不会通过。

黑客因为不知道CA的私钥所以也无法伪造证书。

数字签名的过程

对信息进行HASH得到摘要,用私钥对摘要进行加密,最后将签名附在原文上。

验签过程

收到信息后,将原文和签名分开。

用公钥对签名解签得到摘要1。

原文按照相同的hash算法得到摘要2。

比较摘要1和摘要2。

Chain of trust

最上层为的CA的证书是自签的。

根CA对下面的CA进行签名。一层一层。

TLS 1.3 HandShake

  1. client 发送hello message ,主题内容包括支持的tls版本,支持的密码套件(基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」),支持的非对称加密共享秘钥的交换策略,公钥的类型,以及支持的签名算法,这个用于对handshake过程中的签名,其中包括一个随机数1。

这是TLS 的第一次握手。

  1. server发送hello message,内容包括

这是TLS的第二次握手,server会选择tls版本,密码套件,共享秘钥的交换组,公钥的类型,对client证书的请求(这个是可选的,当server需要验证client的身份时),然后server会生成一个随机数2,并将上述的信息,连同server的证书,握手上下文(从开始握手到对client证书的请求之间的上下文)与服务器证书的签名(签名过程用server的private key和client 提供的签名算法进行签名),握手上下文+server证书+verify的mac(先hash再通过选择的AEAD套件中的mac算法进行mac运算),发送回去。

Server Certificate + Certificate verify +Server Finish 保证了在handshake过程中的安全。

  1. client收到server的确认信息后,通过根证书来验证签名,并确定是否信息被修改。

  1. 这是TLS的第三次握手,client验证完后会生成随机数3,并用server的公钥进行了加密,服务器收到后会用私钥解密得到随机数3,此时,双方都有了三个随机数,这三个随机数生成会话密钥,将自身的证书,随机数3,verify,mac,change cipher Spec(告诉服务端后续将进行加密通讯)发送到server。

  1. server同样发送change cipher Spec(告诉客户端后续将进行加密通讯)和mac到client

后续就是利用会话密钥进行会话的过程了。

Resumption & Pre-Shared-Key

但是服务器在与客户端会话时,并不会总是采用上述的握手方式,上述方式太过繁琐。有时他们会通过pre shared key来进行简单的握手。

原理是在上一次握手之后,通信双方已经彼此认识,因此不需要再进行身份认证。

  1. 服务器可以向client发送一个或多个session ticket(会话凭证),这个凭证可以在下一次握手时使用,PSK identity是对PMS的标识。

  1. 下一次握手时,client会发送hello message 内容有session ticket list,以及相关的PSK模式,等信息。

  1. server 发送hello message,内容包括选定的PSK,以及mac

  1. client确认发送回mac。

可以看出这次握手没有证书的验证过程,只是利用了上次握手确认的详细信息,此次握手仅通过PSK来恢复上次现场。

在这基础上,我们可以在handshake的hello message 的发送中附加上要传输的数据。

TLS1.3与1.2的对比。

如何用Openssl来签发证书和创建私钥?

  1. 在本地模拟CA认证机构,先为自己创建一个私钥,以及自签证书(签名时用的自己的私钥)

openssl req -x509 -newkey rsa:4096 -days 365 -nodes -keyout ca-key.pem -out ca-cert.pem -subj "/C=CH/ST=GANSU/L=LANZHOU/O=LZU/OU=HIGHSCHOOL/CN=*.tech.xiaobai/emailAddress=techschool@gmail.com"
req 代表生成证书请求 -x509 可以理解为一种证书的形式,-newKey 用来创建私钥 rsa:4096表示用
rsa算法生成4096位的私钥。-days 365为证书的有效期 -nodes是我们在开发时不对私钥文件加密,
-keyout 私钥的输出文件,-out 证书的输出文件,
-subj 为创建证书时的附件信息,包括”国家,地区,组织,机构,邮箱等等“。

openssl x509 -in ca-cert.pem -noout -text 用来将证书转为人类可识别的格式
x509格式 -in 指定证书文件 -noout 指不将格式化的内容输出为文件 -text 文本形式显示
  1. 为server端创建私钥并签名一个certificate signing request (CSR)。

openssl req -newkey rsa:4096 -nodes  -keyout server-key.pem  -out server-req.pem -subj "/C=CH/ST=GANSU/L=LANZHOU/O=PC BOOK/OU=computer/CN=*.pcbook.com/emailAddress=pcbook@gmail.com"
因为我们这里并不是生成证书,所以没有-x509参数,而是生成了私钥和带有附加信息的CSR。
  1. CA验证CSR并且签名。

openssl x509 -req -in server-req.pem -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem
x509 证书形式, -req 来生成证书, -in 要签名的证书, -CA CA的证书,-CAkey ca用来签名的秘钥, -CAcreateserial 
每次签名生成一个唯一的序列号。
-out 生成的证书

  • 2
    点赞
  • 26
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值