一、什麼是 RSA、SSL、HTTPS

RSA：它是非對稱加密演算法的一種，而且是最常用的一種。它的理論基礎是：計算兩個大質數的乘積非常簡單，而對該乘積進行因子分解就非常困難。而且

         這兩個質數越大，對其乘積的分解就越困難。RSA生成的金鑰對有公鑰和私鑰之分，不過，貌似金鑰對中的任何一個當公鑰都行，公鑰是可以公開的，

         私鑰只有自己知道，公鑰加密的資料只有私鑰才能解密，反之私鑰加密的資料也只有公鑰才能解密。目前，公開宣告破解的金鑰位數是768位，因此

         長度為1024的RSA金鑰是有一定危險的，建議金鑰用2048位的。量子計算機對破解RSA比較有效。

SSL：全稱是Secure Sockets Layer，是介於TCP層協議和HTTP協議之間的協議，如果用TCP/IP五層協議來考察，那SSL屬於應用層，與HTTP在同一層。

        SSL協議與HTTP協議沒任何關係，它是一個安全協議，用於對資料包（有應用層協議頭）進行加密，因此，我們也可以對FTP、SMTP等協議用SSL協議

        加密，即FTPS、SMTPS。SSL採用非對稱加密演算法，比如可以選擇RSA演算法。

HTTPS：它其實只是SSL協議+HTTP協議的組合而已，類似的還有FTPS、SMTPS等等。HTTPS 不同於 HTTP 的埠，HTTP預設埠為80，而HTTPS默

        認埠為443。

數字簽名：用私鑰對傳送的資訊的hash值進行加密，得到的加密資料就是數字簽名，我們最常見到的是CA對數字證書進行簽名。數字簽名的作用是可以檢查

         資料在傳輸過程中是否被人篡改了，因為如果篡改了，那hash值必定會變化，就與數字簽名解密後的值不一樣了，而由於篡改者沒有CA私鑰，所以沒

         法重新生成數字簽名。你可能會問，為什麼不直接對資訊加密，而是要對其hash值進行加密呢？從效力上講，兩者是等效的，都可以驗證資訊是否被人

         篡改過。當資訊量大時，直接對資訊加密（以及客戶端收到資訊後解密）太耗時，所以用資訊的hash值。

數字證書：裡面包含伺服器公鑰、其它資訊、還會附加伺服器公鑰和證書資訊的數字簽名。這裡的其它資訊包含頒發者、有效期、使用者common name-簡稱CN，

         簽名演算法，簽名雜湊演算法等。一般來說，我們會使用權威CA認證頒發的數字證書，該證書中附加的數字簽名就是CA用自己的私鑰對“證書中的公鑰和

         證書資訊“的hash值加密後得到的。我們可以看到，數字證書本身是沒有加密的，只是附加了一個數字簽名而已，因此，在傳輸過程中別人是可以竊聽

         的，不過沒有關係，我們在傳輸數字證書時，主要是防止別人的篡改和冒充，保證公鑰就是客戶端所訪問的伺服器發來的公鑰，而沒有被人篡改，也

         沒有被冒充，關於冒充，見下面的SSL實現的功能第3點。我們可以通過檢查數字簽名來保證沒有被篡改，通過該證書的頒發者是否為權威CA以及

         common name是否為http request header中的host(不包括埠)來保證沒有被別人冒充。

使用SSL可以實現下面的功能：

1、資料加密傳輸，防止竊聽。SSL常用的非對稱加密演算法是RSA，RSA基於的理論是：兩個大質數相乘計算非常容易，但對該乘積進行因子分解非常困難，

     而且該乘積越大，破解越難。目前公開宣告破解的金鑰位數是768，因此金鑰長度為1024的RSA是有一定危險的，建議金鑰長度用2048位。量子計算

     機對破解RSA有效，目前還不確定美國國安局NSA是否已經掌握了長金鑰RSA的破解方法。

2、可以進行資料完整性檢查，防篡改。

