加密、SSL相关等知识梳理

概述

数据在交换的时候,通讯双方都希望彼此之间可以安全、无错误的进行,这时最好的方式是对彼此之间的通讯链路和通讯内容进行加密。为满足这种需求,通常存在两种方法,一种为链路加密,另外一种为端对端的加密。链路加密是指链路的出、入口存在加密设备,通讯数据经过链路时,首先必须经过加密设备完成数据的加密,然后在链路上进行传输,最后在链路的另一端,加密设备完成解密,数据最终到达对端;而端对端加密是指彼此交互数据的加、解密由通讯双方各自完成。它们按照一定的协议、标准等进行协商,数据在各端加密之后再进入到网络链路中进行传输,数据达到对端时由对端完成解密。

本篇文章主要总结端对端加密中最为常用的TLS/SSL以及证书等相关知识,方便自己知识梳理和后续的查阅。

对称加密

对称加密是指加/解密双方通过规定好的算法,同时定义一串共同密钥为双方持有。数据传输时,通讯发送方利用该密钥和算法对通讯数据进行加密并将它发送到链路中;通讯的接收方在收到数据时,使用相同的算法和密钥对数据完成解密,从而正确读取到数据。

对称加密有效的将信息进行了加密,一定程度上阻止了信息裸奔在互联网中,但是其还有以下缺点:

  1. 密钥不能随着用户的不同而不同,从而导致用户可以使用该密钥解密其他用户的数据;
  2. 密钥不存在协商过程,需要面对面提供或者密钥在网络中传输,不适合大规模用户场景,安全性也存在问题;
  3. 数据可能存在被篡改等等;

非对称加密

非对称加密又称现代加密算法,它与对称加密不同之处便是非对称加密方式具备两个密钥,一个为公钥(public key),另外一个为私钥(private key)。数据加解密过程中,如果使用私钥对数据进行加密,那么只有对应的公钥才能解密,反之亦反。

使用非对称加密,由于公钥加密的信息只有私钥才能解密,因此它解决了非对称加密中同样密钥可以解密不同用户信息的缺陷。但是它还是存在以下问题:

  1. 公钥不存在协商过程,需要面对面提供或者密钥在网络中传输;
  2. 用户端使用的密钥过于单一;
  3. 任何拿到该公钥的用户可以攻击服务器,导致服务器无法提供服务;

混合加密

为了解决密钥可能在网络中传输或者面对面提供的问题,在现实场景中存在这样的应用,即:非对称加密+对称加密混合使用。具体做法如下:

  1. 服务器返回公钥给客户端;
  2. 客户端利用该公钥发起与服务器之间对称密钥的协商过程;
  3. 协商完毕之后,客户端利用公钥加密通讯链路,利用协商的对称密钥加密信息;

至此,链路和信息都完成了加密。这一方法解决了以下问题:

  1. 客户端的密钥可以自己定义,解决了密钥单一问题;
  2. 公钥起到的是加密链路的作用,但是对称密钥才起到加密信息的作用;

因此,这种方法比起单纯的对称加密或者非对称加密要安全的多,但是它仍然存在以下不足:

  1. 对称密钥的协商过程需要制定专门的协议,这样导致只能保证在自有的客户端与服务器之间进行,无法进行大众化使用;
  2. 任何拿到该公钥的用户可以攻击服务器,导致服务器无法提供服务;

SSL/TLS

SSL(Secure Sockets Layer)最初是由网景(Netscape)公司创建的,它有三个版本SSLv1、SSLv2和SSLv3,其中SSLv1并没有对外发布。TLS(Transport Layer Security)它是由SSLv3发展而来的,其初始版本为TLSv1.0,目前最新版本已经到了TLS1.2,TLSv1.3版本仍然在草案阶段。SSL/TLS协议都有对应标准化的RFC文档,SSL对应RFC6101,TLS对应为RFC5246。

