linux基础学习第二十三天linux安全和加密之SSLTLS协议CAopenssl

Posted 2020-08-09

内容：

1、通信加密类型及算法

2、TLS/SSL协议的引入及其通信过程

3、CA、数字签名的引入

4、一个安全的数据通信交换过程

5、openssl工具的使用

6、自制私有根CA过程

一、通信加密类型及算法

数据加密通信的重要性不言而喻，美国NIST,为了保证计算机的安全，提出了几个要求：

(1)、数据要有保密性：数据保密性和隐私性；确保信息不被别人获取，个人存储的信息不能被别人收集到；

(2)、完整性：包括数据完整性和系统完整性；数据完整性确保数据和程序只能以特定权限的进行授权和改变，只能授权之后才能改变或者被改变；确保系统以一种正常的方式执行预定的功能，不会因别人的介入改变方向；

(3)、可用性，工作迅速，可正常使用的情况并获取到信息；

因此，相应的加密类型及算法可以分为以下几种：

1、对称加密

对称加密：采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。需要对加密和解密使用相同密钥的加密算法。由于其速度快，对称性加密通常在消息发送方需要加密大量数据时使用。对称性加密也称为密钥加密。

特性：

(1)、加密、解密使用同一个密钥，效率高

(2)、将原始数据分割成固定大小的块，逐个进行加密

缺陷：

(1)、密钥过多

(2)、密钥分发

(3)、数据来源无法确认

相关的加密算法：

DES：Data Encryption Standard，56bits

3DES：

AES：Advanced Encryption Standard (128, 192, 256bits)

Blowfish，Twofish

IDEA，RC6，CAST5

因为对称式的加密方法如果是在网络上传输加密文件就很难把密钥告诉对方，不管用什么方法都有可能被别窃听到。且通信方如果比较多，秘钥过多，不便于管理，密钥传输和交换难以实现；因此产生了非对称加密

2、非对称加密

非对称式加密就是加密和解密所使用的不是同一个密钥，通常有两个密钥，称为"公钥(public key)"和"私钥(secret key)"，它们两个必需配对使用，否则不能打开加密文件。这里的"公钥"是指可以对外公布的，"私钥"则不能，只能由持有人一个人知道。"公钥"是可以公开的，也就不怕别人知道，收件人解密时只要用自己的私钥即可以，这样就很好地避免了密钥的传输安全性问题。

公钥一般是在私钥中截取片断而成

功能：

数字签名：主要在于让接收方确认发送方身份

对称密钥交换：发送方用对方的公钥加密一个对称密钥后发送给对方

数据加密：适合加密较小数据

缺点：密钥长，加密解密效率低下，因此非对称加密一般不用于加密数据

算法：

RSA（加密，数字签名）,DSA（数字签名）,ELGamal

现实生产中，RSA算法用的最多

3、单向加密(单向散列)

单向加密指的是通过相关算法将任意数据缩小成固定大小的“指纹”，其作用是用于验证数据的完整性，单向加密有以下特点：

任意长度输入

固定长度输出

若修改数据，指纹也会改变（“不会产生冲突”）

无法从指纹中重新生成数据（“单向”）

因此，单向加密主要用于验证数据的完整性

相关的加密算法：

md5、sha1、sha224、sha256、sha384、sha512

二、TLS/SSL协议的引入及其通信过程

为何会产生TLS/SSL？

因为在以前的通信协议设计中，很多应用层的协议并没有对数据进行加密的功能，如http、ftp、telnet、pop3、smtp等，这样很大程度被有心之人加以利用，因此Netscape于1994年开发了SSL，后来成为了世界上最著名的web安全机制，所有主要的浏览器都支持SSL协议

SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。

SSL的通信原理及过程：

SSL介于应用层和TCP层之间，但并不是独立的一层，应用层数据不再直接传递给传输层，而是传递给SSL层，SSL层对从应用层收到的数据进行加密，并增加自己的SSL头。

在建立SSL连接的时候主要需要以下几个步骤： 

    (1) 确认在数据传输过程中的加密手段。 

    (2) 建立并共享在客户端和服务器端的密匙。 

    (3) 验证服务器（可选）。 

    (4) 验证客户端（可选）。  

    其中第一步加密手段确认，允许客户端和服务器端选择一种双方都支持的加密包，SSL3.0协议定义了31种加密包。一个加密包由以下几个部分组成： 

    (1) 密匙交换方法，如RSA密匙交换，Diffie-Hellman密匙交换等。  

    (2) 数据传送的加密手段，如流加密，RC4 with 40-bit keys，RC4 with 128-bit keys，CBC Block Ciphers，RC2 with 40 bit keys，DES40, DES, 3DES_EDE，Idea和Fortezza 等。 

    (3) 建立邮件认证码（Message Authentication Code ，MAC）的邮件文摘，可以使用MD5（128位哈希），Secure Hash Algorithm (SHA)等。