3、可以進行身份驗證，防冒充。比如客戶端給服務端發請求時，先要DNS查詢伺服器的IP，而DNS時被一個黑客攔截，返回了黑客指定的IP，該IP的服務

     給客戶端返回了一個證書，為了使客戶端驗證通過，該證書必須是權威CA機構頒發的，而且證書中的伺服器域名必須與客戶端請求的域名相同，為了保

     證這兩點，那黑客要有某個權威CA頒發的該域名的證書，如果該黑客想直接在權威CA上申請該域名的證書，那是不可行的，因為CA會用一些辦法（比

     如給註冊域名時所用的郵箱發一封確認郵件）驗證該域名是否屬性黑客，顯然，黑客無法通過驗證。另一種方法是黑客直接用瀏覽器等客戶端去從服務

     端獲取，這是可以得到的。但是黑客無法獲取到伺服器私鑰，這樣即使它將伺服器的IP定向到自己的伺服器，但客戶端發來的對稱金鑰由於是用證書中

     包含的公鑰加密的，黑客是無法解密的。

二、SSL通訊過程

     這裡只是一個簡化的通訊過程（主要簡化了生成對稱金鑰的過程），目的只是方便理解SSL原理。

     首先，要向CA申請證書，也可以是自籤的證書。在證書請求檔案中，包含服務端的公鑰，還有域名、Email、地址等資訊。CA用自己的私鑰將這些資訊

加密生成一個證書，該證書會註明CA名稱。我們向CA申請證書基於一個假設：即認為CA的證書是可靠的，可信的。我們可以看到，其實SSL通訊過程中，

涉及到兩對非對稱金鑰和一對對稱金鑰。兩對非對稱金鑰是指CA自己的非對稱金鑰和我們伺服器的非對稱金鑰，簡單說一下他們的作用，如下

      CA非對稱金鑰對的作用：簡單點說吧，CA用私鑰對證書進行加密（注：證書中包含伺服器的公鑰），這樣可以做到黑客無法篡改證書中的公鑰，保證公鑰

只能是域名伺服器發來的。如果不用CA私鑰加密證書，那證書傳輸過程中，黑客可以劫持並篡改證書中的公鑰為自己的公鑰，並通過DNS劫持和修改，指向自己

的伺服器IP，這是非常危險的。CA的非對稱金鑰中，私鑰由CA自己儲存，當用戶申請CA證書時，CA會用該私鑰對證書進行數字簽名，這樣可以保證黑客無法修

改證書，因為黑客修改證書資訊後，必須重新計算hash，重新生成加密生成數字簽名，但黑客沒有CA的私鑰，所以沒法對該hash加密。在SSL通訊過程中，當

客戶端收到伺服器發來的證書後，先計算出該證書資訊的hash，然後用CA公鑰解密證書上的數字簽名，得到hash，如果兩個hash相同，那就說明證書沒有被篡

改過。

     伺服器非對稱金鑰對的作用：加密解密對稱金鑰，在SSL通訊過程中，客戶端將對稱金鑰發給伺服器時，要用伺服器的非對稱金鑰加密的，這樣保證對稱金鑰

的傳輸安全。

SSL握手過程如下：

1、客戶端向伺服器發請求，請求證書

2、伺服器把證書發給客戶端

3、客戶端一般會有大部分CA的公鑰，客戶端收到證書後，檢查該頒發者是否是客戶端認可的CA，如果是，就用該CA的公鑰解密數字簽名，然後再計算

    證書中的”公鑰和證書資訊“的hash值，比較兩者，如果相同，那就說明該證書沒有被人篡改過，而且是該CA機構頒發的。當然，還會進行其它驗證，

    如證書的common name與http request header中的host（不包括埠）是否相同，等等，如果有哪項檢查不通過，會有告警，如果所有檢查通過，

    那進入第4步。

4、客戶端生成對稱金鑰，用證書中的公鑰加密，發給伺服器

5、伺服器收到對稱金鑰後儲存，給客戶端一個應答。

6、客戶端接收響應，這樣就完成了SSL連線，後面的通訊用對稱金鑰加密資料傳輸。  

因為非對稱加密相對對稱加密來說比較耗時，所以正式的資料傳輸是用對稱加密演算法。非對稱加密只是用於建立SSL時對稱金鑰的安全傳輸。我們可以設定

HTTPS長連線，這樣建立好SSL+HTTP連線後，可以用這個連線發多次HTTPS請求，而不用每次請求都建立連線。

