Nginx(3)-建立 https 站點

對稱加密

對稱加密中加密和解密使用相同的密鑰，加解密速度快，算法公開，計算量小。

使用對稱加密，交易雙方都使用一樣鑰匙，安全性得不到保證；每對用戶每次使用對稱加密算法時，都須要使用其餘人不知道的唯一鑰匙，這會使得發收信雙方所擁有的鑰匙數量呈幾何級數增加，密鑰管理成爲用戶的負擔。對稱加密算法在分佈式網絡系統上使用較爲困難，主要是由於密鑰管理困難，使用成本較高。

常見的對稱加密算法：

• DES（Data Encryption Standard）
• 3DES
• AES（Advanced Encryption Standard）密鑰長度可選128/192/258/384/512 bits
• RC二、RC四、RC五、Blowfish 等

非對稱加密

非對稱加密，密鑰成對出現，一公一私。公鑰（public key）公開給全部人，而私鑰本身保存，必須保證其私密性，如對私鑰加密或設置權限。

Bob將信息使用 Alice 的公鑰加密後發送給Alice，Alice 使用私鑰解密加密的文檔。非對稱加密一樣也能夠認證身份，Alice 用本身的私鑰加密信息，若是 Bob 能用 Alice 的公鑰解密，則身份認證成功。

非對稱加密的三種用途：

1. 數字簽名：用於讓接收方確認發送方的身份，並確認數據沒有篡改
2. 密鑰交換：發送方用對方的公鑰加密一個對稱密鑰，併發送給對方
3. 數據加密

常見的非對稱加密算法：

• RSA：加密、解密、簽名
• DSA：簽名

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

• Alice向 Bob 索取他的公鑰，Bob 將他的公鑰發送給 Alice，而且此時 Mallory 攔截到 Bob 的公鑰
• Mallory 將本身的公鑰發送給 Alice，Alice 認爲 Mallory 的公鑰就是 Bob 的公鑰
• Alice 用 Mallory 的公鑰加密並將信息發送給 Bob，Mallory 攔截 Alice 信息，並解密
• Mallory 將消息查看或者修改後，使用以前攔截的 Bob公鑰再次加密後，發送給 Bob
• Bob 收到消息後，相信這是 Alice 發來的信息

單向加密

單向加密只能加密，不能解密，又稱爲提取數據指紋。單向加密的做用是保證數據的完整性，單向加密會定長輸入，當原有數據被改變後，輸出會徹底變化，又稱爲雪崩效應。

常見的單向加密算法：

• md5：128bit，按4位二進制組合成一個16進制數，結果由32個十六進制數組成的數字串
• sha1：160bit
• sha22四、sha25六、sha38四、sha512

PKI公鑰基礎設施

PKI 公鑰基礎設施是抵禦中間人攻擊的一種認證技術，方法是 PKI 的相互認證的機制。

只要能安全的傳輸公鑰，就能避免中間人攻擊。要保證公鑰不被替換，就須要一個可信的認證機構對公鑰進行公證。

PKI 的主要的四個組件：

• 簽證結構：CA，生成數字證書
• 登記機構：RA，接收證書請求，驗證請求者身份，至關於 CA 的前端代理
• 證書吊銷列表：CRL，保存證書頒發機構 CA 已經吊銷的證書序列號和吊銷日期
• PKI 存取庫：對用戶申請、證書、密鑰、CRL 和日誌信息進行存儲和管理

CA是有公信力的認證中心。申請者將本身的公鑰和我的（站點）信息發送給CA，請求其作認證。CA進行驗證後，將申請人的信息和公鑰使用Hash算法提取消息摘要，而後CA使用本身的私鑰對消息摘要進行加密造成數字簽名。CA將申請者的我的信息和申請者的公鑰加上數字簽名造成了數字證書，併發送給申請者。X.509定義了證書的結構以及認證協議標準，目前使用的是第三版。

發送方發送信息時同時也發送本身的數字證書，當接收方收到信息和數字證書時，接收方使用Hash算法對證書中的我的信息和公鑰進行提取指紋，而後使用CA的公鑰對數字簽名進行解密，對比本身生成的消息摘要和解密出來的數字簽名是否一致，若是一致，則發送方的公鑰可用。

CA自己也有證書來證實本身的身份，而且CA是一種樹形結構，高級別的CA會給低級別的CA作信用背書，操做系統和瀏覽器已經內置了頂層的CA證書。

CA 參與的安全通訊過程：

