摘要：常見(jiàn)的對(duì)稱(chēng)加密算法密鑰長(zhǎng)度可選等非對(duì)稱(chēng)加密非對(duì)稱(chēng)加密，密鑰成對(duì)出現(xiàn)，一公一私。申請(qǐng)者將自己的公鑰和個(gè)人站點(diǎn)信息發(fā)送給，請(qǐng)求其做認(rèn)證。定義了證書(shū)的結(jié)構(gòu)以及認(rèn)證協(xié)議標(biāo)準(zhǔn)，目前使用的是第三版。

對(duì)稱(chēng)加密中加密和解密使用相同的密鑰，加解密速度快，算法公開(kāi)，計(jì)算量小。

使用對(duì)稱(chēng)加密，交易雙方都使用同樣鑰匙，安全性得不到保證；每對(duì)用戶(hù)每次使用對(duì)稱(chēng)加密算法時(shí)，都需要使用其他人不知道的惟一鑰匙，這會(huì)使得發(fā)收信雙方所擁有的鑰匙數(shù)量呈幾何級(jí)數(shù)增長(zhǎng)，密鑰管理成為用戶(hù)的負(fù)擔(dān)。對(duì)稱(chēng)加密算法在分布式網(wǎng)絡(luò)系統(tǒng)上使用較為困難，主要是因?yàn)槊荑€管理困難，使用成本較高。

常見(jiàn)的對(duì)稱(chēng)加密算法：

DES（Data Encryption Standard）

3DES

AES（Advanced Encryption Standard）密鑰長(zhǎng)度可選128/192/258/384/512 bits

RC2、RC4、RC5、Blowfish 等

非對(duì)稱(chēng)加密，密鑰成對(duì)出現(xiàn)，一公一私。公鑰（public key）公開(kāi)給所有人，而私鑰自己保存，必須保證其私密性，如對(duì)私鑰加密或設(shè)置權(quán)限。

Bob將信息使用 Alice 的公鑰加密后發(fā)送給Alice，Alice 使用私鑰解密加密的文檔。非對(duì)稱(chēng)加密同樣也可以認(rèn)證身份，Alice 用自己的私鑰加密信息，如果 Bob 能用 Alice 的公鑰解密，則身份認(rèn)證成功。

非對(duì)稱(chēng)加密的三種用途：

數(shù)字簽名：用于讓接收方確認(rèn)發(fā)送方的身份，并確認(rèn)數(shù)據(jù)沒(méi)有篡改

密鑰交換：發(fā)送方用對(duì)方的公鑰加密一個(gè)對(duì)稱(chēng)密鑰，并發(fā)送給對(duì)方

數(shù)據(jù)加密

常見(jiàn)的非對(duì)稱(chēng)加密算法：

RSA：加密、解密、簽名

DSA：簽名

中間人攻擊Man-in-the-middle attack

Alice向 Bob 索取他的公鑰，Bob 將他的公鑰發(fā)送給 Alice，并且此時(shí) Mallory 攔截到 Bob 的公鑰

Mallory 將自己的公鑰發(fā)送給 Alice，Alice 認(rèn)為 Mallory 的公鑰就是 Bob 的公鑰

Alice 用 Mallory 的公鑰加密并將信息發(fā)送給 Bob，Mallory 攔截 Alice 信息，并解密

Mallory 將消息查看或者修改后，使用之前攔截的 Bob公鑰再次加密后，發(fā)送給 Bob

Bob 收到消息后，相信這是 Alice 發(fā)來(lái)的信息

單向加密只能加密，不能解密，又稱(chēng)為提取數(shù)據(jù)指紋。單向加密的作用是保證數(shù)據(jù)的完整性，單向加密會(huì)定長(zhǎng)輸入，當(dāng)原有數(shù)據(jù)被改變后，輸出會(huì)完全變化，又稱(chēng)為雪崩效應(yīng)。

常見(jiàn)的單向加密算法：

md5：128bit，按4位二進(jìn)制組合成一個(gè)16進(jìn)制數(shù)，結(jié)果由32個(gè)十六進(jìn)制數(shù)組成的數(shù)字串

sha1：160bit

sha224、sha256、sha384、sha512

