UUID 的 UX

在「The UX of UUIDs (unkey.dev)」這邊看到的紋章,原文在「The UX of UUIDs」。

裡面有不少是有幫助的建議,像是第一個建議是把 UUID 裡面的 - 拿掉,這樣對於 copy 比較方便 (畢竟大多數人應該是 copy UUID,不會是念出來?)。

第二個建議是加上 prefix,這點不一定侷限在 UUID,只要是 token 上面都很適合。這個在不少系統上應該都有看過,像是 GitHub 的 token,或是 AWS 的 token 都算是這類。

文章裡面沒有提到,但這個建議也可以幫助你在 CI 上設定 regex,擋下把 secret token 寫進去的行為。

第三個提到用 base58,一方面是減少長度,另外一方面是想要避免 1IiLl0Oo 的問題,這點我覺得還好... 既然都是 copy & paste 了,我覺得拿 base62 (i.e. 大小寫加上數字) 不錯,這避免特殊字元無法選擇到,也就是文章裡面第一個建議。

第四個建議是建議重新思考 range,因為 UUID 的 128-bit range 很大,但不是所有應用都需要用到這麼大的範圍確保 collision-free (於是可以當 primary key)。

這點讓我想到 X (Twitter) 當初發表的 Snowflake ID,在 Twitter 這種規模下 64-bit range 也已經夠用。

後面的文章內容就是在推銷自家東西,我就... 跳過了。

AWS 增加 CloudFront 的 AWS-managed prefix list 讓管理者使用

看到 AWS 公告提供 CloudFront 的 origin subnet 資訊 (AWS-managed prefix list) 讓管理者可以用:「Amazon VPC now supports an AWS-managed prefix list for Amazon CloudFront」。

以往會自己去「AWS IP address ranges」這邊提供的 JSON 檔案定時撈出來再丟到 managed prefix list 裡面,這次的功能等於是 AWS 自己管理這個 prefix list 讓管理者使用。

馬上想的到的用途就是 HTTP/HTTPS port 了,只開放給 CloudFront 的伺服器存取:

Starting today, you can use the AWS managed prefix list for Amazon CloudFront to limit the inbound HTTP/HTTPS traffic to your origins from only the IP addresses that belong to CloudFront’s origin-facing servers. CloudFront keeps the managed prefix list up-to-date with the IP addresses of CloudFront’s origin-facing servers, so you no longer have to maintain a prefix list yourself.

要注意的是這不應該當作唯一的 ACL 手段,因為其他人也可以建立 CloudFront distribution 來穿透打進你的 origin server。

另外有個比較特別的地方,這個 prefix list 的權重很重,使用他會算 55 條 rule 的量,在 security group 內很容易撞到 60 條的限制,在 route table 裡面則是直接撞到 50 條的限制;不過這兩個限制都可以跟 AWS 申請調昇:

The Amazon CloudFront managed prefix list weight is unique in how it affects Amazon VPC quotas:

  • It counts as 55 rules in a security group. The default quota is 60 rules, leaving room for only 5 additional rules in a security group. You can request a quota increase for this quota.
  • It counts as 55 routes in a route table. The default quota is 50 routes, so you must request a quota increase before you can add the prefix list to a route table.

如果 HTTP 一條,HTTPS 也一條,那就會算 110 rules 了,有暴力的感覺...

Amazon VPC 允許直接把整個網段配到某台 EC2 Instance 上了

看到「Amazon Virtual Private Cloud (VPC) customers can now assign IP prefixes to their EC2 instances」這邊的消息,VPC 可以把整個網段配到某台 EC2 Instance 上了。

之前也有其他方法可以做到類似的事情:

  • 用 VPC 提供的 Routing Table 把網段指到某台 EC2 的機器上。
  • 把這台 EC2 機器的「Enable Source/Destination Check」關閉。

目前就是用這個方法搞定 VPN server 的:我們希望機器連上 VPN 後拿到 10.x.x.x 的 IP address,而且可以被 VPC 內直接存取,而不要被 NAT 掉。

好像該開張票轉移過去...

雞肋功能:AWS 推出 Managed Prefix Lists 管理 IP 列表

AWS 總算推出可以管理 IP 列表的功能 Managed Prefix Lists,就不需要自己在 security group 裡面針對一堆 IP 設重複的設定:「Amazon Virtual Private Cloud (VPC) customers can now use their own Prefix Lists to simplify the configuration of security groups and route tables」。

目前這個功能在大多數的區域都開放使用了:

There is no additional charge to use the Prefix Lists. Support for Prefix Lists is available in all public regions with support in Africa (Cape Town), Europe (Milan), China (Beijing), and China (Ningxia) coming soon. For more information on prefix lists, visit our public documentation.

