PKI实验

实验概述

实验目的

  公钥加密是当今安全通信的基础，但是当通信的一方向另一方发送公钥时，却容易遭受到中间人攻击。根本问题在于没有一个简单的方式验证公钥所有者的身份。也就是说当收到一个公钥和它的所有者信息时，无法确定该公钥确实为这个所有者所拥有。公钥基础设施（PKI）就是解决此问题的一个方案。

  本次实验涉及到PKI、CA、Apache、HTTPS这几个知识点，所通过本次实验一系列的任务期望能够到达如下几个目的。

  1. 了解PKI的工作原理；

  2. 掌握如何使用PKI保护网络；

 

实验原理

  PKI是一种遵循标准的利用公钥理论和技术建立的提供安全服务的基础设施。公钥基础设置的目的是从技术上解决网上身份认证、电子信息的完整性和不可抵赖性等安全问题，为网络应用（如浏览器、电子邮件、电子交易）提供可高安全的服务。本次实验就是利用PKI技术为一个浏览器提供服务。

1. 中间人攻击

  在发明公钥加密之前，加密依赖私钥。这种加密方法的挑战在于密钥交换，也就是在加密通道建立之前，如何让通信双方把密钥确定下来。公钥解决了这个问题，因为她的加密密钥时公开的，可以用明文发送。然而，经管它可以防御窃听攻击，但是还是为遭遇到中间人攻击。

  中间人攻击时发生在两个设备之间的流量被截获的情况下。当一台计算机向另外一台计算机发送数据时，数据会在多个设备之间传输，例如路由器。这些设备如果被攻击，就可以被用来实施中间人攻击。如下图所示：

                                                                                                                                  

图1：中间人攻击的原理

 

中间人攻击的基本问题是通信双方无法确定这个公钥是否属于对方，如果能够提供一个机制把公钥和所有者的身份绑定在一起，那么就可以解决这个问题。公钥基础设施（PKI）就是解决此问题的一个方案。

2. PKI

2.1 PKI体系结构

  PKI体系包含证书机构（Certificate Authority, CA）、注册机构（Registration Authority,RA）、策略管理、密钥（Key）与证书管理、密钥备份与恢复、模型运算等功能模块。本实验中我们主要用到CA与证书管理模块，因此PKI可以简化为下图所示：

 

                                                                                                                                            

    

图2： PKI结构

2.1 数字证书

  数字证书是一个经证书授权中心（CA机构）数字签名的文件，包含拥有者的公钥及相关身份信息。证书有四种类型，分别是自签名证书、CA证书、本地证书和设备本地证书。本次实验中我们用到了前两种自签名证书和CA证书。

   自签名证书：它的拥有者和证书的颁发者是同一个人。用于没办法去跟CA申请证书的情况下。比如本实验中我们用于虚拟的CA并给自己颁发的证书就是自签名证书。

  CA证书，是CA机构给某一申请终端颁发的证书。

3. Https访问的认证过程

   我们通过下图看以下Https访问web时的证书应用场景，Https服务器通过访问CA申请并获得一个证书，客户端管理员通过这个证书来验证服务器的身份就可以了。

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

 

图2-3 Https访问web时的认证过程

实验内容

  本次实验来自于https://seedsecuritylabs.org/Labs_20.04/Crypto/Crypto_PKI/，共需要完成如下6个小任务。通过这6个任务我们完成一个银行服务器bank32.com的部署、认证、攻击过程。

  Task1 成为认证颁发机构（CA）

  Task2 为web server生成签名请求

  Task3 为web server生成签名证书

  Task4 在网络服务器中部署公钥证书

实验环境

  本次实验需要一个服务器产生证书，另外我们还需要一个容器来模拟web服务器，分两步完成。

1. 搭建Seed服务器，需要在Oracle VM VirtualBox上部署Seed实验室的Ubuntu20.04。

1）本次实验需要用到的工具镜像下载链接：

https://pan.cdut.edu.cn:443/link/50A4C404D957CC7B1DB785E979060E3E

2）vitualbox下载链接：链接：https://pan.baidu.com/s/1TumqdCjeOZYIjPqCQoNnWQ?pwd=5dgn

