幫你在本機產生 localhost 的 SSL Certificate

mkcert 這個工具可以產生出讓系統 (包括瀏覽器) 信任的 https://localhost/:「mkcert: valid HTTPS certificates for localhost」。

先建立 CA 的 root key 與 root certificate,然後把 root certificate 塞到系統與各軟體的信任清單內,再產生 localhost 的 key 與 certificate 出來給前面的 CA root key 簽名。把這些事情包裝起來就是 mkcert 了。

拿來開發軟體時比較方便一點,HSTS 的程式碼就可以全環境共用了...

Yubico 宣佈推出 Lightning 的 U2F 界面...

YubicoCES 2019 上宣佈推出兩用版的 YubiKey,同時支援 USB-CLightning 接頭:「Yubico Launches the Security Key NFC and a Private Preview of the YubiKey for Lightning at CES 2019」。

從照片可以看出來是直接做成兩側各一個頭:

目前是 Private Preview,開發者需要跟 Yubico 申請:

If you are a developer or service that would like to support strong hardware authentication on iOS, we invite you to work with us by applying to participate in the YubiKey for Lightning Program. Selected participants will have access to the private preview of YubiKey for Lightning and also the Yubico Mobile iOS SDK for Lightning.

不過看起來是硬體限制沒辦法朝 NFC 支援?另外如果蘋果下一代 iPhone 換掉變成 USB-C 就搞笑了...

歐盟對十四套 Open Source 軟體推出 Bug Bounty Program

歐盟對於 14 套 open source 軟體推出 bug bounty program,協助改善這些軟體的品質 (主要是資安這塊):「EU to fund bug bounty programs for 14 open source projects starting January 2019」、「In January, the EU starts running Bug Bounties on Free and Open Source Software」。

這十四套軟體的選擇應該可以參考「EU aims to increase the security of password manager and web server software: KeePass and Apache chosen for open source audits」這邊...

然後看到「Intigriti/Deloitte」這個才知道原來 Deloitte 也有做這個啊...

AWS 提供 OpenVPN-based VPN 服務

不知道為什麼在 feed reader 裡面沒注意到這則,後來是在 Facebook 上看到的。

AWS 推出了 OpenVPN-based 的 VPN 服務 AWS VPN:「Introducing AWS Client VPN to Securely Access AWS and On-Premises Resources」。

看起來是這個價錢:

AWS Client VPN pricing
$0.05 per AWS Client VPN connection hour
$0.10 per AWS Client VPN endpoint association hour

所以服務本身的費用要 $72/month 左右,另外 client 接上去的費用另外算?

目前支援的區域有限,暫時只有歐美的大區:

AWS Client VPN is available in US East (Virginia), US East (Ohio), US West (Oregon) and EU (Ireland) AWS Regions. Support for other AWS Regions is coming soon.

所以要開始開發 CECPQ2 了...

CECPQ1Google 在研究對抗量子電腦的演算法,作為測試用的演算法,曾經在 Google Chrome 的 54 beta 版 (2016 年) 存活過一段時間,最近又開始在開發新一代的演算法 CECPQ2 了,這次會是基於 TLS 1.3 上測試:「CECPQ2」。

CECPQ2 will be moving slowly: It depends on TLS 1.3 and, as mentioned, 1.3 is taking a while. The larger messages may take some time to deploy if we hit middlebox- or server-compatibility issues. Also the messages are currently too large to include in QUIC. But working though these problems now is a lot of the reason for doing CECPQ2—to ensure that post-quantum TLS remains feasible.

目前對抗量子電腦的演算法好像都跟 Lattice 有關,找時間來補一下基礎理論... @_@

HTTP/3 (QUIC) 的反面看法

這篇整理了 HTTP/3 (QUIC) 的反面看法,算是常見的疑慮都列出來了:「QUIC and HTTP/3 : Too big to fail?!」。

其實大多都是使用 UDP 而導致的問題:

  • 因為 UDP 導致 firewall 可能沒開,以及可能會需要等 timeout 走回 TCP 的問題。
  • 因為 UDP 變成很多事情在 userland 處理,而導致的 CPU 使用率比使用 TCP 的 TLS 1.2/1.3 高很多。
  • 因為 UDP 導致 amplification attack 的安全性問題,以及對應的 workaround 產生的頻寬議題。
  • 由於 UDP 會需要自己控制擁塞,等於是在 UDP 上面又重做了一次 TCP congestion algorithm,而且因為重作所以得考慮與 TCP 搶資源的公平性。