但實際測試後發現在 web console 的操作上不算好用,主要是因為這個功能還是會受到「How do I increase my security group limits in Amazon VPC?」這邊提到的限制影響,如果沒有開 support ticket 調高限制,預設值是:

  • 每個 network interface 可以設定 5 個 security group。
  • 每個 security group 可以設定 60 條規則。

在建立 prefix list 時,需要設定「裡面會包含的最大數量」(可以到 1000),是一個你不知道為什麼要設定的東西,然後我就很開心設了 1000...

接下來開了一個純測試用的 security group (裡面是空的),結果這個 prefix list 掛不上去...

後來測了幾次後發現 prefix list 在 security 內不是吃一條 rule,而是直接照剛剛設定的「最大數量」去展開。

所以重新砍掉建一個新的 prefix list,改成 15 條後,就可以在 security group 上面掛四次 prefix list (不同的 port),剛好吃完 60 條規則,第五個設定就完全掛不上去... (無論是用 prefix list,或是設定 CIDR)

所以這些限制讓 prefix list 在 web console 上變得很不怎麼好用:

  • 一開始就要設計好 prefix list 內的最大筆數,如果不幸用完是沒辦法修改的。
  • 在 security group 裡不是吃一條規則,而是以最大筆數佔用,prefix list 內沒有射到最大筆數也還是得佔用。

但如果變成 Terraform 之類的工具用的話就還馬馬虎虎,因為你可以設計機制,改 prefix list 時可以開新的 prefix list (最大上限設成實際的數量,不會有浪費),然後再把 security group 裡面的 prefix list reference 換掉。

不過又想到,都已經用 Terraform 這種工具了,加上你又不是只佔一條規則,我就自己展開就好了啊... 不需要這個功能就能處理了。

「雞肋」XD

SHA-1 的 chosen-prefix collision 低於 2^64 了...

算是前陣子的大消息,SHA-1 的 chosen-prefix collision 需要的運算已經低於 2^64 了:「SHA-1 is a Shambles」。

基本的 collision 指的是演算法找出 p1p2 兩個字串,使得 hash(p1) == hash(p2)。但這個方法對於實際的攻擊價值並不大,因為 p1p2 是透過演算法找出來 collision,都是亂數字串。

