Home » Posts tagged "tls" (Page 2)

RFC 8446:TLS 1.3

看到 RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3) 正式推出了,也就是 TLS 1.3 正式成為 IETF 的標準 (Standards Track)。

Cloudflare 寫了一篇文章「A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)」描述了 TLS 1.3 的特點,有興趣的人可以看一看,尤其是 1-RTT 的部份對效能幫助很大 (0-RTT 因為 replay attack 問題,我應該暫時都不會考慮,要等到有一個合理的防禦模型出來)。

另外一個是 OpenSSL 目前最新版是 1.1.0h,當初就決定要等 TLS 1.3 正式成為標準才會出 1.1.1 (參考「OpenSSL 1.1.1 將支援 TLS 1.3」,這也熬了一年啊... 支援後會就有很多軟體可以直接套用了,可以來期待了。

Let's Encrypt 被所有主流瀏覽器直接支援了...

Let's Encrypt 宣佈他們的憑證被所有主流瀏覽器直接支援了,也就是都在各平台的 trusted store 內了:「Let's Encrypt Root Trusted By All Major Root Programs」,看起來這次加入的是 Microsoft 的產品:

As of the end of July 2018, the Let’s Encrypt root, ISRG Root X1, is directly trusted by Microsoft products. Our root is now trusted by all major root programs, including Microsoft, Google, Apple, Mozilla, Oracle, and Blackberry.

先前是靠 IdenTrust 的 cross signing 讓各瀏覽器信任,在「Chain of Trust」這邊有圖說明:

另外查了一下 cross signing 的資訊,以 Let's Encrypt Authority X3 這張的 cross signing 可以看到 cross sign 簽了五年,到 2021 年:(憑證可以從 letsencryptauthorityx3.pem.txt 這邊取得,用 openssl x509 -in letsencryptauthorityx3.pem.txt -text 看到)

    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
        Validity
            Not Before: Oct  6 15:43:55 2016 GMT
            Not After : Oct  6 15:43:55 2021 GMT
        Subject: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

這樣約滿不知道會不會續簽...

找子網域的 subfinder

在「subfinder – 找子網域的工具」這邊看到的,專案是用 Golang 寫的,需要 Golang 1.10+ 才能裝... 這類工具在 PT 找入口時還蠻好用的。

裝完後馬上跑個熱門的 ./subfinder -d teamkp.tw 可以看到不多:

Total 4 Unique subdomains found for teamkp.tw

.teamkp.tw
donate.teamkp.tw
www.donate.teamkp.tw
www.teamkp.tw

加上 -v 則可以看到來源。

Google Chrome 68,第一個將所有 HTTP 站台都標成 Insecure 的版本

Google 在 stable channel 發布了 Google Chrome 68,這是 Chrome 第一個將所有 HTTP 站台都標成 insecure 的版本:「Stable Channel Update for Desktop」。取自二月時的圖:

文章內也說明了這個改變:

In Chrome 68, Chrome will show the “Not secure” warning on all HTTP pages. We announced this in a blog post published on February 8th on Google’s Chromium and Online Security blogs.

雖然之前 Google 一直在推動,但應該還是很多單位沒在管...

nginx 1.15.2 開始支援單一 Port 多服務...

nginx 的新功能,單一 port 支援多服務:「Running SSL and Non-SSL Protocols over the Same Port with NGINX 1.15.2」,最常見的還是混搭 SSH 了:

One key feature in this release is the new $ssl_preread_protocol variable, which allows you to distinguish between SSL/TLS and other protocols when forwarding traffic using a TCP (stream) proxy. This is useful if you want to avoid firewall restrictions by (for example) running SSL/TLS and SSH services on the same port.

雖然 L7 firewall 還是可以看出來 (並且擋下),但簡易的 firewall 就可以用這個方式穿過去了...

保護 TLS 的 Hostname

看到「Encrypted Server Name Indication for TLS 1.3」這個,由 FastlyCloudflareApple 的人聯手推出的 draft,想要保護 TLS 連線一開始明文傳輸的 hostname 部分。看起來是透過 DNS 發佈 public key,然後使用者用這把 public key 保護 hostname 的部分...

而 DNS 的部分可以透過 DNS over TLS 或是 DNS over HTTPS 來保護,這樣讓 ISP 沒有任何資訊可以看到 hostname,把暴露的資訊再降低...

來繼續關注這個技術...

DNS over TLS 的 Privacy 改善

在上一篇提到 DNS over TLS 的「用 Stubby 在 Ubuntu 上跑 DNS over TLS」這篇,裡面 Gholk 留言提到:

可是 isp 還是可以從你接下來要去的 ip 知道你查了什麼吧?除非是 http proxy 多個域名一個 ip.

在「Does SNI represent a privacy concern for my website visitors?」這邊提到了 SNI 對隱私的問題,但他的想法剛好跟這個主題有關。

現代的瀏覽器架構使得使用者要在網路上保護自己很難 (這邊指的是隱私),但我們還是會利用各種方式加高 ISP 的難度,而這邊通常指的是成本:在 168.95.1.1168.95.192.1 上面記錄並且分析的成本,會比在所有的出口或是骨幹上面截聽封包的成本來的低很多,所以會走 DNS over TLS。

用 Stubby 在 Ubuntu 上跑 DNS over TLS

透過 DNS over TLS 會損失一些效能 (我用 VDSL 的光世代測試,大約是從 10ms 變成 40ms),但可以讓 ISP 看不到你查詢什麼,對於隱私有很大的幫助... 而先前是一直在看 Ubuntu 上的 Unbound 什麼時候會有 1.8.0+ 的版本可以用 (支援 DNS-over-TLS),但一直沒看到,結果在「How to Protect Your DNS Privacy on Ubuntu 18.04 with DNS over TLS」這邊看到 Stubby 這個軟體。

Stubby 在 Ubuntu 18.04 上可以直接裝,但在 Ubuntu 16.04 上需要透過 PPA 裝,我是透過「DNS Utils : James Newell」這個安裝的,裝好後 /etc/stubby/stubby.yml 檔裡 upstream_recursive_servers 的設定改成:

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"

就可以走 port 853 的 DNS over TLS 了,而 Stubby 預設會聽 127.0.0.1::1 的 port 53,所以把 /etc/resolv.conf 或是 NetworkManager 的設定改成 127.0.0.1 就可以了。

目前這樣設看起來沒辦法擋 MITM attack (偽造 SSL certificate),Stubby 看起來只能用 tls_pubkey_pinset 鎖住,但實在不愛這個方法 (因為 Cloudflare 有可能會換成其他的 SSL certificate),之後看看有沒有可以吃 Root CA 架構的認證再來調整...

Cloudflare 提供的 DNS Resolver 服務拓展到 Tor 上

Cloudflare 宣佈 DNS Resolver 提供 Tor 的版本,讓使用者可以在不暴露自己的 IP address 的情況下,使用 Cloudflare 提供的 DNS Resolver 服務:「Introducing DNS Resolver for Tor」。

不過沒看懂,如果使用者想要透過 Tor 保護自己的話,本來就可以透過 Tor 存取 1.1.1.11.0.0.1 甚至是其他家有提供 DNS-over-TLS 或是 DNS-over-HTTPS 的服務了?(像是 Google8.8.8.8)

好像找不到什麼使用的理由...

nginx 推出了 1.14.0 的 PPA

nginxPPA (「NGINX Stable : “Nginx” team」這個) 推出了 1.14.0 的版本。

這個版本使用了 OpenSSL 1.1.0,對 cipher 這塊最大的差異主要是包括了 CHACHA20AESCCM 演算法。後者的 CCM 指的是 CCM mode,這是當時 OCB mode 因為專利問題而發展出來的演算法,就目前的效能測試沒有 GCM 好,而且普及率也沒有 GCM 高,放進來應該是當備案 (當 GCM 有狀況時標準裡至少有方案可以選):

The catalyst for the development of CCM mode was the submission of OCB mode for inclusion in the IEEE 802.11i standard. Opposition was voiced to the inclusion of OCB mode because of a pending patent application on the algorithm. Inclusion of a patented algorithm meant significant licensing complications for implementors of the standard.

真正的重點在於 CHACHA20 的引入,讓 OpenSSL 重新有主流 stream cipher 可以使用了... 上一個主流 stream cipher RC4 被打趴好久了。

不過 TLSv1.3 要等 OpenSSL 1.1.1 才有 (參考「Using TLS1.3 With OpenSSL」這邊的說明),目前可以在設定檔裡面設 TLSv1.3 而不會出現錯誤訊息,但暫時還不會有效果...

Archives