SSL/TLS 相關文章 – 鸚鵡 Oh My God！

設定 BIND 的 DDNS (Dynamic DNS) 環境

本篇文章僅限 BIND 的 DDNS (Dynamic DNS) 設定方式
不另說明 DNS 及 BIND 的架構和觀念

範例
Domain: example.com
master (Primary) server: dns.example.com (192.168.1.1)
slave (Secondary) server: ns1.example.com (192.168.1.2)

先用 dnssec-keygen 產生需要的 TSIG key，存放在 /var/named/keys

mkdir -p /var/named/keys
chmod 0760 /var/named/keys
chown root.named /var/named/keys
cd /var/named/keys

// dnssec-keygen -a (演算法) -b (金鑰大小) -n (金鑰類型) Name
dnssec-keygen -a hmac-sha512 -b 128 -n HOST ddns
Kddns.+165+12457

// 會產生兩個 Kddns 開頭的檔案
// 格式說明
// K(Name).+(演算法)+(keyId).key
// K(Name).+(演算法)+(keyId).private
ll Kddns*
Kddns.+165+12457.key
Kddns.+165+12457.private



cat Kddns.+165+12457.key
ddns. IN KEY 512 3 165 waAzR8JieB2vcRX42R9dEg==

mkdir -p /var/named/keys

chmod 0760 /var/named/keys

chown root.named /var/named/keys

cd /var/named/keys

// dnssec-keygen -a (演算法) -b (金鑰大小) -n (金鑰類型) Name

dnssec-keygen -a hmac-sha512 -b 128 -n HOST ddns

Kddns.+165+12457

// 會產生兩個 Kddns 開頭的檔案

// 格式說明

// K(Name).+(演算法)+(keyId).key

// K(Name).+(演算法)+(keyId).private

ll Kddns*

Kddns.+165+12457.key

Kddns.+165+12457.private

cat Kddns.+165+12457.key

ddns. IN KEY 512 3 165 waAzR8JieB2vcRX42R9dEg==

其中 waAzR8JieB2vcRX42R9dEg== 是我們需要的資訊

閱讀全文〈設定 BIND 的 DDNS (Dynamic DNS) 環境〉

設定 DNS CAA 紀錄，保護自己的 SSL/TLS 憑證

目前全球簽發 SSL/TLS 憑證的機構已超過百個
要避免這些機構在某些情況下錯誤簽發憑證 (WoSign曾發生過)
就需要在簽發憑證前做一些檢查動作

在 RFC 6844 中定義了 DNS CAA Record
透過 DNS 的 CAA 紀錄，申明網域授權哪些機構可以簽發該網域的憑證
如果沒有設定 CAA 紀錄，則代表任何機構都可以簽發該網域的憑證
2013年1月 CA可以決定是否檢查該記錄，非強制性
2017年3月 CA/Browser 論壇決議 2017年9月起強制所有憑證發行機構在簽發憑證前必須檢查 DNS CAA 紀錄

閱讀全文〈設定 DNS CAA 紀錄，保護自己的 SSL/TLS 憑證〉

網址由 HTTP 轉換到 HTTPS 過程中保留 Facebook 的按讚數

在 Google 大力推行以及 Let’s Encrypt 的支持下
相信會有越來越多網站選擇增加 HTTPS 的支援，甚或直接只使用 HTTPS 協定連線

在網站導入 SSL/TLS 的過程中，網址也必然會有所變動
可能增加了 HTTPS 連入的管道，也可能從 HTTP 轉變為 HTTPS 單一選擇

在社群導入的情況下，量化的數字是最容易被在意的
在網址轉換的過程中，同一個網頁會變成有新舊兩個網址
而 Facebook 按讚數的計算基礎是網址為基礎，造成即使兩個網址指向同一個頁面卻還是被 Facebook 分別以新舊網址計算按讚數

鸚鵡自己也在移轉的過程中遇到這個問題，在處理的過程中慢慢嘗試及摸索
倒也是搞懂了 Facebook Like Button 處理和判斷的方式
算是有個解決方案，其實不難只要抓到幾個原則

閱讀全文〈網址由 HTTP 轉換到 HTTPS 過程中保留 Facebook 的按讚數〉

讓 Discuz X2.5 在 http 協定下透過 https 協定進行登入動作

前幾天才嘗試修改讓 Discuz! X2.5 可以支援 https 協定下運作
昨天登入 Google 的 Search Console 收到這樣的提示

自 2017 年 1 月起，Chrome (56 以上版本) 會將收集密碼或信用卡詳細資料的網頁標示為「不安全」(透過 HTTPS 提供的網頁除外)。

下列網址包含密碼或信用卡詳細資料的輸入欄位，將會觸發這項新的Chrome 警告。請查看這些示例，掌握這類警告出現的位置，方便您採取有助於保護使用者資料的行動。請注意，這份清單中僅列出部分示例。

目前鸚鵡裝的是 Chrome 55 版，在 http 協定連線時，網址列前面是一個圓形驚嘆號
但不會有其他提示，不知道 Chrome 56 會不會跳出提示
為了避免被跳出不安全的提示，所以決定再來嘗試改一下程式碼
讓論壇即使是 http 協定連入，登入表單也必定傳送到 https 協定

閱讀全文〈讓 Discuz X2.5 在 http 協定下透過 https 協定進行登入動作〉

讓 Discuz X2.5 支援 https 協定

Discuz! 在 X3 之後才內建支援 https 協定
因為不想大幅度升級，所以決定以修改的方式讓 X2.5 版能支援 https 協定

花了不少時間追原始碼，初步修改後大致上可以同時使用 http 和 https 兩種協定進入論壇
使用 https 進入論壇時，論壇畫面、主題列表都沒問題
但是點入文章後，很容易就被瀏覽器提醒連線可能有安全漏洞

原因是論壇本就開放式架構，任何人張貼連外的連結或圖片或其他任何資源
只要連外不是使用 https 連結的，都會被視為不安全的連線
所以多數的論壇都維持使用 http 協定，頂多就是登入時使用 https 而已

既然已經修改了，就紀錄一下修改的方法

閱讀全文〈讓 Discuz X2.5 支援 https 協定〉

將 Let’s Encrypt 申請到的 SSL 憑證用在 Postfix 上，提供 SMTP with TLS 和 smtps 服務

因為已經取得免費的 SSL 憑證：Let’s Encrypt！
所以就想把這個 SSL憑證也用在 Postfix 上，讓 smtp 可以使用 TLS 加密
也可以開啟 smtps 服務 (Port 465)

環境說明

CentOS 7 x64
Postfix 2.10.1

閱讀全文〈將 Let’s Encrypt 申請到的 SSL 憑證用在 Postfix 上，提供 SMTP with TLS 和 smtps 服務〉

將 Let’s Encrypt 申請到的 SSL 憑證用在 Dovecot 上，提供 pop3s 和 imaps 服務

因為已經取得免費的 SSL 憑證：Let’s Encrypt！
所以就想把這個 SSL憑證也用在 Dovecot 上，讓 pop3 和 imap 都可以使用 SSL/TLS 加密

環境說明

CentOS 7 x64
Dovecot 2.2.10

Dovecot 原始設定

disable_plaintext_auth = no
auth_mechanisms = plain login

閱讀全文〈將 Let’s Encrypt 申請到的 SSL 憑證用在 Dovecot 上，提供 pop3s 和 imaps 服務〉