多種不同的 MySQL 的 SSL 配置_Mysql

在這篇部落格的文章裡，我將會描述不同的使用MySQL資料庫的SSL配置方法。

SSL給了你什麼?

你可以通過互連網使用 MySQL 複製特性（replication） 或者通過互連網串連到MySQL。

還有可能是你通過企業網去串連，這樣會有很多人訪問。如果你使用一個內建裝置（BYOD）網路，這就更是一個問題了。

SSL在這裡通過加密網路防止有針對性的監聽。在與正確的伺服器進行互動時，可以有效應對中間人攻擊（man-in-the-middle attacks）。

你還可以使用SSL用戶端認證，讓它同密碼一起作為身份識別的二要素。

SSL不是唯一的選擇， 你可以使用SSH和許多MySQL GUI用戶端，類似MySQL Workbench提供的那個產品。 但是SSH的python指令碼，或者mysqldump，不是那麼易用。

需要注意的事情：

使用SSL在絕大多數情況下要比不使用SSL要好，所以沒有太多可能出現問題的地方。

但是以下幾點需要注意：

對安全性的錯誤估計

你認為你在SSL的保護之下，但是你可能忘記設定一些選項從而導致程式可以接受非SSL的串連，所以要確保設定必須使用SSL作為串連方式。可以使用Wireshark或者其它類似的工具來檢測你的流量是否都真的被加密處理。

沒有及時更新認證

你應該通過一些方法在認證即將到期的時候通知自己。可以是nagios檢查，可以是日曆裡面的小貼士，可以來自於認證簽發機構的email。如果認證到期，將會導致你的用戶端無法正常獲得響應。

效能

如果效能很重要，就應該做基準測試，來看看沒有SSL的情況下有什麼影響。在 OpenSSL 和 YaSSL 下嘗試不同的密碼，並看哪個的執行效果最佳。

使用流量監測的工具

如果你在使用像 VividCortex，pt-query-digest 基於 pcap 的工具，那麼你應該確保在部署完SSL後，這些工具還能用，可以提供密鑰來實現。然後使用一個非 Diffie-Hellman (DH)的密碼，或者使用其他的源，如 performance_schema、slow query log，這還要看你的應用程式支援哪種，也可能會包含一些負載平衡的設定。

MySQL 中的 SSL 和瀏覽器中的 SSL 有什麼不同

瀏覽器預設有一個 CA 的信任清單，但 MySQL 預設是沒有的。這就是他們最大的不同。MySQL 和OpenVPN 使用SSL非常相似。

MySQL server 和 Web server 都開啟了 SSL，同時也都需要有用戶端認證，這是他們相同的地方。

有一些細微的協議支援差別，比如：MySQL 只支援 TLS v1.0，預設不支援主機名稱驗證，所以你的認證可能是給db1.example.com的，也可能是給db2.example的，瀏覽器則可能會用OCSP、CRL's 或 CRLsets 來驗證認證是否有效。 MySQL 5.6以後就只支援CRL驗證。

配置 1: Server/Client 的內部 CA

最基本的安裝和我建立mysslgen的位置。

首先在伺服器上建立一個PKCS#1格式的密鑰，若PKCS#8不行。然後建立一個可以用CA部署的CSR(Certificate Signing Request認證簽章要求) 。最後結果是一個Certificates Service器和一個伺服器的密鑰。筆者習慣用PEM格式的認證

伺服器配置：

SSL認證伺服器和密鑰(ssl-certandssl-key)

SSL CA 憑證 (ssl-ca)

用戶端配置:

SSL CA 憑證(ssl-ca)

要求賬戶用SSL驗證，那你的GRANT語句應該用REQUIRE SSL選項。

配置 2: Server/Client 的內部 CA 和 用戶端認證

首先得在伺服器上開啟SSL，然後給用戶端建立認證。

然後在用戶端指定用戶端認證和密鑰 ssl-cert和ssl-key.

現在必須要用 REQUIRE X509來要求一個有效認證。如果這個CA不只用在MySQL server上，那就不起作用了，因為其他人也有可能拿到有效認證，

可以用 REQUIRE SUBJECT '/CN=myclient.example.com'來限制認證的使用。

在此設定認證是你的CA給頒發的，你頒發的認證你就能有很多可控的，結果就是你頒發的認證都是被信任的。

配置 3: Server/Client 與公用 CA

方案 3與方案 2相似。但公用的CA會指定多個的認證，同樣也會弔銷這些認證。