三、什麼網站需要使用SSL證書

這塊我還沒完全搞懂，因為很多網站在登陸時用HTTPS，而登陸後用的HTTP，我有些不解，因為登陸時用HTTPS可以防止別人截獲使用者名稱和

密碼，那登陸後用HTTP就不怕被人截獲cookie嗎？莫非可以使用HTTPS中的對稱金鑰對HTTP中的資料進行加密？

四、自籤SSL證書

需要先安裝openssl，使用openssl給伺服器生成RSA金鑰及證書。如果是用權威的CA，在你申請CA證書過程中，他會幫你生成私鑰，這樣你就不需要用openssl生成了。

startssl就提供了這個功能。

# 生成一個RSA私鑰,1024是加密強度，一般是1024或2048 
$ openssl genrsa -out private.key 1024
 
# 生成一個證書請求
$ openssl req -new -key private.key -out cert_req.csr

# 自己簽發證書，如果要權威CA簽發的話，要把cert_req.csr發給CA
$ openssl x509 -req -days 365 -in cert_req.csr -signkey private.key -out server_cert.crt

第2個命令是生成證書請求，會提示輸入省份、城市、域名（圖中的Common Name）、Email等，這裡主要是保證Common Name用網站域名，

如果沒有申請域名，客戶端直接通過伺服器IP訪問，那這裡就輸入伺服器IP。另外，對於自簽名的證書，建議生成的私鑰不要加密。生成的證

書請求檔案cert_req.csr中除了包含這些手動輸入的資訊外，它還包含private.key對應的公鑰，你可能會有一個疑問，根據私鑰就能生成公鑰嗎？

當然不是，如果只單純的知道私鑰，可以認為是無法計算出公鑰的，關鍵在於Putty在產生私鑰時，還會在記憶體中儲存必要的公鑰引數。最後由該證

書生成自籤的證書，見圖1.

編輯配置檔案nginx.conf，給站點加上HTTPS協議，重啟Nginx後即可通過https訪問網站了。

server {
    server_name 192.168.1.100; # 客戶端直接用IP來訪問
    # 這是預設的SSL埠，可以修改為其它埠，瀏覽器用https訪問url時，預設就是用這個埠，
    # 如果下面listen修改成其它埠，那瀏覽器用https訪問時，就要指定埠了。
    listen 443; 
    ssl on;
    ssl_certificate /home/xiaobai/server_cert.crt;
    #使用無密碼私鑰
    ssl_certificate_key /usr/xiaobai/private.key;
}

     在SSL握手的過程中，客戶端收到服務端的證書後，會對證書進行多項檢查，如果檢查不通過，就會用告警，不過這些也只是告警而已，他不會

禁止你訪問。常用的瀏覽器（如FireFox、Chrome）會給你提供兩種方案：第一種方案是你可以選擇繼續訪問，這樣在你關閉瀏覽器之前，可以

訪問包含該根URL下的所有URL，但是當你關閉瀏覽器後，再次開啟時還會有警告，我們可以認為，瀏覽器只是臨時把證書新增到了受信任的證書

頒發機構，關閉瀏覽器後，就把它刪除了。第二種方案是允許你永久將該證書新增到受信任的證書頒發機構，這樣，即使你關閉瀏覽器，再次開啟後

該證書還有效。一般來說，我們會先嚐試第一種方案，檢驗一下URL是否可以正常訪問，如果還是無法訪問，那就要看一下伺服器的web伺服器軟體

是否設定有問題。

下面我們說一下其中的兩個檢查：

（1）證書是否是客戶端信任的CA簽發

    檢查證書的簽發機構是否是自己信任的CA，在客戶端有一個信任CA機構列表，如果不是，告警如圖2所示，這是FireFox的警告，在警告

的技術細節中提示了原因：該證書因為其自簽名而不被信任，如果想繼續訪問，那就選擇”新增例外..."，點選新增例外，會出現圖3，可以看

到一個選項“永久儲存此例外”，如果不選，就是上面說到的瀏覽器提供的第一種方案，如果選中，那就是第二種方案。

（2）證書中的Common Name與HTTP Request Header中的host（不包括埠）是否相同

     如果不同，警告如圖4所示，這是Chrome的警告。比如，我的證書的Common Name是主機的區域網IP=192.168.1.100，而我使用伺服器的域名

