Home » Computer » Archive by category "Security" (Page 2)

Symantec 系列的 SSL Certificate 陸續開始失效...

先前就有提到 ChromeFirefox 因為 Symantec 的信任問題太大,都有打算終止信任 Symantec 的憑證了,而其他瀏覽器也都有陸陸續續公佈了類似的計畫,大家的時間表都抓差得不多...

最近接近當時各家瀏覽器規劃的終止信任日,而在使用開發版本的 Chrome 與 Firefox 開始連不上一些網站了。我自己是走 beta channel 所以還沒中,不過好像也快了...

我拿了「Umbrella Popularity List」這邊提供的前一百萬網站測,以 .tw 結尾的網站看起來就只剩下兩個還沒換了:

在蘋果的網站上有清單可以翻:「Information for website operators about distrusting Symantec certificate authorities」。

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

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

SSH 的 SSHFP record

很久前看過 SSHFPT record,當時支援度不高就忘記了... 剛剛在 Cloudflare 的這篇「Additional Record Types Available with Cloudflare DNS」看到發現 OpenSSH 很久前就有支援了...

用法是 VerifyHostKeyDNS 這個 option,像是 ssh -o "VerifyHostKeyDNS=yes" -o "StrictHostKeyChecking=yes" hostname 這樣的指令,對於 ~/.ssh/known_hosts 裡沒有的機器,在第一次連線的時候會去查 DNS record,如果沒有查到的話就會中斷。

產生 SSHFP record 的方式則是可以參考「How do I generate SSHFP records?」這篇,也就是直接用 sshkey-gen -r [hostname],程式就會去讀 /etc/ssh/ 下的資料產生了。

WireGuard 被收進 Linux Kernel 了...

Twitter 上看到 WireGuard 被收進 Linux Kernel 了,等 review 完後就就會正式納入了... 而且 Linus 給的評價還蠻高的:

找了一下起源是「[PATCH v1 3/3] net: WireGuard secure network tunnel」這邊,而 Twitter 上面引用的是「Re: [GIT] Networking」這篇...

找子網域的 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 則可以看到來源。

保護 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,把暴露的資訊再降低...

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

用 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 架構的認證再來調整...

GCP 的 f1-micro 的使用心得...

這幾天在弄備援跳板機,不想弄在日本 (latency),所以就想到 Google Cloud Platform (GCP) 在台灣有機房,而 Compute Enginef1-micro,類似 AWSEC2 提供的 t2.nano 的機器。而這兩天玩了玩,大概有些事情值得記錄起來。

CPU 相關的部份:

  • EC2 的 t2 系列可以透過 API 或是在 web console 看到 CPU credit 剩下多少,GCE 沒找到在哪邊可以看。
  • EC2 的 t2 系列在 CPU credit 用完後是變慢運行,除非你打開 T2 Unlimited 同意 AWS 多收錢。而 GCE 的則是沒得選,相當於一定要開 T2 Unlimited。
  • GCE 的 f1-micro 是 0.2 vCPU,但我在上面跑 Ubuntu 18.04,平常沒事就已經是 15% 左右。這數字比預期的高不少,還在找是什麼原因...

網路相關的部份:

  • 因為要用台灣的機房,網路的部份只有 Premium 等級可以選 (Standard 等級目前只在美國有),也就是會先走 Google 佈建的網路再出去,所以流出的費用會隨著 destination 地區而有差異 (i.e. 封包送到美國與送到中國是不同計價)。
  • 但 Premium 等級實測品質真的很不一樣,到香港居然在 15ms 以下,以前在固網機房內沒看過這個數字...

其他的部份:

  • 硬碟空間方面,Standard provisioned space 比 EBSgp2 便宜不少,而且還包括了 i/o 費用 (AWS 會另外收費)
  • 連續使用就會有 discount 了,也可以 commit 買一年或是三年取得更深的 discount。而 AWS 則是得買 Reserved Instance 拿到 discount。

來看看一個月會有多少帳單產生吧...

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)

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

Archives