PKI 公鑰基礎(chǔ)設(shè)施是抵御中間人攻擊的一種認(rèn)證技術(shù)，方法是 PKI 的相互認(rèn)證的機(jī)制。

只要能安全的傳輸公鑰，就能避免中間人攻擊。要保證公鑰不被替換，就需要一個(gè)可信的認(rèn)證機(jī)構(gòu)對(duì)公鑰進(jìn)行公證。

PKI 的主要的四個(gè)組件：

簽證結(jié)構(gòu)：CA，生成數(shù)字證書(shū)

登記機(jī)構(gòu)：RA，接收證書(shū)請(qǐng)求，驗(yàn)證請(qǐng)求者身份，相當(dāng)于 CA 的前端代理

證書(shū)吊銷(xiāo)列表：CRL，保存證書(shū)頒發(fā)機(jī)構(gòu) CA 已經(jīng)吊銷(xiāo)的證書(shū)序列號(hào)和吊銷(xiāo)日期

PKI 存取庫(kù)：對(duì)用戶(hù)申請(qǐng)、證書(shū)、密鑰、CRL 和日志信息進(jìn)行存儲(chǔ)和管理

CA是有公信力的認(rèn)證中心。申請(qǐng)者將自己的公鑰和個(gè)人（站點(diǎn)）信息發(fā)送給CA，請(qǐng)求其做認(rèn)證。CA進(jìn)行驗(yàn)證后，將申請(qǐng)人的信息和公鑰使用Hash算法提取消息摘要，然后CA使用自己的私鑰對(duì)消息摘要進(jìn)行加密形成數(shù)字簽名。CA將申請(qǐng)者的個(gè)人信息和申請(qǐng)者的公鑰加上數(shù)字簽名形成了數(shù)字證書(shū)，并發(fā)送給申請(qǐng)者。X.509定義了證書(shū)的結(jié)構(gòu)以及認(rèn)證協(xié)議標(biāo)準(zhǔn)，目前使用的是第三版。

發(fā)送方發(fā)送信息時(shí)同時(shí)也發(fā)送自己的數(shù)字證書(shū)，當(dāng)接收方收到信息和數(shù)字證書(shū)時(shí)，接收方使用Hash算法對(duì)證書(shū)中的個(gè)人信息和公鑰進(jìn)行提取指紋，然后使用CA的公鑰對(duì)數(shù)字簽名進(jìn)行解密，對(duì)比自己生成的消息摘要和解密出來(lái)的數(shù)字簽名是否一致，如果一致，則發(fā)送方的公鑰可用。

CA本身也有證書(shū)來(lái)證明自己的身份，并且CA是一種樹(shù)形結(jié)構(gòu)，高級(jí)別的CA會(huì)給低級(jí)別的CA做信用背書(shū)，操作系統(tǒng)和瀏覽器已經(jīng)內(nèi)置了頂層的CA證書(shū)。

CA 參與的安全通信過(guò)程：

首先保證CA為通信雙方都認(rèn)可的機(jī)構(gòu)

通信雙方向CA申請(qǐng)數(shù)字證書(shū)，包含了各自的公鑰

CA對(duì)通信雙方進(jìn)行合法性驗(yàn)證，通過(guò)則使用CA的私鑰對(duì)申請(qǐng)文件進(jìn)行加密（數(shù)字簽名），并將數(shù)字簽名和個(gè)人信息整理為一個(gè)數(shù)字證書(shū)

通信雙方下載各自由CA簽發(fā)的數(shù)字證書(shū)

當(dāng)發(fā)送方要發(fā)送信息時(shí)，首先向接收方請(qǐng)求其數(shù)字證書(shū)

接收方利用CA的公鑰檢查接收到的數(shù)字證書(shū)是否合法，并得到接收方的公鑰

發(fā)送方利用散列函數(shù)對(duì)明文數(shù)據(jù)提取指紋，然后通過(guò)程序隨機(jī)生成一個(gè)session key，利用這個(gè)session key對(duì)明文數(shù)據(jù)進(jìn)行對(duì)稱(chēng)加密，最后發(fā)送方用接收方的公鑰對(duì)session key進(jìn)行非對(duì)稱(chēng)加密

