摘要:常見的對稱加密算法密鑰長度可選等非對稱加密非對稱加密,密鑰成對出現,一公一私。申請者將自己的公鑰和個人站點信息發送給,請求其做認證。定義了證書的結構以及認證協議標準,目前使用的是第三版。
對稱加密
對稱加密中加密和解密使用相同的密鑰,加解密速度快,算法公開,計算量小。
使用對稱加密,交易雙方都使用同樣鑰匙,安全性得不到保證;每對用戶每次使用對稱加密算法時,都需要使用其他人不知道的惟一鑰匙,這會使得發收信雙方所擁有的鑰匙數量呈幾何級數增長,密鑰管理成為用戶的負擔。對稱加密算法在分布式網絡系統上使用較為困難,主要是因為密鑰管理困難,使用成本較高。
常見的對稱加密算法:
DES(Data Encryption Standard)
3DES
AES(Advanced Encryption Standard)密鑰長度可選128/192/258/384/512 bits
RC2、RC4、RC5、Blowfish 等
非對稱加密非對稱加密,密鑰成對出現,一公一私。公鑰(public key)公開給所有人,而私鑰自己保存,必須保證其私密性,如對私鑰加密或設置權限。
Bob將信息使用 Alice 的公鑰加密后發送給Alice,Alice 使用私鑰解密加密的文檔。非對稱加密同樣也可以認證身份,Alice 用自己的私鑰加密信息,如果 Bob 能用 Alice 的公鑰解密,則身份認證成功。
非對稱加密的三種用途:
數字簽名:用于讓接收方確認發送方的身份,并確認數據沒有篡改
密鑰交換:發送方用對方的公鑰加密一個對稱密鑰,并發送給對方
數據加密
常見的非對稱加密算法:
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
sha224、sha256、sha384、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 參與的安全通信過程:
首先保證CA為通信雙方都認可的機構
通信雙方向CA申請數字證書,包含了各自的公鑰
CA對通信雙方進行合法性驗證,通過則使用CA的私鑰對申請文件進行加密(數字簽名),并將數字簽名和個人信息整理為一個數字證書
通信雙方下載各自由CA簽發的數字證書
當發送方要發送信息時,首先向接收方請求其數字證書
接收方利用CA的公鑰檢查接收到的數字證書是否合法,并得到接收方的公鑰
發送方利用散列函數對明文數據提取指紋,然后通過程序隨機生成一個session key,利用這個session key對明文數據進行對稱加密,最后發送方用接收方的公鑰對session key進行非對稱加密
發送方將自己的證書和加密后的文件(包含session key)發送給接收方
接收方用CA的公鑰驗證發送方數字證書的合法性,包括用CA的公鑰解密數字證書、用相同的簽名算法ID提取指紋并與簽名比對、數字證書的有效期、證書的主體名和被訪問的主機名或人名是否相同以及證書是否在吊銷列表中。
如果合法,則利用自己的私鑰對session key進行解密得到明文數據,然后利用散列函數對明文數據提取指紋,將自己得到的指紋與發送方發來的指紋進行對比,如果一致,則沒有被篡改,安全通信完成。
以上,對稱加密和非對稱加密解決了數據的保密性,單向加密解決了數據的完整性,使用 PKI 解決了數據的可用性或者是來源合法性。這樣就建立了一個安全的通信。
SSL/TLS1994年,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協議通信的大概過程:
客戶端向服務端索要公鑰(證書)并驗證
雙方協商生成“會話密鑰”
后續使用“會話密鑰”加密通信
首先,客戶端發出請求(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
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/40380.html
摘要:然后再將這兩個文件夾給定權限和所有權上面的就是默認的用戶組合用戶名。 原文來自: https://www.codecasts.com/blo... 在維護 codecasts 期間,遇到很多次一個 nginx 如何配置多個站點 的問題,我通常的回復就是:多添加一個 server 的 block 配置就好了,然而很多同學還是沒能配置成功,今天我們仔細來看看在 一臺 Ubuntu 的服務器...
摘要:是一款輕量級的服務器反向代理服務器及電子郵件代理服務器,并在一個協議下發行。表明它使用了,但存在不同于的默認端口及一個加密身份驗證層在與之間。現在它被廣泛用于萬維網上安全敏感的通訊,例如交易支付方面。 Nginx Nginx是一款輕量級的Web 服務器/反向代理服務器及電子郵件(IMAP/POP3)代理服務器,并在一個BSD-like 協議下發行。其特點是占有內存少,并發能力強,事實上...
閱讀 1938·2021-11-24 09:39
閱讀 3277·2021-09-22 14:58
閱讀 1162·2019-08-30 15:54
閱讀 3315·2019-08-29 11:33
閱讀 1788·2019-08-26 13:54
閱讀 1598·2019-08-26 13:35
閱讀 2468·2019-08-23 18:14
閱讀 762·2019-08-23 17:04