openssl

最新推荐文章于 2024-04-14 07:13:37 发布

wangzhenyu177

最新推荐文章于 2024-04-14 07:13:37 发布

阅读量1k

点赞数

文章标签： openssl

本文链接：https://blog.csdn.net/wangzhenyu177/article/details/78122812

版权

openssl 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

0 目录

文章目录

0 目录
1 点对点的加密通信过程
2 openssl命令实现上述过程

1 点对点的加密通信过程

一个加密通信过程，应当具备：
1、数据来源身份合法性（发送方不能被第3方伪装）；
2、数据内容完整性（数据内容不能被第3方篡改）；
3、数据保密性（不能被第3方看到或“看懂”）。

下面以Alice为发送数据者、Bob为接受者、Eve为窃听者为例说明¹：

1.1 数据完整性

Alice向Bob发送数据时，通过单向加密得到数据的特征码，并把该特征码附在数据后面一并发送。Bob收到后只要用同样算法提取特征码，若与发来的特征码相同，则说明数据没有被篡改。

这里写图片描述

Alice把数据和数据的特征码作为一个整体发送给Bob，特征码确保数据若被篡改就会被发现：

这里写图片描述

1.2 来源合法性

上述步骤不能确保发送者Alice不被窃取者Bob冒充：

这里写图片描述

由此，Alice在发数据时，使用自己的私钥（通信前双方已约定好使用哪种公钥加密算法），加密数据的特征码。由于公钥公开，Bob有Alice的公钥，从而可以解密加密后的特征码，只要能解密，说明确实是由Alice私钥加密的，验证了来源²。

这里写图片描述

发送的数据变为：

这里写图片描述

1.3 数据保密性

此时，数据来源不会被冒充，也不会被篡改，但Eve还是可以看到数据的：

这里写图片描述

所以Alice要把数据及用Alice私钥加密后的特征码作为一个整体，用对称加密算法加密：

这里写图片描述

且要把对称加密算法的密钥传递给Bob。为防止该密钥被窃取，应当用Bob的公钥加密（这样只有Bob才能能解密）：

这里写图片描述

于是Alice发给Bob的信息变为：

这里写图片描述

Bob接收到信息，进行：
1、用自己的私钥解密，获得对称加密算法的密钥；
2、用对称加密算法的密钥解密，获得数据内容和Alice私钥加密过的数据特征码（Bob获得了数据内容）；
3、用Alice的公钥解密，获得数据特征码（如能解密，则Bob验证了发送者是Alice）；
4、使用和Alice相同的单向机密算法加密数据内容，对比Alice发来的特征码（如一致，说明数据未被篡改）。

1.4 CA

CA是通信双方都信任的实体，用于颁发证书验证通信方身份。

1.4.1 为何要有CA

标题1.3最后展示的通信过程看上去“无懈可击”。因为数据、算法的密钥等都是以密文传递，而公钥加密算法的公钥本来就是可公开的。

但是，正是因为这个过程中，双方都需要先获得对方的公钥来完成加密、解密，造成了漏洞。
如果Alice和Bob从没见过面，Eve在他们互相获取公钥时：
1、对Alice，冒充Bob，获取到了Alice的公钥，并把自己的公钥给Alice；
2、对Bob，冒充Alice，获取到了Bob的公钥，并把自己的公钥给Bob。

造成的结果：
Alice端：发送的数据，Eve收到后只要执行正常的解密步骤，全都可以看到。因为Alice是用Eve的公钥加密了对称加密算法的密钥。而Alice无法发觉。
Bob端：Eve随意篡改数据（或只是查看）后，再按上述的加密过程（其中加密数据特征码用自己的私钥）加密发给Bob。Bob也无法发觉³。

这就是所谓中间人攻击，整个过程变为：

这里写图片描述

Bob对Alice的回复，也可这样进行。所有数据都会经过Eve，可查看也可篡改。
所以需要一个双方都信任的第三方实体——CA，来确认对方身份，以保证通信双方的公钥互相正确获得。

1.4.2 CA如何发挥作用