發(fā)送方將自己的證書(shū)和加密后的文件（包含session key）發(fā)送給接收方

接收方用CA的公鑰驗(yàn)證發(fā)送方數(shù)字證書(shū)的合法性，包括用CA的公鑰解密數(shù)字證書(shū)、用相同的簽名算法ID提取指紋并與簽名比對(duì)、數(shù)字證書(shū)的有效期、證書(shū)的主體名和被訪(fǎng)問(wèn)的主機(jī)名或人名是否相同以及證書(shū)是否在吊銷(xiāo)列表中。
如果合法，則利用自己的私鑰對(duì)session key進(jìn)行解密得到明文數(shù)據(jù)，然后利用散列函數(shù)對(duì)明文數(shù)據(jù)提取指紋，將自己得到的指紋與發(fā)送方發(fā)來(lái)的指紋進(jìn)行對(duì)比，如果一致，則沒(méi)有被篡改，安全通信完成。

以上，對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密解決了數(shù)據(jù)的保密性，單向加密解決了數(shù)據(jù)的完整性，使用 PKI 解決了數(shù)據(jù)的可用性或者是來(lái)源合法性。這樣就建立了一個(gè)安全的通信。

1994年，NetScape公司設(shè)計(jì)了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布，設(shè)計(jì) SSL 的目的是是為了對(duì)http報(bào)文進(jìn)行加密，隨后又陸續(xù)發(fā)布了2.0和3.0。1999年，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司，發(fā)布了SSL的升級(jí)版TLS （Transport Layer Security）1.0版，目前 TLS 的版本是TLS 1.3。

SSL/TLS發(fā)生作用的位置在 ISO/OSI 參考模型中的表示層、TCP/IP 模型中的應(yīng)用層。

SSL協(xié)議分為兩部分：Handshake protocol和Record Protocol。

Handshake Protocol用來(lái)在通信雙方協(xié)商出一個(gè)安全的會(huì)話(huà)密鑰以供后續(xù)對(duì)稱(chēng)加密中使用。Record Protocol則定義了傳輸?shù)姆庋b格式。

SSL/TLS協(xié)議通信的大概過(guò)程：

客戶(hù)端向服務(wù)端索要公鑰（證書(shū)）并驗(yàn)證

雙方協(xié)商生成“會(huì)話(huà)密鑰”

后續(xù)使用“會(huì)話(huà)密鑰”加密通信

首先，客戶(hù)端發(fā)出請(qǐng)求（ClientHello），將本地支持的加密套件（Cipher Suit）的列表，也就是本地支持的加密算法、支持的TLS版本、支持的壓縮方法發(fā)送到服務(wù)端。另外產(chǎn)生一個(gè)隨機(jī)數(shù)發(fā)送到服務(wù)端，同時(shí)保存在本地一個(gè)副本，稍后用于生成會(huì)話(huà)密鑰。

然后，服務(wù)端回應(yīng)（ServerHello），將服務(wù)端的數(shù)字證書(shū)發(fā)送給客戶(hù)端，并確認(rèn)使用的加密通信協(xié)議版本（也就是安全套件）、服務(wù)器生成的隨機(jī)數(shù)、確認(rèn)使用的加密算法。

其次，客戶(hù)端收到服務(wù)端證書(shū)根據(jù)證書(shū)鏈驗(yàn)證真實(shí)性后，得到服務(wù)器的可信公鑰，然后再發(fā)送一個(gè)新的隨機(jī)數(shù)、編碼改變通知（隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送）、客戶(hù)端握手結(jié)束通知。

最后，服務(wù)端收到第三個(gè)隨機(jī)數(shù)后，計(jì)算生成本次會(huì)話(huà)使用的會(huì)話(huà)密鑰，然后發(fā)送編碼改變通知和服務(wù)器握手結(jié)束通知。

隨后的通信使用的http協(xié)議，然后使用會(huì)話(huà)密鑰加密。

TLS 安全密碼套件

密鑰交換

身份驗(yàn)證

對(duì)稱(chēng)加密算法、強(qiáng)度、分組模式

簽名 hash 算法

建立私有 CA

1.安裝 openssl：yum install openssl -y

2.生成 CA 的密鑰對(duì)：(umask 077;openssl genrsa -out /etc/pki/CA/private/cakey.pem 2048)

