HashiCorp 推出 Boundary 與 Waypoint

HashiCorp 推出了兩個新的產品。

第一個是 Boundary,這個產品看起來還很早期,但看起來想要實做 BeyondCorp 的一些想法 (可以參考之前寫的「Google 推的 BeyondCorp」):「Announcing HashiCorp Boundary」,這在 Hacker News 上有討論串,而且 HashiCorp 的老大 Mitchell Hashimoto 也有出來回答一些問題:「HashiCorp Boundary (hashicorp.com)」。

這個產品讓他慢慢發展起來應該會是不錯的 open-source implementation,不過傳統的 castle 在小一點的場合也還算夠用...

另外一個是 Waypoint,看起來是個 CI/CD 類的產品:「Announcing HashiCorp Waypoint」,在 Hacker News 上也有討論串,而且同樣的 Mitchell Hashimoto 也有在裡面回覆一些東西:「Waypoint: Build, deploy, and release applications across any platform (hashicorp.com)」。

我自己看了一下設定的方式以及一些畫面,然後再回頭看 Hacker News 上的討論,以目前得到的資訊來看,這個產品似乎沒有很明顯解決到痛點,也許就是補產品線...

Google Chrome 的顯示完整 URL 的方式又改了...

剛剛更新 Google Chrome 後發現 address bar 又被動手腳了 (我是 beta channel 的版本),在網址列上的 Protocol (Scheme) 與 www subdomain 不見了,而本來裝 Suspicious Site Reporter 可以讓 URL bar 恢復的方式也失效了。

翻了一下老問題「Chrome address bar no longer shows protocol or www subdomain」,裡面有提到新的解法 (他寫的當下) 是「The current solution in Chrome 83+」這個,直接在網址列上選右鍵,可以看到 Always show full URLs 這個選項,這是整個 Google Chrome 的選項,而非單一站台選項,選下去後就生效了:

而本來的 Suspicious Site Reporter 也可以拔掉了 (沒有用處了)。

打穿蘋果的企業網路

上個禮拜丟出來很轟動的一篇「side project」,三個月不斷的打穿蘋果的企業網路:「We Hacked Apple for 3 Months: Here’s What We Found」,對應的 Hacker News 討論可以在「We Hacked Apple for 3 Months (samcurry.net)」這邊看到。

在最後面有提到這本來是打好玩的,但後來就投入愈來愈多時間進去:

This was originally meant to be a side project that we'd work on every once in a while, but with all of the extra free time with the pandemic we each ended up putting a few hundred hours into it.

這是五個人通力合作打了三個月出來的成果,依照他們的回報數字,共打出了 55 個「洞」,考慮到週休的情況,幾乎是天天打洞出來玩:

There were a total of 55 vulnerabilities discovered with 11 critical severity, 29 high severity, 13 medium severity, and 2 low severity reports. These severities were assessed by us for summarization purposes and are dependent on a mix of CVSS and our understanding of the business related impact.

文章裡沒有對每個安裝漏洞都描述,但有針對一些比較「有趣」的漏洞說明,雖然看了以後知道是怎麼一回事,但對這些手法沒這麼熟,你叫我打我還是不會打啊 XDDD 反而是當作表演藝術來看...

讓瀏覽器直接連 HTTPS 的 SVCB/HTTPS

Cloudflare 的「Speeding up HTTPS and HTTP/3 negotiation with... DNS」這篇裡面提到了一個新的標準 (目前是 draft):「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」。

從文件上可以看到這個標準是由 GoogleAkamai 的人提出來的,想要透過 DNS 的方式告訴瀏覽器這個網站可以直接用 HTTPS 連線 (以及其他資訊)。

這樣有兩個好處,第一個是安全性上的好處,HSTS 只保證了第二次以及之後的連線會強制用 HTTPS,但不能保證第一次連線時是 HTTPS。透過 DNS 查到後可以第一次就用 HTTPS 連線。

第二個是效能上的好處,降低了一個 3xx redirect 的時間,雖然 DNS 多了一些查詢,但 DNS 查詢這邊通常會比 TCP connection 建立連線來說快不少,再加上 HTTP protocol 需要先等瀏覽器端送出 HTTP header 後才有回應,這樣應該是快蠻多的。

文章裡有提到 iOS 14 好像有開始在嘗試,但我好像沒看到其他資料:

We began investigating and found these to be a part of Apple’s iOS14 beta release where they were testing out a new SVCB/HTTPS record type.

先繼續觀望看看標準怎麼發展...

OpenSSH 8.4 預設停用 ssh-rsa

前幾天 OpenSSH 8.4 釋出了:「Announce: OpenSSH 8.4 released」。