SSL/TLS也是同时使用非对称加密和对称加密两种方式,此外,SSL/TLS通过引入证书,保证了交互过程的可信任性和完整性;同时,通过规定一系列的交互协议和协商流程,从而完成对称密钥的确定或更新。SSL/TLS交互时,客户端/服务端两方大致会进行以下过程:

A、客户端向服务端发起Hello请求,其中携带支持的加密算法列表、版本、随机数等参数信息;

B、服务端从客户端支持的加密算法列表中选择一项,同时将自己的公钥等信息一并返回给客户端。

C、客户端对服务端返回的信息进行校验,以验证数据的正确性和完整性。然后利用公钥信息再次进行对称加密中密钥的协商过程。

D、最终,服务端和客户端均会拥有协商后的一个对称密钥,该密钥用于后续通讯过程中的数据加解密。

具体的SSL/TLS过程如下图所示:

   https://upload-images.jianshu.io/upload_images/7459167-3acf19fdebc458a6.png

对于使用SSL/TLS加密,它可以解决前面混合加密中需要制定专门协议的问题,但是对于任何持有该证书的客户端都可以发起攻击的问题仍然存在,解决的办法是服务器在上图的消息2中同样发起验证客户端的证书请求,从而达到相互认证的目的。这种场景一般用于金融等安全性较高的领域。

在一般场景中,客户端只会认证服务器,而服务器并不会认证客户端。此时会出现客户端与服务器之间的通讯消息被人截获的场景。例如:用户与服务器进行SSL/TLS的协商过程,但是请求被一个代理截获,该代理返回了自己的证书给用户,后面进行相关的协商过程。与此同时,代理还会发起与服务器的SSL/TLS协商过程,从而也完成了密钥的协商。这样,用户发送过来的信息可以由代理解密出来,然后通过加密发送到服务器。这一过程代理可以随意更改用户的信息。对于这样的情况,用户需要注意浏览器给出的不信任提示。在一般设备与服务器交互时,可以通过将服务端的公钥信息保存到设备内,当与服务器进行连接时,直接利用本地的公钥信息对消息进行解密,这时由于代理公钥与本地公钥不一致将出现错误。

证书的生成命令

首先确保/etc/pki/CA/下存在index.txt和serial文件。

同时保证serial文件中存在一个十六进制数。如果上面那些都没有,可以按照如下命令操作:

touch /etc/pki/CA/index.txt

touch /etc/pki/CA/serial

echo 02 > /etc/pki/CA/serial

CA证书生成

1、生成密钥

openssl genrsa -out ca.key 2048

说明:

A、ca.key中包括了公钥和私钥,可以通过以下命令查看私钥和公钥:

openssl rsa -pubout -in ca.key

openssl rsa -in ca.key -text

2、生成证书签名请求文件

openssl req –new -key ca.key -out ca.csr

说明:

A、包含了公钥信息;

B、CN:填写你的域名或者ip/hostname;

C、证书请求文件以-----BEGIN CERTIFICATE REQUEST ----开头;

D、读取csr文件的内容命令如下:

openssl req -noout -text -in ca.csr

3、生成自签名证书文件

openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt

证书文件为ca.crt

Server端证书生成

服务端的证书需要利用前面生成的ca.crt作为根证书进行签名。操作过程如下:

1、openssl genrsa -out server.key 1024

2、openssl req –new -key server.key -out server.csr

3、openssl ca -in server.csr -out server.crt -cert ca.crt -keyfile ca.key

Client端证书生成

同server端处理类似。

 

可能出现的问题:

1、生成的server.crt或client.crt为空,生成证书时出现打印信息如下:

The mandatory stateOrProvinceName field was missing

这时需要将/etc/pki/tls/openssl.conf中CA下面的match修改为optional,然后重新生成。

2、出现failed to update database   TXT_DB error number 2错误

原因是存在两个相同的证书,此时需要重新生成,并在生成过程中修改Common Name,确保该值与之前设置的不一样。

 

 

说明:本文用于个人知识记录和梳理,参考网络中各位大佬博客。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值