提取码：5dgn

有了SEED虚拟机镜像后，安装下面的方法安装seed虚拟机。

1.镜像解压后是vdi文件，按照下面步骤导入并启动

 

 

 

 

 

 

 

 

 

输入密码dees

界面

 

 

 

 

事先创建一个共享文件夹叫：VM_Share

 

 

点击设备->共享文件夹->(这里可以创建到固定分配这里，重启后还会有共享文件夹)

 

 

 

 

再点击设备->安装增强功能 在出现yes/no时输入y回车

 

 

在终端输入命令sudo adduser ‘当前用户名’ ‘有权限的组名’ ，我这里是vboxsf这个组 :sudo adduser seed vboxsf

在终端输入命令reboot重启就可以使用这个共享文件夹了

3. 部署容器

  Step1：下载本次实验需要的容器压缩包PKI_Labsetup.zip。

  Step2：将容器压缩包上传到Seed镜像环境中，建议先新建一个文件夹PKI，让压缩包传到/home/seed/PKI路径下并解压。使用命令为 unzip PKI_Labsetup.zip，

 

 

Step3：Build容器   

cd Labsetup/   

docker-compose build

 

 

 

 

 

Step4：启动 命令为 dcup

 

 

 

Step5: 最后，在主机（seed虚拟机）的/etc/hosts文件增加如下一条配置10.9.0.80 www.bank32.com ，其中10.9.0.80是容器的IP地址中。待web服务器配置完成后就可以通过主机访问了。

容器启动后如果要进入容器的shell，需要通过如下两个命令；在主机终端中输入 dockps 命令，查看刚启动的容器ID；输入命令 docksh ID的前两个字符

 

 

 

 

 

 

实验步骤

  本次实验通过4个分解的任务模拟证书签发和认证过程。首先将本地主机作为一个CA,完成签发证书的过程；接着用签发的证书去配置安全的Web服务器，通过这个配置，分析验证整个证书验证的过程。在整个实验过程中，大家要学习和体会：

1.使用openssl颁发一个证书的方法

2.一个公钥证书包含哪些内容

3.为一个Web服务器配置证书的方法

4.在客户端配置CA的方法以及客户端为什么能够对服务器的身份进行验证

Task1. 成为认证颁发机构（CA）

  认证颁发机构（CA）是一个可信的、能够签发数字证书的实体。在签发证书之前，CA需要验证证书申请者的身份。CA的核心功能有如下两个：（1）验证Subject域；（2）对证书进行数字签名。

  一些商业性的CAs被视为根类CAs，想要获得商业核证机关发出的数字证书的用户需要向这些核证机关支付费用。在实验中，我们不使用商业的CA而是让自己成为根CA，然后使用此CA为其他人（例如服务器）颁发证书。

  任务1中，我们将使本地主机设置成为根CA，并为此CA生成证书。根CA的证书是自签名的，通常预加载到大多数操作系统、web浏览器和其他依赖PKI的软件中。

Step1.部署CA。

  签名时，openssl会使用一个默认的配置文件（/usr/lib/ssl/openssl.cnf）,该文件中已经配置了需要的文件夹和文件的名字，因为我们要修改这个配置文件，因此我们拷贝这个文件到自己的目录下，新拷贝的文件命名为myCA_openssl.cnf。Openssl.cnf文件部分配置内容如下,将unique_subject前面的注释去掉。

 

 

 

 

 

因此需要在/home/seed/PKI下创建一个demoCA的目录，并在该文件夹下创建三个文件夹certs、crl和newcerts和两个文件index.txt和serial。Seiral文件包含证书的序列号可以将任意数字反正文件中来初始化序列号，我们采用1000为例。具体命令如下:

sudo mkdir demoCA //根据myCA_openssl.cnf中的内容创建需要的文件夹和文件

cd demoCA

sudo mkdir certs crl newcerts

 

sudo touch index.txt serial

sudo vi serial //最后打开serial写入1000

 

 

 

 

 