比較重要的改變是 ssh-rsa 預設變成停用,因為是使用 SHA-1 演算法的關係:

It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.

官方給了三個方案:

  • The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them.
  • The ssh-ed25519 signature algorithm. It has been supported in OpenSSH since release 6.5.
  • The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These have been supported by OpenSSH since release 5.7.

掃了一下 ~/.ssh/known_hosts,看起來目前大多都是 ssh-ed25519 了,還有少數還是 ssh-rsa

翻了一下 Ubuntu 這邊的版本,16.04 是 7.2p2,看起來目前有支援的版本都可以用這三個。

官方有提到可以在 command 上強制關閉 ssh-rsa 測試的方法:

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

現在看起來比較麻煩的是 Dropbear 的部份,我自己之前是有包 PPA 來用 (2019.78),但看起來還是不夠新支援 ssh-ed25519 (要今年六月的 2020.79 才支援),所以也許要找時間來把 PPA 更新到 2020.80...

另外一種方法是走 ecdsa-sha2-nistp{256,384,521} 這些演算法,不過從名字就可以知道裡面演算法的由來,卡個 NIST 在那邊看起來就不太舒服,但還是寫一下方法好了:

先用 dropbearkey 產生對應的 ecdsa host key:

sudo dropbearkey -t ecdsa -f /etc/dropbear/dropbear_ecdsa_host_key -s 256

再來在 /etc/default/dropbear 裡面把 DROPBEAR_EXTRA_ARGS 加上對應的 ecdsa host key 資訊,這邊直接用 -r 是因為他可以重複指定,不會影響到其他的 host key 設定:

# any additional arguments for Dropbear
DROPBEAR_EXTRA_ARGS="-r /etc/dropbear/dropbear_ecdsa_host_key"

然後重跑 dropbear 就可以了。

另外有興趣的人可以用 ssh -Q key 看 openssh client 支援的演算法。

Let's Encrypt 生了新的 Root 與 Intermediate Certificate

Let's Encrypt 弄了新的 Root Certificate 與 Intermediate Certificate:「Let's Encrypt's New Root and Intermediate Certificates」。

一方面是本來的 Intermediate Certificate 也快要要過期了,另外一方面是要利用 ECDSA 降低傳輸時的頻寬成本:

On Thursday, September 3rd, 2020, Let’s Encrypt issued six new certificates: one root, four intermediates, and one cross-sign. These new certificates are part of our larger plan to improve privacy on the web, by making ECDSA end-entity certificates widely available, and by making certificates smaller.

本來有 Let's Encrypt Authority {X1,X2,X3,X4} 四組 Intermediate Certificate,都是 RSA 2048 bits。

其中 X1 與 X2 差不多都到期了 (cross-signed 的已經過了,自家 ISRG Root X1 簽的剩不到一個月),不過這兩組已經沒在用了,這次就不管他了。

而 X3 與 X4 這兩組則是明年到期,會產生出新的 Intermediate Certificate,會叫做 R3 與 R4,跟之前一樣會被自家 ISRG Root X1 簽,以及 IdenTrust DST Root CA X3 簽:

For starters, we’ve issued two new 2048-bit RSA intermediates which we’re calling R3 and R4. These are both issued by ISRG Root X1, and have 5-year lifetimes. They will also be cross-signed by IdenTrust. They’re basically direct replacements for our current X3 and X4, which are expiring in a year. We expect to switch our primary issuance pipeline to use R3 later this year, which won’t have any real effect on issuance or renewal.

然後是本次的重頭戲,會弄出一個新的 Root Certificate,叫做 ISRG Root X2,以及兩個 Intermediate Certificate,叫做 E1 與 E2:

The other new certificates are more interesting. First up, we have the new ISRG Root X2, which has an ECDSA P-384 key instead of RSA, and is valid until 2040. Issued from that, we have two new intermediates, E1 and E2, which are both also ECDSA and are valid for 5 years.

主要的目的就是降低 TLS 連線時的 bandwidth,這次的設計預期可以降低將近 400 bytes:

While a 2048-bit RSA public key is about 256 bytes long, an ECDSA P-384 public key is only about 48 bytes. Similarly, the RSA signature will be another 256 bytes, while the ECDSA signature will only be 96 bytes. Factoring in some additional overhead, that’s a savings of nearly 400 bytes per certificate. Multiply that by how many certificates are in your chain, and how many connections you get in a day, and the bandwidth savings add up fast.