整篇文章算是整理了一般對 HTTP/3 的疑慮,之後如果有進展的話,可以再拿出來當 checklist 再確認有哪些有改善...

Vault 出 1.0 版,整合雲上面的 HSM 服務

看到「HashiCorp Vault 1.0」這則消息,Vault 要出 1.0 不是什麼新聞,重點是他把跟 Cloud Auto Unseal 的功能放出來了:

In Vault 1.0, we are open sourcing Cloud Auto Unseal, allowing for all users of Vault to leverage cloud services such as AWS KMS, Azure Key Vault, and GCP CKMS to manage the unseal process for Vault.

可以看在 AWS 上的作法:「Auto-unseal using AWS KMS」。

這樣在雲上的服務可以再降低風險...

Cloudflare 同時支援 TLS 1.2 與 TLS 1.3 的過程

Cloudflare 算是很早就參與 TLS 1.3 發展的廠商。在參與過程中他們希望讓支援 TLS 1.3 draft 的瀏覽器可以開始使用 TLS 1.3 draft,但又不希望因為 draft 頻繁修改而導致本來的使用者受到影響,所以就找了方法讓兩者並存:「Know your SCM_RIGHTS」。

這個方法就是 SCM_RIGHTS,可以讓另外一個 process 存取自己的 file description。

You can use UNIX-domain sockets to pass file descriptors between applications, and like everything else in UNIX connections are files.

所以他們的作法就是先讀取 TLS 裡 Client Hello 的資料,如果裡面有看到想要使用 TLS 1.3 的訊息,就透過前面提到的 SCM_RIGHTS 丟進 Golang 寫的程式跑:

We let OpenSSL read the “Client Hello” message from an established TCP connection. If the “Client Hello” indicated TLS version 1.3, we would use SCM_RIGHTS to send it to the Go process. The Go process would in turn try to parse the rest of the “Client Hello”, if it were successful it would proceed with TLS 1.3 connection, and upon failure it would give the file descriptor back to OpenSSL, to handle regularly.

這樣本來的 stack 就只要修改一小段程式碼,將當時還很頻繁修改的 TLS 1.3 draft 丟到另外一個 process 跑,就比較不用擔心本來的 stack 會有狀況了。

OpenSSL 的版號規則打算要改變...

在「The Holy Hand Grenade of Antioch」這邊看到 OpenSSL 的版號規則要改變了,變得比較接近 Semantic Version 的架構。

本來是 MAJOR.MINOR.FIX[PATCH] 這樣的形式,之後打算改成 MAJOR.MINOR.PATCH,不過現有的 1.1.1 與 1.0.2 會先維持原來的規則:

The current 1.1.1 and 1.0.2 versioning scheme will remain unchanged.

另外下一個大版本會是 3.0.0,而不是 2.0.0 (被其他計畫用掉了,所以為了避免混淆中獎,就直接跳過去了):

The current development version (master branch) will be identified as version 3.0.0. The OpenSSL FIPS module currently under development will also follow this versioning scheme. We are skipping the 2.0.0 major version because the previous OpenSSL FIPS module has already used this number.

另外授權也變成 Apache License 2.0 了:

OpenSSL version 3.0.0 will be the first version that we release under the Apache License 2.0. We will not be applying the Apache License to earlier releases of OpenSSL.

我記得 Apache License 2.0 跟 GPLv2 是不相容的... 本來使用 OpenSSL 的軟體為了 OpenSSL 的授權而加的例外條款,這次又要再修嗎...?

AWS 的 Firecracker 技術 (安全的 Container?)

AWS 放出來的 open source 專案 Firecracker,也就是在 AWS 內打造安裝的 container 環境所使用的技術:「Firecracker – Lightweight Virtualization for Serverless Computing」。

依照說明,看起來是利用 crosvm (KVM-based) 但讓他更輕,啟動 image 的時間更快,達到跟 container 類似的效果:

High Performance – You can launch a microVM in as little as 125 ms today (and even faster in 2019), making it ideal for many types of workloads, including those that are transient or short-lived.

Low Overhead – Firecracker consumes about 5 MiB of memory per microVM. You can run thousands of secure VMs with widely varying vCPU and memory configurations on the same instance.

看起來有機會在自己機器上跑看看 (i.e. 非虛擬環境)?跑之前要注意目前只支援 Intel 的硬體:

Firecracker currently supports Intel CPUs, with planned AMD and Arm support. Firecracker will also be integrated with popular container runtimes.