你應該瞭解 --ssl-verify-server-cert ，以確保伺服器有一個帶主機名稱的認證。否則，有人可能會用一個不帶主機名稱的有效認證來發起中間人攻擊（Man-in-the-MiddleAttack，簡稱“MITM攻擊”）。

也應該使用 REQUIRE X509 欄位，要求每個使用者 SUBJECT 、ISSUER（可選）欄位。

配置 4: Server/Client 和多個公用 CA's

這個方案用起來顯得輕而易舉。

可以使用認證包 （一個檔案多個認證），並用 ssl ca 命令指定此檔案。

在Ubuntu系統上，這個認證由/etc/ssl/certs/ca-certificates.crt 下的 ca-certificates 包提供

其他選項，用“指定assl-capath”來代替“使用ssl-ca”，這樣就可以設定到/etc/ssl/certs裡。如果想用CA的預設目錄，那就得運行OpenSSL 中的c_rehash 程式來產生正確的符號串連（只在OpenSSL下可用）。

配置 5: Replication（複製）

設定 CHANGE MASTER TO 命令中MASTER_SSL_* 就可實現。

如果開啟了主機名稱驗證，就確保用了 MASTER_SSL_VERIFY_SERVER_CERT。

只有這樣才能真正確保 replication 使用者的SSL串連是要求的SSL串連。如果SSL允許了，SHOW SLAVE STATUS就會顯示輸出,而不是不可用。

每台伺服器一個CA還是集中式CA?

可以每伺服器用一個CA然後指定一個用戶端認證，但是每個伺服器的用戶端都需要不同的認證來串連，也就是說你會發放很多CA認證。

所以你可能就會想要使用一個CA，而不是每個伺服器一個CA。

出錯了怎麼辦？

如果其中一個私人密鑰（用戶端，伺服器或CA）損壞，有以下幾種辦法處理：

什麼也不做，只要等到認證到期。這隻適用於短暫的認證（如認證有效期間是7天）。這樣做容易讓你受到攻擊，你也可能會有其他緩解風險的方法。問題是，每7天就得重啟MySQL，而且還需要一些自動分配認證的機制。

重新建立所有認證和密鑰(包括 CA)。這隻適用於CA、伺服器和使用者數量較少的情況。

用CRL（Certificate Revocation list憑證撤銷清單）。 這樣做只在你的認證有正確序號的情況下管用。此外，你要是有多個CA的話，就必須每個CA都捆綁CRL，並在c_rehash建立的符號串連的目錄中指定ssl-crl，指定ssl-crl路徑(僅OpenSSL)。如果使用CRL，那MySQL 的版本要是5.6或更高，然後更新CRL，也更新所有用戶端。

注意: 如果密鑰泄露了，就必須重新建立私人密鑰，僅用以前的CSR（認證簽章要求）是不夠的。

用戶端配置注意事項

ssl-ca 參數可在my.cnf的[client]部分設定，但這樣設定mysql binlog就不管用了，所以在用戶端用loose-ssl-ca 代替。ssl-key 和 ssl-cert 參數應該是在~/.my.cnf檔案的[client]部分，這些檔案都應該適當的保護起來。

目前以my_config_editor建立的'login-path'無法添加到SSL設定。

密碼注意事項

用 SSL 加密，可以設定一定的密碼，用 YaSSL 就很有限。當使用 OpenSSL 時，就可以使用一個密碼套件，這套件是一組特定的密碼集、一些過濾器和一個規則。

YaSSL, OpenSSL 的狀態變數注意事項

如果很難判斷你的MySQL用的是 OpenSSL 還是 YaSSL， 有些方法可以幫你，如使用命令ldd /path/to/mysqld。預設情況下 MySQL Community Edition 用的是 YaSSL ， MySQL Enterprise Edition 用的是 OpenSSL。

根據SSL執行情況，某些狀態變數可能更新的不正確。

為確保不受任何SSL漏洞影響，你最好參照 Oracle 關鍵補丁更新，保持你的 MySQL 和 OpenSSL及時更新。

運行 CA的注意事項

其實並沒有看起來那麼容易，往往開始很簡單，往後很無奈。要十分肯定的知道怎麼發布CRL，X509 擴充是什麼，你都必須用什麼。

有個網站告訴你如何配置你自己的CA：如何做一個自有的憑證授權單位（CA） - jamielinux

也有許多公用CA會給你私人的 CA 提供主機。

SSL/TLS書籍推薦

筆者推薦一本關於SSL的書：Bulletproof SSL and TLS 《SSL和TLS的防彈衣》

還有一本關於密碼學曆史的書，非常有趣：The Code Book

譯者高中時候讀過這本書的中文版《密碼故事》，確實不錯。