1. 首先保證CA爲通訊雙方都承認的機構
2. 通訊雙方向CA申請數字證書，包含了各自的公鑰
3. CA對通訊雙方進行合法性驗證，經過則使用CA的私鑰對申請文件進行加密（數字簽名），並將數字簽名和我的信息整理爲一個數字證書
4. 通訊雙方下載各自由CA簽發的數字證書
5. 當發送方要發送信息時，首先向接收方請求其數字證書
6. 接收方利用CA的公鑰檢查接收到的數字證書是否合法，並獲得接收方的公鑰
7. 發送方利用散列函數對明文數據提取指紋，而後經過程序隨機生成一個session key，利用這個session key對明文數據進行對稱加密，最後發送方用接收方的公鑰對session key進行非對稱加密
8. 發送方將本身的證書和加密後的文件（包含session key）發送給接收方
9. 接收方用CA的公鑰驗證發送方數字證書的合法性，包括用CA的公鑰解密數字證書、用相同的簽名算法ID提取指紋並與簽名比對、數字證書的有效期、證書的主體名和被訪問的主機名或人名是否相同以及證書是否在吊銷列表中。
   若是合法，則利用本身的私鑰對session key進行解密獲得明文數據，而後利用散列函數對明文數據提取指紋，將本身獲得的指紋與發送方發來的指紋進行對比，若是一致，則沒有被篡改，安全通訊完成。

以上，對稱加密和非對稱加密解決了數據的保密性，單向加密解決了數據的完整性，使用 PKI 解決了數據的可用性或者是來源合法性。這樣就創建了一個安全的通訊。

SSL/TLS

1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，可是未發佈，設計 SSL 的目的是是爲了對http報文進行加密，隨後又陸續發佈了2.0和3.0。1999年，互聯網標準化組織ISOC接替NetScape公司，發佈了SSL的升級版TLS （Transport Layer Security）1.0版，目前 TLS 的版本是TLS 1.3。

SSL/TLS發生做用的位置在 ISO/OSI 參考模型中的表示層、TCP/IP 模型中的應用層。

SSL協議分爲兩部分：Handshake protocol和Record Protocol。

Handshake Protocol用來在通訊雙方協商出一個安全的會話密鑰以供後續對稱加密中使用。Record Protocol則定義了傳輸的封裝格式。

SSL/TLS協議通訊的大概過程：

1. 客戶端向服務端索要公鑰（證書）並驗證
2. 雙方協商生成「會話密鑰」
3. 後續使用「會話密鑰」加密通訊

首先，客戶端發出請求（ClientHello），將本地支持的加密套件（Cipher Suit）的列表，也就是本地支持的加密算法、支持的TLS版本、支持的壓縮方法發送到服務端。另外產生一個隨機數發送到服務端，同時保存在本地一個副本，稍後用於生成會話密鑰。

而後，服務端迴應（ServerHello），將服務端的數字證書發送給客戶端，並確認使用的加密通訊協議版本（也就是安全套件）、服務器生成的隨機數、確認使用的加密算法。

其次，客戶端收到服務端證書根據證書鏈驗證真實性後，獲得服務器的可信公鑰，而後再發送一個新的隨機數、編碼改變通知（隨後的信息都將用雙方商定的加密方法和密鑰發送）、客戶端握手結束通知。

最後，服務端收到第三個隨機數後，計算生成本次會話使用的會話密鑰，而後發送編碼改變通知和服務器握手結束通知。

隨後的通訊使用的http協議，而後使用會話密鑰加密。

TLS 安全密碼套件

• 密鑰交換
• 身份驗證
• 對稱加密算法、強度、分組模式
• 簽名 hash 算法

使用私有 CA 實現 https 站點

創建私有 CA

1.安裝 openssl：yum install openssl -y

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

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

• req：生成證書籤署請求
• -new：新請求
• -key ...：指定私鑰文件
• -out .../-x509：生成自簽署證書的位置和格式
• -days：有效天數

4.初始化 CA 工做環境： touch /etc/pki/CA/{index.txt,serial};echo 01/etc/pki/CA/serial

與 CA 配置的相關文件是/etc/pki/tls/openssl.cnf ，index.txt是數據庫索引文件， serial 是用來記錄簽證相關信息的。

站點申請證書

1.安裝 openssl

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

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.生成證書籤署請求：openssl req -new -key /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.csr

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

4.將簽署請求文件 nginx.csr發送給 CA 服務

CA 簽署請求文件

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

2.將證書發送給請求客戶端

3.其餘：CA 吊銷證書openssl ca -revoke nginx.crt

站點部署證書

將證書保存在/etc/nginx/ssl/目錄下，因爲以前編譯安裝的 nginx，默認沒有將ssl_module編譯，因此須要從新將帶有 ssl 模塊一同編譯nginx。

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

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

因爲當前操做是升級操做，以前使用的 Nginx 配置文件等不能被覆蓋，因此不能使用make install，須要備份原nginx 二進制文件，將新的 nginx 二進制文件覆蓋便可

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 程序，啓動 nginx。

修改nginx配置文件，開啓 https

server {
        listen  443; #監聽端口爲443
        server_name devops.yellowdog.com;

        ssl on; #開啓 ssl
        ssl_certificate /etc/nginx/ssl/nginx.crt; #證書位置
        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; #依賴 SSLv3和 TLSv1協議的服務器密碼將優先於客戶端密碼
        location / {
            alias dlib/; #根目錄相對位置
        }
    }

另外還設置將80端口的訪問重定向至443端口

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

總結

部署 https 站點整體不難，但重點要理解安全通訊中的原理。

推薦文章：圖解openssl實現私有CA