三、 数字签名、证书、CA等相关解析说明

1、数字签名：是指可以添加到文件的电子安全标记。使用它可以验证文件的发送者以及帮助验证文件自被数字签名后是否发生更改。 如果文件没有有效的数字签名，则无法确保该文件确实来自它所声称的源，或者无法确保它在发布后未被篡改(可能被病毒篡改),较为安全的做法是，不要打开该文件。 

数字签名的获取和使用:  

(1).对要发送的内容使用hash函数生内容的摘要(digest) 

(2).使用自己的私钥对摘要加密,就获得了自己的数字签名. 

(3).将数字签名放到要发送的内容里面,一同发送.  

(4).对方收到内容后,先用发送者的公钥对内容里的数字签名解密,得到内容的摘要,是否解密成功就能证明发送人的身份.  

(5).然后对内容使用hash函数生成内容的摘要. 6.如果两个摘要一致,就证明内容没被修改过.  

2、数字证书(digital certificates)：作用是防止公钥被篡改,也可以添加到文件，通俗地说，证书就类似显示生活的身份证，它是用来证明某个人是某个人的东西。一份数字证书包括了公钥、个人、服务器或者其它机构的身份信息. 

数字签名的获取和使用:  

(1).把 发送者的个人信息,发送者的公钥,数字证书的相关信息(比如:有效日期) 使用CA(证书中心)的私钥加密,再加上CA中心对该数字证书里面的信息的数字签名,得到的就是发送者的数字证书.(以上步骤是在CA的服务器上运算的) 

(2).将数字签名和数字证书都放到要发送的内容里面,一同发送.  

(3).对方接收到内容后,先用CA的公钥解开数字证书,就可以拿到发送者真实的公钥了，然后就能证明发送者的身份和接收内容是否被修改过了。  以IE浏览器为例，单击 工具/Internet 选项/内容/证书 就能看到"受信任的根证书颁发机构"列表,浏览器会根据这张表,查看解开数字证书的(CA的)公钥是否在列表之内。 

3、证书中心（certificate authority，简称CA）：也叫 认证中心，它是专门提供网络身份认证服务，负责签发和管理数字证书，具有权威性和公正性的第三方信任机构，它的作用就像我们现实生活中颁发证件的公司，如护照办理机构。目前国内的CA认证中心主要分为区域性CA认证中心和行业性CA认证中心。 

4、根证书(root certificates)：根证书，是CA认证中心给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。

从技术上讲，数字证书包含四部分，用户的信息，用户的公钥，数字证书的信息,还有CA中心对该数字证书里面的信息的数字签名，要验证一份数字证书的真伪（即验证CA中心对该数字证书信息的数字签名是否有效），需要用CA中心的公钥验证，而CA中心的公钥存在于对这份数字证书进行签名的数字证书1内，故需要下载数字证书1，使用数字证书1对数字证书验证又需先验证数字证书1本身的真伪，故又要用签发数字证书1的数字证书2来验证，这样一来就构成一条数字证书验证链，这条数字证书验证链在哪里终结呢？答案就是根证书，根证书是一份特殊的数字证书，它的签发者是它本身，下载根证书就表明您对该根证书以下所签发的数字证书都表示信任，数字证书的验证追溯至根证书即为结束。

所以说用户在使用数字证书之前必须先下载根证书。，下图是windows的证书相关截图信息

四、一次安全加密的通信过程(源自网络)

根据上图来说一下一次会话，发邮件，用户和用户之间的数据加密的全过程：
1、Bob生成数据
2、用单向加密数据生成特征码
3、Bob用自己的私钥加密特征码放在数据后面———-用自己的私钥进行签名；
4、生成临时会话密钥加密特征码和数据——-因为之前没有对数据进行加密；
5、用对方Alice的公钥加密临时密钥(这里的公钥其实就是证书，证书包括了Alice的公钥已经CA的信息)
6、数据加密完后一并发给对方
7、Alice用自己的私钥解密对称密钥
8、拿到密码后解密对方加密的数据
9、Alice用Bob的公钥解密特征码—————–使用发送者的公钥对签名进行认证；
10、Alice用相同的单向加密验证数据的完整性

五、openssl的介绍和使用

openssl：开源的ssl实现工具，它由三个组件组成

三个组件：

openssl: 多用途的命令行工具

libcrypto: 加密算法库

libssl：加密模块应用库，实现了ssl及tls

相关命令：openssl enc、openssl dgst、openssl genrsa、openssl rsa 

另外，还有一系列的指令，如： 

