Tag: gnutls

Squid + GnuTLS 不支援 Intermediate Certificate 的問題

先前在「架設 Proxy over TLS」這邊提到了我用 Squid 架 Proxy over TLS 的服務起來用，本來在家裡跑得好好的，但到了公司發現卻不能用，追蹤後發現是目前 Ubuntu 裡面包的 Squid + GnuTLS 沒有辦法支援 intermediate certificate 的問題，而且有人問過了：「[squid-users] HTTPS_PORT AND SSL CERT」。

這邊先講測試的方法，然後後面再講解法。

測試的方式可以用 openssl s_client -connect hostname:port 測，正常的情況會可以看到兩層。

在這邊的例子裡，R3 簽了 home.gslin.org，DST Root CA X3 簽了 R3，而 DST Root CA X3 則在 root certificate 名單中：

$ openssl s_client -connect home.gslin.org:443
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = home.gslin.org
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:CN = home.gslin.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

如果沒有送出 Intermediate Certificate 的話就會導致信任鏈無法建立，像是我故意設計的 nointermediate.gslin.com 這樣，R3 簽了 nointermediate.gslin.com，但 R3 並沒有在 root certificate 的名單中：

$ openssl s_client -connect nointermediate.gslin.com:443
CONNECTED(00000003)
depth=0 CN = nointermediate.gslin.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = nointermediate.gslin.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = nointermediate.gslin.com
verify return:1
---
Certificate chain
 0 s:CN = nointermediate.gslin.com
   i:C = US, O = Let's Encrypt, CN = R3                                
---

而想到的解法就是重新包一份 Squid 出來用，把本來的 --with-gnutls 改成 --with-openssl。

這邊會先裝 Build-Depends 裡面指定的東西，然後加裝 libssl-dev，接著換掉 --with-gnutls 後編譯，最後產生 .deb：

sudo apt install -y ed libltdl-dev pkg-config build-essential cdbs debhelper dpkg-dev lsb-release dh-apparmor libcppunit-dev libcap2-dev libdb-dev libecap3-dev libexpat1-dev libgnutls28-dev libkrb5-dev comerr-dev libldap2-dev libnetfilter-conntrack-dev libpam0g-dev libsasl2-dev libxml2-dev nettle-dev libssl-dev
apt-get source squid
cd squid/squid-4.10
sed -i -e 's/--with-gnutls/--with-openssl/' debian/rules
cd ..
dpkg-buildpackage -rfakeroot -uc -b

編好的 .deb 就可以拿到其他機器上裝了，然後就可以吐出 intermediate certificate 了...

對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)

在「Disasters」這邊列了不少對稱式加密系統 (secret-key cryptography) 爆炸的歷史，其中提到了很多 Encrypt 與 MAC 結合時的問題 (Authenticated encryption)。另外 Colin Percival 在 2009 年的時候有寫了一篇為什麼要用 Encrypt-then-MAC 的文章：「Encrypt-then-MAC」，當時 Colin Percival 寫的時候大家還是不能理解，但現在回頭看上面的爆炸歷史應該就清楚很多了 XDDD

SSH 協定是使用 Encrypt-and-MAC (傳輸「密文」與「明文的 MAC 值」)。在 2008 年時 SSH 使用 CBC 模式時會有安全問題：對 128bits CBC mode system (像是 aes128-cbc)，任意位置的 32bits 有 2-18 的機會可以解出原文。(CVE-2008-5161，論文是「Plaintext Recovery Attacks Against SSH」)

TLS 1.0 (SSLv3) 使用 MAC-then-Encrypt (傳輸「明文與明文的 MAC 值」加密後的結果)。1999 年就知道這個方法不可靠，不過到了 2011 年時才被拿出來示範，也就是 BEAST attack。(CVE-2011-3389，在 ekoparty Security Conference 上的「表演」：「BEAST: Surprising crypto attack against HTTPS」，連結1、連結2)

OpenSSL 與 GnuTLS 所實作的 DTLS 在 2011 年也被炸到，其中 OpenSSL 是 100% plaintext recovery，GnuTLS 是 4%。(CVE-2012-0390，論文是「Plaintext-Recovery Attacks Against Datagram TLS」)

而 Encrypt-then-MAC (傳輸「密文」與「密文的 MAC」) 是三者裡面最不容易出包的作法，而且被證明 Provable security：Encrypt 與 MAC 所用的 crypto system 的安全強度不會因為 Encrypt-then-MAC 而減少。而這也是 IPSec 的作法。

附帶一提，其中 Provable security 這個詞，並非表示「可被證明是安全的」，在「In defense of Provable Security」這篇文章裡有比較完整的說明。通常是指安全強度不會因為這個系統而降低：以 Encrypt-then-MAC 的例子來說，如果 Encrypt 的部份用 DES，或是 MAC 用 CRC32，那麼 Encrypt-then-MAC 並不會提供更強的安全性...

總而言之，MAC-then-Encrypt 與 Encrypt-and-MAC 的方式要小心才能避免各種攻擊 (像是不能用 CBC mode)，而 Encrypt-then-MAC 可以讓設計協定的人放鬆到「只要 Encrypt 與 MAC 都夠強」系統就沒問題。在 Authenticated encryption 裡提到的 ISO/IEC 19772:2009 支援六個模式，有些有專利問題，有些演算法看起來就很複雜 (於是就容易出包)，其中 Encrypt-then-MAC 看起來是個還不錯的方案...