CloudFlare 全面支援 DNSSEC

CloudFlare 宣佈全面支援 DNSSEC 了:「Announcing Universal DNSSEC: Secure DNS for Every Domain」。

另外也因為現在需要把 public key 手動 copy & paste 到 DNS 註冊商會很麻煩 (而且有可能會貼錯),所以 CloudFlare 的人試著往 IETF 標準化這件事情:

At CloudFlare, we care about advancing what’s possible on the Internet, so we have published an Internet Draft proposing a protocol for DNS providers such as CloudFlare to communicate directly to registries and registrars. We are pushing it to become an accepted Internet Standard RFC.

AWS Public IP 的變動可以透過 Amazon SNS 訂閱

在「Subscribe to AWS Public IP Address Changes via Amazon SNS」這邊提供利用現有的 Amazon SNS 所提供的新功能。

依照說明,訂 arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged 就可以了:

會收到類似於這樣的東西:

{
  "create-time":"yyyy-mm-ddThh:mm:ss+00:00",
  "synctoken":"0123456789",
  "md5":"6a45316e8bc9463c9e926d5d37836d33",
  "url":"https://ip-ranges.amazonaws.com/ip-ranges.json"
}

不過之前就可以 polling 了,這個功能好像還好...

Twitter 的歷史資料企業方案

Twitter 宣佈可以搜尋所有公開的 tweet 了:「Instant and complete access to every historical public Tweet」。

This new product builds off of our existing 30-Day search solution and extends the available window of instant and complete Twitter access to a span of more than nine years… and counting.

提供給 Gnip 的客戶搜尋:(這家公司去年被 Twitter 買下,參考「Twitter buys social data provider Gnip, stock soars」)

The Full-Archive Search API will now allow Gnip customers to immediately search for any historical public Tweet — ever.

看起來是個半獨家生意:

For more technical information about the Full Archive Search API, you can read our support documentation, and contact the Twitter Data Sales team at data-sales@twitter.com to learn how your business can start using this new historical API today.

uBlock₀ 提供阻擋 WebRTC 取得 Local IP address 的功能

Google Chrome 上之前是透過 WebRTC Block 之類的軟體阻擋網站透過 WebRTC 取得 Local IP address 的功能,現在則內建在 uBlock₀ 內了。

在「You can block WebRTC from leaking your IP now in uBlock Origin」這邊看起來是這個月月初 (2015 年 7 月) 開發出來的功能。

WebRTC Leaktest 交叉測試可以發現 Public IP address 的部份,目前測過的套件都擋不下來,但 Private IP address 的部份都有順利擋下來。

又可以少裝一個套件了...

對 GitHub 的 Public Key 分析

Hacker News Daily 上看到有人針對 GitHub 上的 Public Key 分析:「Auditing GitHub users’ SSH key quality」。

這個分析主要用的是 GitHub 的 .keys 功能取得:

A little known feature of GitHub is the ability to look at the public SSH keys that other users have set to be authorised on their account (for example https://github.com/torvalds.keys)

作者從去年 2014 年 12 月 27 日跑到今年 2015 年 1 月 9 日,共取得了 1376262 把 public key,然後就針對這些 key 分析。

「The Debian bug bites again」這一段講的是 CVE-2008-0166 (可以參考「該換 ssh keys 了」這篇的說明),發現即使是七年後的現在,也還是有問題。

另外還有 256 bits 與 512 bits 的 RSA key,作者自己建立了一把測試,用 i5-2400 只要 25 分鐘就可以解出 256 bits 的 private key:

This risk isn’t only real if someone had gathered together top of the line mathematicians or supercomputers worth of power, the 256 bit key I factored was factored on a i5-2400 in 25 mins.

NSA 應該都摸透了...

作者提供的時間線:

[27th December 2014] Key Crawl Started
[28th Feb 2015] Disclosed low bits issue to a peer at GitHub
[1st March 2015] Discovered the weak Debian Keys (and disclosed)
[5th May 2015] Debian keys revoked, emails sent out
[1st June 2015] Weak and low quality keys revoked

Amazon VPC 的 Private Subnet 不需要透過 NAT 去 Amazon S3 抓資料了

在今天之前,Amazon VPC 裡 Private Subnet 的機器需要透過 NAT 才能連到 Amazon S3 的 Endpoint API 上操作:(NAT instance 會放在 Public Subnet 裡)

出自「NAT Instances」的說明。

但在這個架構中,如果 NAT instance 不夠大台,甚至是流量需求超過 10Gbps 時就會有效能瓶頸了。而目前沒有比較簡單的方法可以解決。(一種解法是拆多個 subnet 跑,透過多個不同的 NAT instance 連出去,但這樣架構又變複雜了)

今天則是公佈了讓內部可以直接存取 Amazon S3 的方式:「New – VPC Endpoint for Amazon S3」。第一波是美國 (扣除美國政府用的區域)、歐洲、亞洲、澳洲。所以是巴西與美國政府兩個區域還沒上:

Amazon VPC Endpoints for Amazon S3 are available now in the US East (Northern Virginia) (for access to the US Standard region), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), and Asia Pacific (Sydney) regions.

這樣是解了不少問題,不過如果可以直接解決 NAT infrastructure 的問題應該會更痛快?

RFC7469:Public Key Pinning Extension for HTTP

前幾天的 Standards Track:「Public Key Pinning Extension for HTTP」。

HPKP (HTTP Public Key Pinning) 機制是讓 server 端在第一次連線時告訴 client (像是瀏覽器) Public Key 資訊,也就是建構在 TOFU (Trust-on-first-use):

Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)

機制上很像 HSTS (HTTP Strict Transport Security,RFC6797)。依據 Mozilla 的「Public Key Pinning」資料,目前新版的 Google ChromeFirefox 都有支援了。

GitHub 保護自家的 OAuth Access Token 不會進入 GitHub 上公開的 Repository

GitHub 的公告:「Keeping GitHub OAuth Tokens Safe」。

當你不小心把 GitHub 的 OAuth Access Token 推到 GitHub 的 public repository 時,站方會自動 revoke 掉:

Starting today you can commit more confidently, knowing that we will email you if you push one of your OAuth Access Tokens to any public repository with a git push command. As an extra bonus, we'll also revoke your token so it can't be used to perform any unauthorized actions on your behalf.

保護使用者在使用 GitHub 自家的產品。

Firefox 也要支援 Public Key Pinning Extension for HTTP

在「Mozilla to Support Key Pinning in Firefox 32」看到的新聞,目前的標準還是 draft:「Public Key Pinning Extension for HTTP」。

被簡稱 PKP 與 HPKP:(一般比較常用前者)

We call this "public key pinning" (PKP); in particular, this document describes HTTP-based public key pinning (HPKP).

可以看到 Google Chrome 程式碼裡面是怎麼使用 PKP 技術預載的:「/trunk/src/net/http/transport_security_state_static.json」。

目前 Google Chrome 使用的方式是限制 Google 的網域只能由某些特定的 CA 才能簽,這樣可以降低其他 CA 簽出高經濟價值的 SSL certificate 的效益。

Mozilla 的 wiki 上面可以看到對應的條目:「SecurityEngineering/Public Key Pinning」,目前 Firefox 的版本是 31,也就是從下一個版本就支援了。

第一波的 32 版會支援 Mozilla 自己的某些站台,以及一些 Twitter 的網域。

第二波的 33 版會把 Twitter 的部份擴充到 *.twitter.com,另外還會支援 Google 所擁有的網域。

第三波的 34 版會支援 Firefox account (*.accounts.firefox.com)、Tor 以及 Dropbox