申请者向CA提请自己的各种信息和公钥，CA经过考察、核实申请者，如同意则向申请方颁发证书（证书上有申请者提交的各信息包括公钥⁴）。通信时只要将证书发给对方（前提是对方也信任该CA），对方即可确认通信者的身份和公钥。

申请者拿到证书后，如何发挥作用？
同上述通信过程一样，CA是把证书提取特征码、私钥加密特征码并附在证书后提供给申请者的。
如果Alice有了CA颁发的证书，通信时就把证书发给Bob。Bob必须先获取到CA的公钥，才可以验证Alice的证书的来源合法性（即是否是CA颁发的）和数据完整性（注意这里无需数据保密性了，证书中的Alice的公钥本来就是要公开的）。而后Bob还要检查内容是否正确（即是否是Alice的证书、是否过期等等），如正确，就可使用证书中记录的Alice的公钥了，公钥分发完成。

这样，Bob就需要先有CA的公钥。CA会先给自己颁发一个自签证书（内含CA的各信息和公钥）来证明自己。只要获取到CA的自签证书即可。显然这个自签证书就不要再用网络发送了，最保险的比如当面获取⁵。

证书有有效期，获取到证书后，在有效期内，通信变为：
先发送证书给通信方（假如双方都已从CA处获取到CA的自签证书，即有CA的公钥）：

这里写图片描述

此时，如果Eve想冒充Alice，就需要向CA申请证书，当然他无法以Alice的名义申请到，从而无法把自己的公钥冒充为Alice的提供给Bob。

这样双方获取到对方公钥，仍按1.3描述步骤进行加密通信：

这里写图片描述

1.5 服务的加密通信过程

上述的加密通信过程都是手动的，而服务的加密通信当然需要自动完成。
基于ssl通信的大致步骤，比如https：
1、客户端发出通信请求，与服务端商定通信细节（如采用何种加密算法）；
2、服务端回给客户端，确定通信意向；
3、服务端将证书发给客户端，客户端验证证书⁶，这样客户端获取了服务端的公钥；
4、客户端把对称加密算法的密钥（用于加密数据，该密钥一般为生成的随机数）用服务端的公钥加密，发给服务端；
5、服务端解密获得客户端发来的对称加密算法密钥，用此密钥加密网页，发给客户端。
不断执行第5步响应用户请求，直至通信结束。

前4步可看作是在“握手”，第5步是通信。只是大致步骤。

2 openssl命令实现上述过程

OpenSSL是ssl（security socket layer，安全套接字层，位于应用层与传输层之间）的开源实现⁷。共3组件：
1、加密解密库（包含各加密算法）；
2、加密通信库（完成标题1.3所述的过程）；
3、openssl命令工具

前两者用于开发使用，本文不述。下面使用openssl命令模拟加密通信过程。

2.1 PKI

先说下这个概念。

以CA为核心，生成的一套安全架构，就是PKI（public key infrastructure，公钥基础设施）。
包含4组件：
1、签证机构（CA）。用于签发证书。
2、注册机构（RA）。用于接收注册申请，但没权力签发证书。
3、证书吊销列表（CRL）。用于吊销证书⁸。
4、供他人下载的申请的证书的存取位置（CB）

标题1介绍CA时只是作为一个实体，而CA运作时的用到的组件应当是上述4组件。下面使用openssl实现时，会体现到。

2.2 openssl命令使用

简单来说，命令格式：openssl command [options]

其中command为openssl各子命令：

Standard commands
asn1parse         ca                ciphers           cms               
crl               crl2pkcs7         dgst              dh                
dhparam           dsa               dsaparam          ec                
ecparam           enc               engine            errstr

……

各子命令有不同的选项。
其中有两类特殊子命令：dgst提供了单向加密算法；enc提供了各对称加密算法。

