雞肋功能: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 這些功能就可以省下不少功夫...

對於現在的瀏覽器,CSS 是否還需要加上 vendor prefix...

在「Do we need box-shadow or border-radius prefixes anymore?」這篇文章開頭就先給懶人包:

  • 如果沒有圓角 (border-radius) 或是陰影 (box-shadow) 會造成使用者不順。
  • 如果這四個平台 (以及瀏覽器) 的量夠大的話:Firefox 3.6-、Safari 4-、iOS 3.2-、Android 2.3-。

在這兩種情況下,你仍然需要加上 vendor prefix...

而比較長的說明,可以參考原文後半段,把這兩個效果分開說明。

如果是 Sass (SCSS) 使用者,就直接加吧,反正程式都幫你做好了... 雖然 validator 會叫 CSS 不合法,但也沒印象看過哪家瀏覽器會因為 css vendor prefix 就罷工... (真的有嗎?XD)