enc：通用加密程序，可以使用不同的加密组合完成加密，输入及输出可以通过Base64编码转换。 

dgst：通用邮件文摘，使用f md2, md5, sha (sha-0 or sha-1)或者mdc2等算法。 

rsa：操纵RSA 私钥。 

dsa：操纵DSA 私钥。 

dh：操纵Diffie-Hellman参数文件。 

crt2pkcs7：产生包括了一个crl和证书的pkcs7对象。 

x509：操纵x509证书, “自签”证书。 

req：操纵PKCS#10证书需求，并且产生证书请求。 

genrsa：产生一个任意大小的RSA 私钥。 

genrsa：产生了一组Diffie-Hellman参数。 

ca：从PKCS#10 证书请求产生一个证书，该程序同时维护着所颁发的证书的数据库。 

verify：检测x509证书的签名

加密：

1、对称加密：

openssl enc -e -des3 -in FILE -out FILE ：-e表示加密，-des3表示加密算法，注意由于加密的文件一般其他人没有任何权限，在不改变当前环境的情况下，使用(command)来实现在子shell中设定umask，然后按提示输入密钥即可

[17:14 [email protected]~]# openssl enc -e -des3 -in anaconda-ks.cfg -out anaconda-ks.cfg.key
enter des-ede3-cbc encryption password:
Verifying - enter des-ede3-cbc encryption password:
[17:15 [email protected]~]# ll anaconda-ks.cfg anaconda-ks.cfg.key 
-rw-------. 1 root root 1582 Sep 17 18:27 anaconda-ks.cfg
-rw-r--r--. 1 root root 1600 Sep 20 17:15 anaconda-ks.cfg.key
[17:16 [email protected]~]#(umask=077;openssl enc -e -des3 -in anaconda-ks.cfg -out anaconda-ks.cfg.key)
enter des-ede3-cbc encryption password:
Verifying - enter des-ede3-cbc encryption password:
[17:16 [email protected]~]#ll anaconda-ks.cfg anaconda-ks.cfg.key )
-rw-------. 1 root root 1582 Sep 17 18:27 anaconda-ks.cfg
-rw-r--r--. 1 root root 1600 Sep 20 17:16 anaconda-ks.cfg.key

2、单向加密

openssl dgst -md5 testfile：

[17:21 [email protected]~]# openssl dgst -sha1 anaconda-ks.cfg
SHA1(anaconda-ks.cfg)= 2b8174985e36c55eb12bd30861d58a62cd54fa64
[17:26 [email protected]~]# openssl dgst -md5 anaconda-ks.cfg
MD5(anaconda-ks.cfg)= c2f639d9a0f6820c1df83fec41b96bda

3、非对称加密

                生成私钥：

                openssl genrsa -out /PATH/TO/PRIVATEKEY.FILE  NUM_BITS

                    (umask066; opensslgenrsa-out key.pri–des 2048)

                从私钥中提取出公钥：

                    openssl rsa -in PRIVATEKEYFILE –pubout –out PUBLICKEYFILE

六、自建私有CA和颁发证书步骤

在创建CA之前，先查看openssl的配置文件，检查默认的CA设置信息：/etc/pki/tls/openssl.cnf，这里我们主要关心CA的相关信息，所以部分信息省略

[17:04 [email protected]~]# cat /etc/pki/tls/openssl.cnf 
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
.....省略部分
####################################################################
[ ca ]
default_ca= CA_default# The default ca section
####################################################################
[ CA_default ]
dir= /etc/pki/CA# Where everything is kept
certs= $dir/certs# Where the issued certs are kept
crl_dir= $dir/crl# Where the issued crl are kept
database= $dir/index.txt# database index file.
#unique_subject= no# Set to ‘no‘ to allow creation of
# several ctificates with same subject.
new_certs_dir= $dir/newcerts# default place for new certs.
certificate= $dir/cacert.pem # The CA certificate
serial= $dir/serial # The current serial number
crlnumber= $dir/crlnumber# the current crl number
# must be commented out to leave a V1 CRL
crl= $dir/crl.pem # The current CRL
private_key= $dir/private/cakey.pem# The private key
RANDFILE= $dir/private/.rand# private random number file
x509_extensions= usr_cert# The extentions to add to the cert
# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt = ca_default# Subject Name options
cert_opt = ca_default# Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions= crl_ext
default_days= 365# how long to certify for
default_crl_days= 30# how long before next CRL
default_md= default# use public key default MD
preserve= no# keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy= policy_match
# For the CA policy
[ policy_match ]
countryName= match
stateOrProvinceName= match
organizationName= match
organizationalUnitName= optional
commonName= supplied
emailAddress= optional
# For the ‘anything‘ policy
# At this point in time, you must list all acceptable ‘object‘
# types.
[ policy_anything ]
countryName= optional
stateOrProvinceName= optional
localityName= optional
organizationName= optional
organizationalUnitName= optional
commonName= supplied
emailAddress= optional
####################################################################
.....省略部分