chosen-prefix collision 指的是先給定 p1p2 (在實際攻擊中,兩組都會是有意義的字串),然後攻擊的演算法可以算出 m1m2,使得 hash(p1 // m1) == hash(p2 // m2),其中的 // 就是字串加法。這樣的是先產生出有意義的字串,於是就可以在真實世界中使用。

舉例來說,我先產生出 blog.gslin.org 的 SSL certificate,然後再產生出一個 github.com 的 SSL certificate,這兩個分別就是 p1p2

接下來演算法算出 m1m2,使得 hash(p1 // m1)hash(p2 // m2) 相同。

接著,我就可以拿 p1 // m1 給 CA 簽名 (因為我有 blog.gslin.org 的擁有權),而拿到的憑證因為 hash 值相同,就可以給 github.com 這組用。

2008 年的時候就用這個方法生出一個 sub-CA:

In 2008, researchers used a chosen-prefix collision attack against MD5 using this scenario, to produce a rogue certificate authority certificate. They created two versions of a TLS public key certificate, one of which appeared legitimate and was submitted for signing by the RapidSSL certificate authority. The second version, which had the same MD5 hash, contained flags which signal web browsers to accept it as a legitimate authority for issuing arbitrary other certificates.[14]

另外,如果跟 2017 年由 GoogleCWI 打出來的 SHAttered 比較,當時的攻擊是 identicial-prefix,實際上的用途沒那麼大,這次是 chosen-prefix,就有很強的實際用途了。

所以這次的攻擊給了幾個重要的事情。

第一個是 SHA-1 的 chosen-prefix collision attack 運算已經降到 2^64 以下了,然後加上:

第二個是 2^64 的運算成本已經低於 USD$100k 了,作者是使用 GPUserversrental 這個租用 GPU 的服務跑出這次的運算,而這也表示攻擊安全層級是 2^64 的密碼系統,成本也是 USD$100k 了。

地球上還是有不少系統使用 SHA-1 (作者在網站上有提到),看起來這陣子會有不少修正...

AWS 的 BYOIP 服務開放一般使用了...

先前提到的「AWS 提供自帶 IP 到 AWS 上的服務了...」只能在 us-west-2 上使用 (需要申請),現在則是開放一般使用了:「Announcing the general availability of Bring Your Own IP for Amazon Virtual Private Cloud」。

而且範圍也增加了,除了本來測試的區域 us-west-2,現在 us-east-1us-east-2 都可以用:

This feature is now publicly available in US East (N. Virginia), US East (Ohio) and US West (Oregon) AWS Regions.

費用方面也都不需要額外費用:

There is no additional charge to use the BYOIP feature. Also, you don’t have to pay for Elastic IP addresses that you create from BYOIP address prefixes.

從文件上看起來目前只支援 IPv4,每段最少需要 /24,而且每個 region 最多五個 range,另外保留使用權 (如果 IP 網段之前有很多不良記錄時 AWS 可以拒絕)。

關閉新版 Google Chrome 網址列雞婆省略 www 的行為...

因為平常用的 Google Chrome 是 beta channel,前陣子出新版後網址遇到 wwwm 時就會不見,像是網址輸入 https://www.google.com,在連上後會變成這樣:

這樣讓人很不習慣,當時在網路上找了一些資料都沒找到,結果剛剛找資料時意外發現找到解法了:「Chrome address bar no longer shows protocol or www subdomain」。

把這個選項改成 Disabled 後,重開瀏覽器就恢復原來的行為了...

Amazon S3 提供更高的存取量...

AWS 宣佈提高了 Amazon S3 的效能:「Amazon S3 Announces Increased Request Rate Performance」。

每個 S3 prefix 都可以到 5500 RPS read 與 3500 RPS write:

Amazon S3 now provides increased performance to support up to 3,500 requests per second to add data and 5,500 requests per second to retrieve data, which can save significant processing time for no additional charge. Each S3 prefix can support these request rates, making it simple to increase performance exponentially.

舊的資料可以看「Request Rate and Performance Considerations」這邊,裡面沒有明講速度,但有提到如果超過 800 RPS read 與 300 RPS write 的門檻,建議開 case:

However, if you expect a rapid increase in the request rate for a bucket to more than 300 PUT/LIST/DELETE requests per second or more than 800 GET requests per second, we recommend that you open a support case to prepare for the workload and avoid any temporary limits on your request rate.

不過如果有量的話,還是建議照著原來的 prefix 建議,打散處理會比較好,通常在前面的 CDN 通常可以跑簡單的 url rewrite 處理掉 (像是 CloudFront 自家或是 Cloudflare),像是把使用 unix timestamp (ms) 的 https://www.example.com/1531843366123.jpg 變成 https://www.example.com/6123/1531843366123.jpg,這樣可以讓 Amazon S3 的後端依照 prefix 打散 loading,避免當站愈來愈大的時候很難處理。

在 S3 上儲存大量資料時要注意的事情

印象中要在 Amazon S3 上面存大量資料時需要注意 key 的命名,用 Google 找了找發現官方的「Request Rate and Performance Considerations」這篇。

文章中有提到這是對有大量存取需求時才需要注意的事項:

The guidelines in this section apply if you are routinely processing 100 or more requests per second. If your typical workload involves only occasional bursts of 100 requests per second or more, you don't need to follow the guidelines in this section.

不過平常即使沒有需要大量存取,還是可以照著做,因為應該不會有負面影響。如果能照著上面的方式先做,之後也許會受益...

由於 Amazon S3 是使用 key-prefix 當作 partition 的依據,所以 prefix 的值對於效能很重要。官方推薦的幾種方法都是對 key-prefix 下手:

  • 對整個 path + filename 的字串 hash 後當作 prefix。舉例來說,examplebucket/2013-26-05-15-00-00/cust1234234/photo1.jpg hash 後加到前面,名稱變成 examplebucket/232a-2013-26-05-15-00-00/cust1234234/photo1.jpg
  • 將最前面一段 reverse string。像是把 2134857/data/start.png 變成 7584312/data/start.png

MySQL InnoDB 與 PostgreSQL 的 Partial Index(es) 是不一樣的東西...

MySQL InnoDB 指的 Partial Index 是:

An index that represents only part of a column value, typically the first N characters (the prefix) of a long VARCHAR value.

PostgreSQL 指的 Partial Indexes 是:

A partial index is an index built over a subset of a table; the subset is defined by a conditional expression (called the predicate of the partial index). The index contains entries only for those table rows that satisfy the predicate. Partial indexes are a specialized feature, but there are several situations in which they are useful.

先講結論,PostgreSQL 可以做掉 MySQL InnoDB 的 Partial Index 想做的事情,而且還更多。

MySQL InnoDB 的 Partial Index 是設定對 prefix index (對字串前面的 n bytes),可能的情況是 CHAR(32) 只對前面 16 bytes 索引。

PostgreSQL 的 Partial Indexes 受益於許多方面而更強大。因為有 Indexes on Expressions,所以除了可以像 MySQL 對 prefix 索引外,也可以索引 suffix,甚至是索引透過 string function 得出來的值。

像是 PostgreSQL 可以設定「我只要索引一月一日出生的人的 username」:

CREATE INDEX test_index ON test_table (username) WHERE birth_month = 1 AND birth_day = 1;

在 MySQL 裡需要反正規化後下 index,或是拆出另外一個表格再下 index 的問題,在善用 PostgreSQL 這些功能就可以省下不少功夫...