Message Digest commands (see the `dgst' command for more details)
md2               md4               md5               rmd160            
sha               sha1

Cipher commands (see the `enc' command for more details)
aes-128-cbc       aes-128-ecb       aes-192-cbc       aes-192-ecb       
aes-256-cbc       aes-256-ecb       base64            bf

……

这些子命令都有man文档。

2.2.1 对称加密

常用选项：

选项	意义
-e	加密
-d	解密
-a	保存为base64格式⁹，否则是二进制的
-salt	添加杂质参与运算，使密码更复杂，默认就是使用的。至于算法是如何利用这些杂质运算的，这取决于算法，使用者无需关心
-in	指定要处理的文件（可能是加密也可能是解密，取决于使用-e还是-d）
-out	处理完成的文件存放位置

比如使用des3算法，加密字符串“123456”：

[root@localhost ~]% echo 123456 > test.data						# 明文存储在文件test.data
[root@localhost ~]% openssl enc -e -des3 -in test.data -out test.encrypt -salt -a
enter des-ede3-cbc encryption password:							# 提示输入加密算法的密钥，笔者这里键入的密钥也是123456
Verifying - enter des-ede3-cbc encryption password:				# 确认密钥

[root@localhost ~]% cat test.encrypt							# 加密后的字符串	
U2FsdGVkX1/Zh+yHSXpGv6wmT/gGoUsJ

解密时，只需使用解密选项-d，-in处理文件和-out处理完成文件换下即可：

[root@localhost ~]% openssl enc -d -in test.encrypt -out test2.data -des3 -a	# 这里如果不使用选项-a指定文本格式，则达不到预期结果
enter des-ede3-cbc decryption password:											# 这里输入密钥“123456”
[root@localhost ~]% cat test2.data												# 解密结果
123456

2.2.2 单向加密

单向加密只需指定加密算法和指定文件即可：

[root@localhost ~]% openssl dgst -md5 test.data 
MD5(test.data)= f447b20a7fcbf53a5d5be013ea0b15af

在/etc/passwd中存放的用户密码，是由openssl的子命令passwd加密而来，实际上也是单向加密：

[root@localhost ~]% head -1 /etc/shadow
root:$6$rM6GJUnZsJZzNfGj$LR4fLT7edLf.cMowtLaM4Q77SfFFLtORJOQxDXHbbXPELb.z0Pnggtev5xBYmtXELNR5GUdqK0ERJXKgtm89f0:17417:0:99999:7:::

由冒号隔开的各字段，第2段为密文。
密文又由“$”分3段：
1、为数字，表示使用何种单向加密算法；
2、salt，加密时用到的杂质¹⁰；
3、salt与密码明文一起加密而成的密文。

演示：

[root@localhost ~]% openssl passwd -1 -salt 123456 test.data 
$1$123456$PbX.DOCPep372vOc6fIrQ/								# 从加密结果可以看到，杂质就是指定的“123456”，不过实际使用时最好使用随机数，这样手动指定不安全

2.2.2.1 随机数

附带提一下随机数。
$RANDOM在bash中，是0至32767之间的一个随机数字。
openssl也能成随机数（含字母），使用子命令rand即可：

[root@localhost ~]% openssl rand -base64 12				# -base64指定处理结果为base64格式，数字为指定生成的长度
pmggc5cbvPBjYlDn
[root@localhost ~]% openssl rand -base64 12
xGLDhvTVuaIjIU6C
[root@localhost ~]% openssl rand -hex 12				# -hex指定处理结果为16进制格式
7aafad13801244d363893c16

2.2.3 公钥加密

公钥加密首先要得到私钥，再从私钥中提取出公钥。以RSA算法为例：

生成私钥使用子命令genrsa：

[root@localhost ~]% openssl genrsa 512						# 数字指定的是密钥位数，默认就是512位
Generating RSA private key, 512 bit long modulus
.....................++++++++++++
.............++++++++++++
e is 65537 (0x10001)
-----BEGIN RSA PRIVATE KEY-----
MIIBOgIBAAJBAMjW6WyF+7WVle00XeCUUu3Szgn7oa+A9xeihgnUQu4m9ioZY3OD
/1BkRHVAHbA9VLzS6DwEW7aDE+fSQo0vPA8CAwEAAQJANtMD0U4Z0g3NaX0cC0wx
/x3GhM8d6ezIhrkk4dYBl0SrrJ+FgDUIdLA9rn7nU+3XQeKR6U82WrKb/D/F0w57
4QIhAOUewDL55L8s64rzYUCq7/AmjMA6KTRkXXkk6KBWUiLpAiEA4GbMd157uXW+
AbtjFlVVeaeercaZE4vUZtVneMpOXDcCIQCHbRqrxts3SMTct6inQaJa715IjNgo
GJ7LaU563yrjaQIgKHHewFUDL7YM/PrtLQVMVpTjgKaeyGsXaUFlWNv9q5kCIFrG
ykMe7ESydOmn4cxwvITw2DT25JBd5TiUIpHzGG6Y
-----END RSA PRIVATE KEY-----

从私钥中提取公钥使用子命令rsa：

[root@localhost ~]% openssl genrsa -out rsa.private 512			# -out把生成的私钥存放在指定文件中，注意密钥位数必须是命令的最后一个参数
Generating RSA private key, 512 bit long modulus
.................++++++++++++
..............++++++++++++
e is 65537 (0x10001)

[root@localhost ~]% openssl rsa -in rsa.private -pubout			# 选项-in表示从指定文件中提取；选项-pubout表示输出公钥
writing RSA key
-----BEGIN PUBLIC KEY-----
MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANgIm22h3hVTK7Y3BrROakJPyjLxL33m
a1Ig18/dIHnkz6rgcQ/uo/xVdWy7dEcQ+eHMgI1NM9wZrnHphPoGKD8CAwEAAQ==
-----END PUBLIC KEY-----

实际上私钥存储的文件应当设定除属主外，组用户、其他用户均不可读，所以保存语句可改为：

[root@localhost ~]% (umask 077;openssl genrsa -out rsa.private 512)

# 括号中表示在子shell中运行，把子shell中的umask改为077，这样不影响当前shell的umask，且保证在子shell中进行创建的文件，组用户和其他用户无任何权限

接下来就可以进行加密、解密了，加密解密使用子命令rsautl：
先说明下该子命令常用选项：

选项	意义
-encrypt	加密
-decrypt	解密
-in	要处理的文件
-inkey	使用的密钥
-pubout	输出公钥
-pubin	指定选项-inkey指定的密钥是作为公钥的；默认-inkey指定的密钥是作为私钥
-sign	数字签名（实质就是用私钥加密数据）
-verify	验证数字签名（实质就是用公钥解密私钥加密的密文）

使用公钥加密，私钥解密：

[root@localhost ~]% openssl rsa -in rsa.private -pubout > rsa.public	# 提取的公钥重定向至文件rsa.public
writing RSA key

[root@localhost ~]% openssl rsautl -encrypt -in test.data -inkey rsa.public -pubin -out test10.encrypt
[root@localhost ~]% cat test10.encrypt 
±yB8

数字签名（实质就是私钥加密，公钥解密）：

[root@localhost ~]% openssl rsautl -sign -in test.data -inkey rsa.private -out test11.encrypt                          # 这里为了演示方便，直接用私钥加密了数据test.data。而数字签名加密的应当是文件的特征码
[root@localhost ~]% cat test11.encrypt
¼/2O��吞c CϑmcܽN|H±ӠS&NZ����1·¦㥟e£؉sL

[root@localhost ~]% openssl rsautl -verify -in test11.encrypt -inkey rsa.public -pubin
123456
1
2
3
4
5
6

虽然以RSA算法做数字签名，实质是私钥加密、公钥解密，但格式并不是公钥加密中公钥和私钥对调，而是要使用选项-sign、-verify。

2.2.4 自建CA

公信的CA颁发的证书要付费，如果只是在一定范围内通信，通信方验证需要证书，可自建私有CA完成。

在openssl的配置文件/etc/pki/tls/openssl.cnf中可看到对CA的配置定义：


[ ca ]
default_ca      = CA_default            # The default ca section

####################################################################
[ CA_default ]

dir             = /etc/pki/CA           # CA所有相关内容的存放目录
certs           = $dir/certs            # 已签署的证书存放目录
crl_dir         = $dir/crl              # 已吊销的证书存放目录
database        = $dir/index.txt        # 数据库索引文件
#unique_subject = no                    # Set to 'no' to allow creation of
                                        # several ctificates with same subject.
new_certs_dir   = $dir/newcerts         # 新证书默认位置

certificate     = $dir/cacert.pem       # CA的自签证书
serial          = $dir/serial           # 证书的序列号
crlnumber       = $dir/crlnumber        # 证书吊销的序列号
                                        # must be commented out to leave a V1 CRL
crl             = $dir/crl.pem          # 当前的证书吊销列表
private_key     = $dir/private/cakey.pem# CA私钥
RANDFILE        = $dir/private/.rand    # private random number file

x509_extensions = usr_cert              # The extentions to add to the cert

……

default_days    = 365                   # 颁发证书的默认有效期
default_crl_days= 30                    # 吊销声明有效期
default_md      = default               # use public key default MD
preserve        = no                    # keep passed DN ordering
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

各不同数据要按上述定义放在指定目录，如目录不存在则手动创建，否则会报错。如需把相关内容放在自定义文件中，配置文件要修改。

自建步骤：

1、CA要有自己的私钥，先生成一个私钥（这里仍使用RSA算法），放在指定文件：

[root@localhost ~]% openssl genrsa 512 > /etc/pki/CA/private/cakey.pem
Generating RSA private key, 512 bit long modulus
…++++++++++++
…++++++++++++
e is 65537 (0x10001)
1
2
3
4
5
2、申请一个自签证书至指定文件，申请证书使用子命令req：


[root@localhost ~]% openssl req -new -x509 -key /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem -days 365            # 选项-new表示这是新的证书申请；-key用于指定私钥（证书存储的内容是公钥，该选项指定了从指定私钥中提取公钥，会自动提取）；-x509表示这是自签证书；-days指定有效期，不指定就使用配置文件中默认的
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:CN                # 要求填写属性信息以认证身份
State or Province Name (full name) []:Taiwan
Locality Name (eg, city) [Default City]:Taipei
Organization Name (eg, company) [Default Company Ltd]:WTO
Organizational Unit Name (eg, section) []:WC
Common Name (eg, your name or your server's hostname) []:Webber     # 要求填写名字或主机名，非常重要，要与互联网上别访问的名字一样，否则根据证书会认为身份错误
1
2
3
4
5
6
7
8
9
10
11
12
13
14

正常申请证书也是如上命令，只是没有选项-x509，申请后需CA签署；上述命令是自签，无需再签署。

3、配置文件中定义的各数据存放目录，如不存在需创建：


[root@localhost ~]% mkdir /etc/pki/CA/
cacert.pem  certs/      crl/        newcerts/   private/    
[root@localhost ~]% touch /etc/pki/CA/{serial,index.txt}       # 笔者主机缺少存放证书序列号的文件和数据库索引文件

[root@localhost ~]% echo 01 > /etc/pki/CA/serial               # 而且serial文件中要有一个初始序列号
1
2
3
4
5

这样CA就创建好了。也就是说只要有自签证书，就可作为一个CA主机了。

2.2.4.1 用另一台主机向CA主机申请证书


1、先另一主机node2创建一个私钥：

[root@node2 ~]% openssl genrsa 512 > node2.private
Generating RSA private key, 512 bit long modulus
.++++++++++++
.++++++++++++
e is 65537 (0x10001)
1
2
3
4
5

2、创建证书请求文件（Certificate Signing Require）：


[root@node2 ~]% openssl req -new -key node2.private > node2.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:CN                            # 信息范围要与CA主机一致，因为自建CA影响的就是一定范围
State or Province Name (full name) []:Taiwan
Locality Name (eg, city) [Default City]:Taipei
Organization Name (eg, company) [Default Company Ltd]:WTO
Organizational Unit Name (eg, section) []:WC
Common Name (eg, your name or your server's hostname) []:www.node2.com
Email Address []:123456@qq.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:zhiyewanjia123
An optional company name []:Null
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

3、把这个申请文件复制到CA主机上，在CA主机上执行签署：


[root@node2 ~]% scp node2.csr root@192.168.0.105:/tmp          # 复制

……
1
2
3
在CA主机上找到这个文件，签署申请使用子命令ca：

[root@localhost ~]% openssl ca -in /tmp/node2.csr -out /etc/pki/CA/certs/node2.crt     # 签署的证书保存在配置文件中指定的目录下

……

Certificate is to be certified until Oct  1 04:43:45 2018 GMT (365 days)
Sign the certificate? [y/n]:y                       # 询问是否签署，输入“y”

Write out database with 1 new entries
Data Base Updated
1
2
3
4
5
6
7
8
9

此时可以看到数据库索引文件中，记录了该证书的相关信息：


[root@localhost ~]% cat /etc/pki/CA/index.txt
V   181001044345Z       01  unknown                     # V表示已签署    /C=CN/ST=Taiwan/O=WTO/OU=WC/CN=www.node2.com/emailAddress=123456@qq.com
1
2
5、把签署完的证书发回给node2主机即可。可使用子命令x509查看证书内容（主要是subject和serial）：

[root@node2 ~]% openssl x509 -in node2.crt -noout -subject -serial     # -noout表示不输出公钥
subject= /C=CN/ST=Taiwan/O=WTO/OU=WC/CN=www.node2.com/emailAddress=123456@qq.com
serial=01
1
2
3

2.2.4.2 吊销证书

如果用户的私钥被盗取，为防止身份被冒充，可向CA申请吊销证书。
实际使用中，很少手动这样操作，这里演示下大致过程。以上述node2主机申请的证书为例，步骤：

1、用户先查看自己证书的序列号，交给CA服务器；

2、与存储证书序列号的文件/etc/pki/CA/serial一样，吊销也有序列号，由文件/etc/pki/CA/crlnumber保存，也要给一个初始编号：

[root@localhost ~]% echo 01 > /etc/pki/CA/crlnumber
1

3、CA服务器查看序列号、项目信息是否与index.txt中记录的一致，如一致则吊销。
吊销仍使用子命令ca，选项-revoke，参数是/etc/pki/CA/newcerts目录下，证书序列号对应的.pem文件：


[root@localhost ~]% openssl ca -revoke /etc/pki/CA/newcerts/01.pem 
Using configuration from /etc/pki/tls/openssl.cnf
Revoking Certificate 01.
Data Base Updated

[root@localhost ~]% cat /etc/pki/CA/index.txt                  # 对于吊销后的证书，数据库文件记录为R
R   181001044345Z   171001084316Z   01  unknown /C=CN/ST=Taiwan/O=WTO/OU=WC/CN=www.node2.com/emailAddress=123456@qq.com
1
2
3
4
5
6
7

4、更新证书吊销列表：


[root@localhost ~]% openssl ca -gencrl -out /etc/pki/CA/Webber.crl     # -gencrl表示从数据库索引文件中获取信息；生成列表名为“CA名.crl”（应该是约定俗成的？）
Using configuration from /etc/pki/tls/openssl.cnf

[root@localhost ~]% openssl crl -in /etc/pki/CA/Webber.crl -text -noout        # 查看吊销列表
Certificate Revocation List (CRL):
        Version 2 (0x1)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: /C=CN/ST=Taiwan/L=Taipei/O=WTO/OU=WC/CN=Webber/emailAddress=12345@qq.com
        Last Update: Oct  1 08:53:17 2017 GMT
        Next Update: Oct 31 08:53:17 2017 GMT
        CRL extensions:
            X509v3 CRL Number: 
                1
Revoked Certificates:
    Serial Number: 01
        Revocation Date: Oct  1 08:43:16 2017 GMT
    Signature Algorithm: sha1WithRSAEncryption
         43:e7:d0:fc:ef:7a:5c:37:d4:26:1b:a1:19:51:0e:f8:1d:03:
         cc:2a:3b:e8:35:5d:86:13:f5:7f:ce:9e:a3:f3:70:d0:4b:bb:
         b3:e3:cf:42:7a:c6:a9:17:97:91:78:a0:02:f8:ae:0c:dc:31:
         5c:78:2d:b5:70:cc:34:84:b7:f6
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

此外吊销的证书应当放到指定目录？不大确定，大致过程就是这些。基本不会用到手动吊销证书。

（完）

各加密算法具体实现本文不述。说明用到的只是各类型算法的性质：
1、对称加密算法：用于加密数据，加密与解密使用同一密钥，比如DES、AES算法等；
2、非对称加密算法（也称公钥加密）：密钥成对，分为公钥和私钥；公钥是从私钥中提取出来的；公钥公开，私钥保密；公钥加密的数据，只有私钥能解密（反之亦然）；由于算法复杂消耗资源、时间较多，一般用于加密对称加密算法的密钥，完成密钥分发。比如RSA算法等；
3、单向加密算法：对数据单向加密，无法解密；输出的密文为定长字符串；数据相同，则加密而来的密文也相同；数据的微小变化，会造成密文的巨大变化（否则就能根据两个相似密文推断出它们的明文也是相似的）。如md5、sha256、sha512算法等。
单向加密算法可看作提取数据的特征码（指纹信息）。 ↩︎
这就是所谓的数字签名。其实只要用某人的私钥加密一段数据，别人能用他的公钥解密从而验证来源是他，就是数字签名了。但约定俗成的数字签名，还就是用私钥加密要发送数据的特征码，而非其他数据。
Alice用私钥之所以加密特征码而不是数据，因为公钥加密算法效率较低。 ↩︎
因为Bob收到Eve发来的信息后，执行正常解密也不会有问题：
1、可解密对称加密算法的密钥，因为这是Eve用Bob的公钥加密的
2、可用对称加密算法的密钥，获得数据内容（可被Eve篡改过）和加密的篡改过的数据的特征码（甚至Eve使用的对称加密算法都可以和Alice发给他的不一样，反正给Bob的密钥让Bob能解开就行）
3、可使用Eve的公钥（Bob误以为是Alice的），解密获取数据特征码（因为这是Eve用自己的私钥加密的）
4、最后再用单向加密算法验证数据完整性（没有意义了，数据就算完整也是篡改过的数据的特征码） ↩︎
实际上证书的信息不只这些，证书遵循x509标准。
可查阅，本文不赘述。 ↩︎
注意CA自签证书的获取是免费的（因为就是为了获取公钥），这和申请CA颁发证书是两回事。
还是要获取CA的公钥，而且得用“笨”办法。说白了就是把通信方需要获取其他通信方的公钥，转化为了大家都先获取CA的自签证书（内含CA公钥），再通过该公钥验证CA颁发的证书的问题。当然这个比获取每个要通信方的公钥好。
而且也不一定要CA一个个当面把自签证书提供给每个人，比如windows系统就内置了可信CA的自签证书。从而windows使用者可验证通信对方的证书（因为证书的特征码是被CA的私钥加密的）。 ↩︎
客户端一般无需申请证书，因为服务端往往不需知道客户端的身份。
个别情况下例外，如银行的加密狗存的就是客户的证书，为了验证客户身份。不过这种也无需花什么代价，因为银行用的是自建的CA，只在自己限定的范围内生效（即该范围内的主机都信任自建的CA即可）。 ↩︎
协议是由具体软件实现的。比如apache是http协议的一种实现。 ↩︎
比如Bob的私钥被盗了，拿到Bob私钥的人就可以冒充Bob和别人通信。Bob要向CA声明，自己的公钥作废，以止损。 ↩︎
即文本格式。base64含大、小写字母（共52个）、数字（10个）、+、/。共64字符 ↩︎
因为单向加密算法，只要明文一样，则加密的密文也一样，所以为了避免一方的密文与另一方相同从而猜出另一方的明文，加密时使用杂质和明文一起进行加密，这样即便明文相同，密文也会不一样了。
所以杂质最好是随机的，如果两者连杂质都一样，密码正好设定的也一样，那加密的密文还是会一样。 ↩︎

wangzhenyu177

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
openssl

0 目录目录点对点的加密通信过程1 数据完整性2 来源合法性3 数据保密性4 CA41 为何要有CA42 CA如何发挥作用5 服务的加密通信过程openssl命令实现上述过程1 PKI2 openssl命令使用1 点对点的加密通信过程一个加密通信过程，应当具备： 1、数据来源身份合法性（发送方不能被第3方伪装）； 2、数据内容完整性
复制链接

扫一扫