Step2.生成自签名证书ca.key (私钥证书)和 ca.crt (公钥证书)。

  在PKI或者PKIlib(自己所建目录下)，执行如下命令，具体命令如下：

sudo openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -keyout ca.key -out ca.crt -subj "/CN=www.modelCA.com/O=Model CA LTD./C=US" -passout pass:dees

  其中-subj用来设置Subject域信息，-passout是使用证书时需要的密码信息，因为每次要使用此CA为其他人签名证书时，都必须输入该密码（dees）。

  利用下面两个命令查看ca.crt和ca.key的内容：

openssl x509 -in ca.crt -text –noout

 

 

sudo openssl rsa -in ca.key -text -noout

回答下面两个问题：  

问题1：证书的哪个部分表明这是CA的证书？

问题2：证书的哪个部分表明这是自签名证书？

1. 答：签发者：表示CA的名称，即颁发证书的机构。

如果是自签名证书，那么证书中的颁发者和主体名是相同的，也就是主体名和签发者都表示是同一个实体

Task2. 为web server生成签名请求

  如果银行要部署一个基于HTTPS的网络服务器（比如www.bank32.com）来保护客户与服务器之间的交互，就需要从根CA那里获取一个公钥证书。首先需要生成一个签名请求（CSR—Certificate Singing Request），CSR中包含银行的公钥与其身份细节，如机构名称、地址与域名等信息。

  生成CSR的命令如下，与Task1中生成自签名的证书类似，去掉了-x509的选项，没有这个选项就是生成了CSR，有这个选项就是生成了自签名证书。命令如下，其中bank32A和bank32B是bank32网站的别名。

sudo openssl req -newkey rsa:2048 -sha256 -keyout server.key -out server.csr -subj "/CN=www.bank32.com/O=Bank32 Inc./C=US" -addext "subjectAltName = DNS:www.bank32.com, DNS:www.bank32A.com, DNS:www.bank32B.com" -passout pass:dees

 

 

 

查看ca.crt的内容

 

 

查看ca.key的内容

 

Task3. 为web server生成签名证书

sudo openssl ca -config myCA_openssl.cnf -policy policy_anything -md sha256 -days 3650 -in server.csr -out server.crt -batch -cert ca.crt -keyfile ca.key

 

 

 

 

 

Ca.crt:

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            49:07:74:7b:09:ce:9d:a8:c9:dd:48:5c:f9:6c:0b:12:41:14:9c:d1

        Signature Algorithm: sha256WithRSAEncryption

        Issuer: CN = www.modelCA.com, O = Model CA LTD., C = US

        Validity

            Not Before: Dec 11 07:48:13 2023 GMT

            Not After : Dec  8 07:48:13 2033 GMT

        Subject: CN = www.modelCA.com, O = Model CA LTD., C = US

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                RSA Public-Key: (4096 bit)

                Modulus:

                    00:dc:e3:80:d0:a0:24:5a:03:60:45:d6:91:dd:e6:

                    c3:45:08:00:87:c6:46:73:db:1c:33:ae:c9:1a:e5:

…………….

…………….

Exponent: 65537 (0x10001)

        X509v3 extensions:

            X509v3 Subject Key Identifier:

                D6:6D:CE:C9:5B:07:43:56:D1:8F:AC:3A:64:58:F8:3D:71:C4:5E:69

            X509v3 Authority Key Identifier:

                keyid:D6:6D:CE:C9:5B:07:43:56:D1:8F:AC:3A:64:58:F8:3D:71:C4:5E:69

 

            X509v3 Basic Constraints: critical

                CA:TRUE

    Signature Algorithm: sha256WithRSAEncryption

         72:fe:42:82:60:40:ff:3f:1a:af:1d:e8:9f:38:97:53:1c:27:

         cb:27:c1:39:ca:12:e3:34:96:e5:d8:d4:52:ea:db:3c:7e:f9:

………

……….

openssl x509 -in server.crt -text –noout //查看server.crt

 

