Home » Posts tagged "security"

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.

AWS 推出了 S3 Object Lock,保護資料被刪除的可能性

AWS 推出了 S3 Object Lock,可以設定條件鎖住 S3 上的 object,以保護資料不被刪除:「AWS Announces Amazon S3 Object Lock in all AWS Regions」。

這個功能跟會計做帳的概念很像,也就是寫進去後就不能改,也不能刪除,保留一定時間後才移除掉:

You can migrate workloads from existing write-once-read-many (WORM) systems into Amazon S3, and configure S3 Object Lock at the object- and bucket-levels to prevent object version deletions prior to pre-defined Retain Until Dates or Legal Hold Dates.

AWS 提供有兩種模式,一個是 Governance mode,這個模式下可以設定某些 IAM 權限可以移除 S3 Object Lock。另外一個是 Compliance mode,這個模式下連 root account 都不能刪除:

S3 Object Lock can be configured in one of two modes. When deployed in Governance mode, AWS accounts with specific IAM permissions are able to remove object locks from objects. If you require stronger immutability to comply with regulations, you can use Compliance Mode. In Compliance Mode, the protection cannot be removed by any user, including the root account.

AWS 推出 Global Accelerator,用 AWS 的網路加速

AWS 推出了 Global Accelerator,利用 AWS 的網路加速:「New – AWS Global Accelerator for Availability and Performance」。

這個產品有點像是 GCP 的 Premium Network 的概念,從名稱叫做 Data Transfer-Premium (DT-Premium) 也可以看出來這點。另外 Cloudflare 也有類似的產品,叫做 Spectrum

使用者的連線會先進入最接近使用者的 AWS Edge,然後走 AWS 自己的網路到真正服務所在的 AWS 區域:

AWS 自家的 CloudFront 可以做類似的事情,但是 CloudFront 是 DNS-based service,而且只吃 HTTP 類的連線;這次推出的 Global Accelerator 則是 Anycast-based service,同時支援 TCP 與 UDP。

目前的 edge 只有北美、歐洲與亞洲:

AWS Global Accelerator is available in US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo) and Asia Pacific (Singapore).

這類服務通常也都可以擋下一些 DDoS 攻擊,畢竟是拿大水管在擋...

Amazon S3 推出 SFTP

Amazon 居然推出對 Amazon S3SFTP 服務了:「Introducing AWS Transfer for SFTP, a Fully Managed SFTP Service for Amazon S3」。

這個服務是掛在 AWS Transfer 的名義下 (AWS Transfer for SFTP),這對老系統來說可以省一些事情,不過目前還不支援固定 IP,這樣不太能直接搬上去 (這種老系統常常都是用 IP firewall 擋著):

Q: Can I use fixed IP addresses to access the SFTP server endpoint?
A: No. Fixed IP addresses that are usually used for firewall whitelisting purposes are currently not supported.

另外認證的部份看起來已經包括了常用的認證:

Q: Which compliance programs does AWS SFTP support?
A: AWS SFTP is PCI-DSS and GDPR compliant, and HIPAA eligible.

不過第一次的 SSH key 部份要怎麼取得啊... 有支援 SSHFP 嗎?

支援的區域蠻多的,對台灣使用常見的區域都有在第一波的清單內:

AWS SFTP is available in AWS Regions worldwide including US East (N. Virginia, Ohio), US West (Oregon, N. California), Canada (Central), Europe (Ireland, Paris, Frankfurt, London), and Asia Pacific (Tokyo, Singapore, Sydney, Seoul).

最後是價錢,上傳與下傳都要另外收費 (USD$0.04/GB),另外服務本身的 endpoint 也要收費 (USD$0.3/hour,一個月大約會是 $216),跟自己弄比起來好像不怎麼便宜,目前看起來主要是整合了 IAM 與其他機制... 不過這就是賣服務,看自己取捨就是了 :o

CloudFront 十週年、在東京的第十個 PoP,以及支援 WebSocket 與 Origin Failover

CloudFront 宣佈十年了,另外這次在東京又加節點了,變成 10 個:「Celebrating the 10 year anniversary of Amazon CloudFront by launching six new Edge locations」。

另外宣佈支援 WebSocket:「Amazon CloudFront announces support for the WebSocket protocol」,以及支援 Origin Failover:「Amazon CloudFront announces support for Origin Failover」。

WebSocket 算是大家等蠻久的功能,大家主要是希望利用 CloudFront 擋 DDoS,正常流量才往後丟。而 Origin Failover 則是可以設定兩個 Origin,當主要的掛掉時可以切到備用的,對於支援多節點的架構算是第一步 (目前看起來只能設兩個):

With CloudFront’s Origin Failover capability, you can setup two origins for your distributions - primary and secondary, such that your content is served from your secondary origin if CloudFront detects that your primary origin is unavailable.

都是隔壁棚 Cloudflare 支援許久的功能... 算是補產品線與進度?

Travis CI 將轉移到 VM-based 環境

Travis CI 宣佈了將目前 container-based 的環境轉移到 VM-based 的時程:「Upcoming Required Linux Infrastructure Migration」,裡面有提到十月初的時候的文章「Combining The Linux Infrastructures」。

看起來是因為安全性的考慮,container-based 的環境必須在指定 sudo: false 的情境下才能使用。如果需要 root 權限一定會丟到 VM-based 的環境跑。現在看起來 Travis CI 不打算維護 container-based 環境了,所以整個轉移到 VM-based 的環境...

另外一個方向應該是 Google 之前提出來的 gVisor 專案 (參考「Google 推出 gVisor 強化 Container 的安全性」),不過看起來相容性又是個問題...

Archives