3.生成自簽證書(shū)和相關(guān)文件：openssl req -new -x509 -key /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem -days 365

req：生成證書(shū)簽署請(qǐng)求

-new：新請(qǐng)求

-key ...：指定私鑰文件

-out .../-x509：生成自簽署證書(shū)的位置和格式

-days：有效天數(shù)

4.初始化 CA 工作環(huán)境： touch /etc/pki/CA/{index.txt,serial};echo 01/etc/pki/CA/serial

與 CA 配置的相關(guān)文件是/etc/pki/tls/openssl.cnf ，index.txt是數(shù)據(jù)庫(kù)索引文件， serial 是用來(lái)記錄簽證相關(guān)信息的。

站點(diǎn)申請(qǐng)證書(shū)

1.安裝 openssl

2.生成密鑰，保存在服務(wù)配置文件目錄下

mkdir /usr/nginx-1.14.2/conf/ssl
ln -s /usr/nginx-1.14.2/conf/ssl/ /etc/nginx/ssl
(umask 077;openssl genrsa -out /etc/nginx/ssl/nginx.key 2048)

3.生成證書(shū)簽署請(qǐng)求：openssl req -new -key /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.csr

需要注意的是，填寫(xiě)的信息需要與 CA 端保持一致，Organization Name 也必須保持一致。

4.將簽署請(qǐng)求文件 nginx.csr發(fā)送給 CA 服務(wù)

CA 簽署請(qǐng)求文件

1.簽署請(qǐng)求文件：openssl ca -in /tmp/nginx.csr -out /tmp/nginx.crt -days 365

2.將證書(shū)發(fā)送給請(qǐng)求客戶(hù)端

3.其他：CA 吊銷(xiāo)證書(shū)openssl ca -revoke nginx.crt

站點(diǎn)部署證書(shū)

將證書(shū)保存在/etc/nginx/ssl/目錄下，由于之前編譯安裝的 nginx，默認(rèn)沒(méi)有將ssl_module編譯，所以需要重新將帶有 ssl 模塊一同編譯nginx。

回到 Nginx 源碼目錄下，加上 SSL 模塊，再次編譯：

./configure --prefix=/usr/nginx-1.14.2/ --with-http_ssl_module
make

由于當(dāng)前操作是升級(jí)操作，之前使用的 Nginx 配置文件等不能被覆蓋，所以不能使用make install，需要備份原nginx 二進(jìn)制文件，將新的 nginx 二進(jìn)制文件覆蓋即可

cp /usr/nginx-1.14.2/sbin/nginx /usr/nginx-1.14.2/sbin/nginx.without_ssl.bak
cp /tmp/nginx-1.14.2/objs/nginx /usr/nginx-1.14.2/sbin/nginx

objs/nginx是新編譯的 nginx 程序，覆蓋原 nginx 程序，啟動(dòng) nginx。

修改nginx配置文件，開(kāi)啟 https

server {
        listen  443; #監(jiān)聽(tīng)端口為443
        server_name devops.yellowdog.com;

        ssl on; #開(kāi)啟 ssl
        ssl_certificate /etc/nginx/ssl/nginx.crt; #證書(shū)位置
        ssl_certificate_key /etc/nginx/ssl/nginx.key; #私鑰位置
        ssl_session_timeout 5m; 
        ssl_protocols SSLv2 SSLv3 TLSv1; #指定密碼為 openssl 支持的格式
        ssl_ciphers HIGH:!aNull:!MD5; #密碼加密方式
        ssl_prefer_server_ciphers on; #依賴(lài) SSLv3和 TLSv1協(xié)議的服務(wù)器密碼將優(yōu)先于客戶(hù)端密碼
        location / {
            alias dlib/; #根目錄相對(duì)位置
        }
    }

另外還設(shè)置將80端口的訪(fǎng)問(wèn)重定向至443端口

server {
    listen       80;
    server_name  devops.yellowdog.com;
    rewrite ^(.*)$ https://$server_name$1 permanent;
}

部署 https 站點(diǎn)總體不難，但重點(diǎn)要理解安全通信中的原理。

推薦文章：圖解openssl實(shí)現(xiàn)私有CA