server.crt:

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 4096 (0x1000)

        Signature Algorithm: sha256WithRSAEncryption

        Issuer: CN = www.modelCA.com, O = Model CA LTD., C = US

        Validity

            Not Before: Dec 11 08:00:17 2023 GMT

            Not After : Dec  8 08:00:17 2033 GMT

        Subject: C = US, O = Bank32 Inc., CN = www.bank32.com

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                RSA Public-Key: (2048 bit)

                Modulus:

                    00:b2:ee:c2:5f:a0:4f:ce:ee:dd:17:45:12:12:99:

                    e2:95:f0:9a:c3:28:6a:68:59:ce:39:c2:11:b6:c5:

…..

…….

Exponent: 65537 (0x10001)

        X509v3 extensions:

            X509v3 Basic Constraints:

                CA:FALSE

            Netscape Comment:

                OpenSSL Generated Certificate

            X509v3 Subject Key Identifier:

                62:D9:32:A4:B5:D1:94:17:F7:8A:31:92:26:0A:AA:C3:1A:E5:96:14

            X509v3 Authority Key Identifier:

                keyid:D6:6D:CE:C9:5B:07:43:56:D1:8F:AC:3A:64:58:F8:3D:71:C4:5E:69

 

            X509v3 Subject Alternative Name:

                DNS:www.bank32.com, DNS:www.bank32A.com, DNS:www.bank32B.com

    Signature Algorithm: sha256WithRSAEncryption

         3b:56:03:f5:e2:1c:e3:95:66:60:70:47:44:13:8f:1b:44:4f:

         0b:84:a1:c3:fa:9a:20:8a:ee:f4:7b:00:07:e1:bb:13:7b:83:

……

……

Serial number 不一样

Task4. 在网络服务器中部署公钥证书

一旦银行收到了数字证书，它就可以在HTTPS网站中部署该证书。我们会基于Apache部署一个HTTPS web服务器。

Step1 将证书和私钥拷贝到volumes路径下，volumes目录在我们建的目录PKI路径下的Labsetup路径下

cp ~/PKI/server.crt ~/PKI/Labsetup/volumes

cp ~/PKI/server.key ~/PKI/Labsetup/volumes

 

 

Step2 在Lapsetup路径下启动容器服务器，进入shell，dockps 命令查看容器ID，docksh id的前两个符号即可进入容器shell

 

 

Dcup启动

Dockps查看

 

Step3 将主机传递过来的证书和私钥放到/certs路径下

cd volumes

cp server.crt server.key ../certs

 

 

Step4 进入到目录/etc/apache2/sites-available中查看文件,site-available是存放的所有可用站点信息。下面我们需要修改文件bank32_apache_ssl.conf。

修改可以有两种方式，一种是直接在容器中下载vi编辑器。命令如下：

apt-get update

apt-get install vim

修改前

 

 

 

修改后

 

 

其中<VirtualHost*:443>代表着当以HTTPS协议访问443端口时服务器相关配置：

ServerName条目指定网站的名称，而DocumentRoot条目指定网站文件存储的位置。同时我们需要告诉Apache服务器证书和私钥存储在哪里，后两行为证书和私钥文件的位置。

而下方<VirtualHost*:80>代表着当以HTTP协议访问80端口时服务器相关配置：

注意DirectoryIndex项的区别，访问80端口时为index_red.html；而访问443端口时为index.html

Step5 在容器shell中重启apache

 

 

这里需要输入证书口令：dees

a2enmod ssl // 使能SSL模式

a2ensite bank32_apache_ssl //使能文件中的配置信息

service apache2 restart //重启服务器，如果报错，根据提示修改配置文件即可

Step6 进入主机，打开浏览器输入https://www.bank32.com

可以打开，但提示有风险

 

 

 

 

 

 

 

 

提示网站没有进行网页加密，实际是以HTTP协议访问的服务器80端口.

下面我们解决这个问题，需要添加证书。服务器的证书我已经添加到容器中，而且在配置文件中进行了设置，之所以无法使用，是因为server证书是由我们自己建立的CA发放的，我们的这个CA还没有被浏览器认可，所以下面要设置Firefox，添加一个信任的Authority：

1.打开FireFox的设置

 

 

 

双击打开

 

 

 

点击OK，刷新页面, 能够安全访问www.bank32.com