另外一個特別的修改是把名字改短 (把「Let's Encrypt Authority」拿掉),也是為了省傳輸的成本:

As an aside: since we’re concerned about certificate sizes, we’ve also taken a few other measures to save bytes in our new certificates. We’ve shortened their Subject Common Names from “Let’s Encrypt Authority X3” to just “R3”, relying on the previously-redundant Organization Name field to supply the words “Let’s Encrypt”. We’ve shortened their Authority Information Access Issuer and CRL Distribution Point URLs, and we’ve dropped their CPS and OCSP urls entirely. All of this adds up to another approximately 120 bytes of savings without making any substantive change to the useful information in the certificate.

這個部份讓我想到之前寫的「省頻寬的方法:終極版本...」這篇,裡面提到 AWS 自家的 SSL Certificate 太胖,改用 DigiCert 的反而可以省下不少錢 XDDD

另外也提到了這次 cross-sign 的部份是對 ECDSA Root Certificate 簽 (ISRG Root X2),而不是對 ECDSA Intermediate Certificate 簽 (E1 與 E2),主因是不希望多一次切換的轉移期:

In the end, we decided that providing the option of all-ECDSA chains was more important, and so opted to go with the first option, and cross-sign the ISRG Root X2 itself.

這算是蠻重要的進展,看起來各家 client 最近應該都會推出新版支援。

5 Eyes、9 Eyes 與 14 Eyes

{5,9,14} Eyes 是先前在其他地方看到的詞,後來在「Cutting Google out of your life」這邊在講 Google 的替代方案時又有提到,然後也有解釋:「Global Mass Surveillance - The Fourteen Eyes」。

這邊提到的 Eyes 起因是大多數國家對於監視自己公民都有法律限制,所以藉由與國外的情報單位「合作」,取得對自己國家公民的監視資訊 (即使各國之間有簽訂不監視其他國家公民),而這邊列出的 {5,9,14} Eyes 就是互相有簽訂合作的國家:

The UKUSA Agreement is an agreement between the United Kingdom, United States, Australia, Canada, and New Zealand to cooperatively collect, analyze, and share intelligence. Members of this group, known as the Five Eyes, focus on gathering and analyzing intelligence from different parts of the world. While Five Eyes countries have agreed to not spy on each other as adversaries, leaks by Snowden have revealed that some Five Eyes members monitor each other's citizens and share intelligence to avoid breaking domestic laws that prohibit them from spying on their own citizens. The Five Eyes alliance also cooperates with groups of third-party countries to share intelligence (forming the Nine Eyes and Fourteen Eyes); however, Five Eyes and third-party countries can and do spy on each other.

另外還有「Key Disclosure Law」這段,在講有哪些國家有法律可以強制個人交出金鑰。

回到本來提到的 degoogle 列表,裡面列出了很多替代的服務與軟體,其中服務的部份會列出所在地區是否在 {5,9,14} Eyes 的範圍內,以及發生過的爭議事件。

當作替代方案在看,至少可以把一些足跡從 Google 抽出來...

CloudFront 支援 TLS 1.3

看到 AWS 的公告,宣佈 CloudFront 支援 TLS 1.3:「Amazon CloudFront announces support for TLSv1.3 for viewer connections」。

預設會自動啟用:

TLSv1.3 is available today and enabled by default across all Amazon CloudFront security policies options. No additional changes are required to your CloudFront configuration to benefit from the security and performance improvements of TLSv1.3 for your viewer connections.

對使用者最大的差異應該還是改善 first byte 的時間 (主要是因為 handshake 時間縮短),這點 AWS 的人也有提到在內部測試時,美國區的改善情況:

In our own internal tests in the US region as an example, first byte latency for new negotiated connections saw reductions of up to 33% for TLSv1.3 compared to previous versions of TLS.

在 latency 更高的地區應該也會有大幅改善...

自己架設各種服務的 ansible playbook:Sovereign

來清個瀏覽器上的 tab,sovereign 是個 ansible playbook,幫你架設各種服務:

Sovereign is a set of Ansible playbooks that you can use to build and maintain your own personal cloud based entirely on open source software, so you’re in control.

裡面包了許多服務,但看下來比較麻煩的是郵件相關的服務,現在要自己搞一整包郵件系統一直都是痛點,這點在 Hacker News 上偶而就會看到分享...

這包 ansible playbook 裡面跟郵件相關的部份包括了 PostfixDovecot 搭出基本的 SMTP + IMAP + POP3,另外用 Solr (全文搜尋)、PostgreSQL (Virtual domain)、Rspamd (擋 spam),DKIMDMARC (郵件來源認證機制),以及 Roundcube (Webmail)。

非郵件相關的話包括了 VPN、cloud storage,以及一些管理、安全、備份有關的服務可以用,看起來的確是把常用的東西都放進去了。

不過這種東西自己架是有自己架的「樂趣」,而且對底層掌握度也比較高 (尤其是又有隱私與安全性的考量),對應的客群應該會看一看架構,然後自己動手?