有上面的配置信息以及相关的注释内容可以看出，相关的CA存放位置以及申请的填写信息以及相关证书文件名以及扩展名称的定义等，要严格按照配置文件的信息来进行设置。

查看初始的CA目录，只有部分目录是初始生成的空目录，有部分部分在开始需要手动添加：index.txt、serial等

[19:23 [email protected]/etc/pki/CA]# tree
.
├── certs
├── crl
├── newcerts
└── private
4 directories, 0 files

    (1) 创建所需要的文件

touch /etc/pki/CA/index.txt
echo 01 > /etc/pki/CA/serial
[19:25 [email protected]/etc/pki/CA]# touch index.txt
[19:27 [email protected]/etc/pki/CA]# touch serial
[19:28 [email protected]/etc/pki/CA]# echo 01>serial 
[19:28 [email protected]/etc/pki/CA]# tree
.
├── certs
├── crl
├── index.txt
├── newcerts
├── private
└── serial
4 directories, 2 files

    (2) CA自签证书

    生成私钥

cd /etc/pki/CA/

(umask066; openssl genrsa -out /etc/pki/CA/private/cakey.pem 2048)，注意，根据配置文件，生成的私钥文件名必须是cakey.pem，，（）里的命令表示只在子shell有效，不会影响现有环境的mask值

[19:28 [email protected]/etc/pki/CA]# (umask=066;openssl genrsa -out /etc/pki/CA/private/cakey.pem 2048)
Generating RSA private key, 2048 bit long modulus
..........................................+++
.....................................+++
e is 65537 (0x10001)
[19:32 [email protected]/etc/pki/CA]#tree
.
├── certs
├── crl
├── index.txt
├── newcerts
├── private
│   └── cakey.pem
└── serial
4 directories, 3 files

    生成自签名证书(自己向自己申请并颁发证书)

    openssl req -new -x509 –key /etc/pki/CA/private/cakey.pem -days 7300 -out /etc/pki/CA/cacert.pem

        -new: 生成新证书签署请求

        -x509: 专用于CA生成自签证书

        -key: 生成请求时用到的私钥文件

        -days n：证书的有效期限

        -out /PATH/TO/SOMECERTFILE: 证书的保存路径

[19:32 [email protected]/etc/pki/CA]# openssl req -new -x509 -key private/cakey.pem -days 7300 -out /etc/pki/CA/cacert.pem
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) []:BEIJING
Locality Name (eg, city) [Default City]:HAIDIAN
Organization Name (eg, company) [Default Company Ltd]:mylinux.com
Organizational Unit Name (eg, section) []:hill
Common Name (eg, your name or your server‘s hostname) []:www.mylinux.xom  
Email Address []:[email protected]

    注意填写相关的信息(如国家、省份、公司名称等)，自此一个私有根CA已经搭建完成，可以给内部的相关服务器进行办法证书了 。

    (3) 颁发证书

    (a) 在需要使用证书的主机生成证书请求；

    给web服务器生成私钥

        (umask066; openssl genrsa -out /etc/httpd/ssl/httpd.key 2048)

    生成证书申请文件

        openssl req -new -key /etc/httpd/ssl/httpd.key -days 365 -out /etc/httpd/ssl/httpd.csr

    (b) 将证书请求文件传输给CA

    (c) CA签署证书，并将证书颁发给请求者；

        openssl ca -in /tmp/httpd.csr –out /etc/pki/CA/certs/httpd.crt -days 365

    注意：默认国家，省，公司名称必须和CA一致

       (d) 查看证书中的信息：

        openssl x509 -in /PATH/FROM/CERT_FILE -noout -text|subject|serial|dates

    (4) 吊销证书

    (a) 在客户端获取要吊销的证书的serial

        openssl x509 -in /PATH/FROM/CERT_FILE -noout -serial -subject

    (b) 在CA上，根据客户提交的serial与subject信息，对比检验是否与index.txt文件中的信息一致

    吊销证书：

        openssl ca -revoke /etc/pki/CA/newcerts/ SERIAL.pem

     (c) 生成吊销证书的编号(第一次吊销一个证书时才需要执行)

        echo 01 > /etc/pki/CA/crlnumber

    (d) 更新证书吊销列表

        openssl ca -gencrl -out /etc/pki/CA/crl/ca.crl

    查看crl文件：

        openssl crl -in /etc/pki/CA/crl/ca.crl -noout-text

本文出自 “6638225” 博客，转载请与作者联系！