www.xiaobai.net進行的訪問，這時就會提示提示“您嘗試訪問的是 www.xiaobai.net，但實際上訪問的卻是標識為 192.168.1.100 的服務”。

（注：如果區域網內的主機通過192.168.1.100訪問伺服器，它會出現（1）中的警告，該證書不是受信任的證書頒發機構頒發的。）

      前面提到Chrome對於不信任的證書會有告警，但也提供了兩種方案使用他們：第一種方案是選擇”繼續www.xiaobai.net(不安全)"，它是臨時性

                                                                              圖4

五、找一家CA機構

     要獲取受瀏覽器信任的證書，則需要到證書提供商處申請。證書授證中心，又叫做CA機構，為每個使用公開金鑰的使用者發放一個數字證書。瀏覽器在預設情況下內建了一些CA機構的證書，

使得這些機構頒發的證書受到信任。VeriSign即 是一個著名的國外CA機構，工行、建行、招行、支付寶、財付通等網站均使用VeriSign的證書，而網易郵箱等非金融網站採用的是中國互

聯網資訊中心CNNIC頒發的SSL證書，不過知乎上有人說CNNIC的證書不可信，呵呵，我同意。一個證書的價格從一百到數千，以VeriSign的證書為例，價格在每年8000元人民幣左右。

     也有免費的證書可以申請，StartSSL就是，它的根證書很久之前就被一些具有開源背景的瀏覽器支援（Firefox瀏覽器、谷歌Chrome瀏覽器、蘋果Safari瀏覽器等）。後來StartSSL竟然

搞定了微軟：在升級補丁中，微軟更新了通過Windows根證書認證（Windows Root Certificate Program）的廠商清單，並首次將StartCom公司列入了該認證清單。現在，在Windows 7

或安裝了升級補丁的Windows Vista或Windows XP作業系統中，系統會完全信任由StartCom這類免費數字認證機構認證的數字證書，從而使StartSSL也得到了IE瀏覽器的支援。

（來源及申請步驟）。在StartSSL提供了免費和收費兩種證書，見https://www.startssl.com/?app=37，其中Class1就免費的，它只驗證域名所有者，其它的都是收費的。這裡我們只說一

下這種免費的證書的申請，在Class1中需要驗證你是域名的所有者："Domain Name Validation"，在你輸入域名後，它會彈出一個郵箱列表，如下，前三個郵箱是[email protected]你的域名，

[email protected]你的域名，[email protected]你的域名，還有一個是你註冊域名時提供的郵箱，選擇一個，點選“Continue”，它會給你郵箱把一個驗證碼

六、只針對註冊、登陸進行https加密處理

既然HTTPS能保證安全，為什麼全世界大部分網站都仍舊在使用HTTP呢？使用HTTPS協議，對伺服器來說是很大的負載開銷。從效能上考慮，我 們無法做到對於每個使用者的每個訪問請求都進行安全加密（當然，Google這種大神除外）。作為一個普通網站，我們所追求的只是在進行交易、密碼登陸等操 作時的安全。通過配置Nginx伺服器，可以使用rewrite來做到這一點。

在https server下加入如下配置：

if ($uri !~* "/logging.php$")
{
    rewrite ^/(.*)$ http://$host/$1 redirect;
}

在http server下加入如下配置：

if ($uri ~* "/logging.php$")
{
    rewrite ^/(.*)$ https://$host/$1 redirect;
}

這樣一來，使用者會且只會在訪問logging.php的情況下，才會通過https訪問。

更新：有一些開發框架會根據 $_SERVER['HTTPS'] 這個 PHP 變數是否為 on 來判斷當前的訪問請求是否是使用 https。為此我們需要在 Nginx 配置檔案中新增一句來設定這個變數。遇到 https 連結重定向後會自動跳到 http 問題的同學可以參考一下。

server {
    ...
    listen 443;
    location \.php$ {
        ...
        include fastcgi_params;
        fastcgi_param HTTPS on; # 多加這一句
    }
}
 
server {
    ...
    listen 80;
    location \.php$ {
        ...
        include fastcgi_params;
    }
}

參考連結：