交大的 Single Sign On 系統

Facebook 上看到這個消息:「交通大學 OAuth 平台上線!」,由於 D2 E-mail 系統上沒什麼資料,主要賣點還是 Single Sign On 的部份。

當初想要做 OpenID 的 SSO (當年已經有 OpenID 1.0),跟 cschen 申請了 sso.nctu.edu.tw (還掛在 ccreader 上呢),但後來還是沒實做出來 (也忘了是什麼原因),過了快十年總算有人跟計中合作跳下來做了 XD

SSO 很多人都能做 (像是透過 POP3S 或是 IMAPS 認證,甚至透過網頁登入確認),但只有帶著官方名義做才有意義 (也就是本來就碰的到密碼的人來管理),這次唯一可惜的是還沒有讓系統完全自動化... (i.e. 自由申請)

SSL/TLS 以及 PKI 的歷史 (加上各種風風雨雨)

Twitter 上看到 Let's Encrypt 轉了這則講 SSL/TLS 與 PKI 的時間線:「SSL/TLS and PKI History」。

這幾年的資料比較完整,看著這些時間線剛好可以拿來複習一下。

而 2013 年 Snowden 的事情也被放進去了,這使得這三年各種 SSL/TLS 化的進展急劇加速 (包括各種 HTTPS 的進展,甚至是郵件的 STARTTLS 加密等等),也因此推動了像是 Let's Encrypt 這樣更方便提供 SSL/TLS certificate 的組織成立。

Facebook 推薦好友機制的演算法讓更多的隱私問題浮現...

在「Facebook recommended that this psychiatrist’s patients friend each other」這邊報導了 Facebook 推薦好友機制的演算法意外的拉出了奇怪的東西:

[...], such as this story from Lisa*, a psychiatrist who is an infrequent Facebook user, mostly signing in to RSVP for events. Last summer, she noticed that the social network had started recommending her patients as friends—and she had no idea why.

“I haven’t shared my email or phone contacts with Facebook,” she told me over the phone.

精神科醫師被 Facebook 推薦他的病人... 而更慘的是病人也收到的推薦包括了其他的病人:

Another one of her female patients had a friend recommendation pop up for a fellow patient she recognized from the office’s elevator. Suddenly, she knew the other patient’s full name along with all their Facebook profile information.

“It’s a massive privacy fail,” said Lisa. “I have patients with HIV, people that have attempted suicide and women in coercive and violent relationships.”

而且因為職業的關係,他也對此很小心防範:

Lisa lives in a relatively small town and was alarmed that Facebook was inadvertently outing people with health and psychiatric issues to her network. She’s a tech-savvy person, familiar with VPNs, Tor and computer security practices recommended by the Electronic Frontier Foundation–but she had no idea what was causing it.

這聽起來不是什麼好演算法 :o

大量破解 Facebook 帳號的方法

Facebook 安全設計上的問題造成的重大漏洞:「Hacker reveals How He Could have Hacked Multiple Facebook Accounts」。

攻擊者先用很多 proxy 去打出哪些 id 是有效的:

Gurkirat first collected valid Facebook IDs by making queries to Facebook Graph API starting with 100,000,000,000,000, since Facebook IDs are generally 15-digit long and then visited www.facebook.com/[ID] with a valid ID number in place of [ID].

這樣他就順利打出兩百萬個帳號:

Once entered, the URL automatically redirected and changed the Facebook ID to the user's username. In this way, first, he was able to make a list of 2 Million valid Facebook usernames.

接下對這些帳號發出重設密碼的需求,並且開始亂猜六碼數字 (也是透過大量的 proxy):

Then using a script, hundreds of proxies and random user-agents, Gurkirat automatically initiated the password reset requests for those 2 million users, each assigned a 6-digit password reset code, thus consuming the complete 6-digit range.

然後就打出一票來了:

最大的問題在於六碼數字的強度不夠,但 Facebook 看起來沒打算改...

Mozilla 在考慮移除 WoSign 的 CA Root

雖然平常早就把 WoSign 移除信任,但在「Mozilla考虑对沃通CA采取行动」這邊看到有趣的消息,翻了一下 Gervase Markham 發表的原文還蠻精彩的:「Incidents involving the CA WoSign」。

第一次事件 (Incident 0) 是在 2015/04/23,攻擊者只要能夠證明他能控制某個 TCP port,就會發出 certificate:

On or around April 23rd, 2015, WoSign's certificate issuance system for their free certificates allowed the applicant to choose any port for validation. Once validation had been completed, WoSign would issue certificates for that domain. A researcher was able to obtain a certificate for a university by opening a high-numbered port (>50,000) and getting WoSign to use that port for validation of control.

設計不良造成的資安事件總是會發生。重點在於 Google 知道,但 Mozilla 完全不知道:(我講得很保守是因為這個句子在 thread 後面被澄清解釋的更慘,參考後文)

This problem was reported to Google, and thence to WoSign and resolved. Mozilla only became aware of it recently.

更嚴重的是,這次的事件在 WoSign 的稽核上沒有出現:

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

第二次事件 (Incident 1) 是在 2015 年六月,也是資安設計的問題,當你可以拿到 WoSign 所指定的 subdomain 控制權後,你就可以拿到 parent domain 的 certificate,而這次甚至被拿到 GitHub 全系列的 certificate:

The reporter proved the problem in two ways. They accidentally discovered it when trying to get a certificate for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then confirmed the problem by using their control of theiraccount.github.com/theiraccount.github.io to get a cert for github.com, github.io, and www.github.io.

嗯,也沒通報:

* This misissuance incident was not reported to Mozilla by WoSign as it should have been (see above).

嗯,稽核也沒出來:

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

嗯,被拿到的 domain (ucf.edu) 也沒 revoke:(可以從「crt.sh | 29647048」這邊看到)

They reported this to WoSign, giving only the Github certificate as an example. That cert was revoked and the vulnerability was fixed. However recently, they got in touch with Google to note that the ucf.edu cert still had not been revoked almost a year later.

第三次事件 (Incident 2) 則是在 2016 年七月,由於現在大多數的瀏覽器都會對 2016 後簽出的 SHA-1 憑證直接標示為不安全,而 WoSign 的 API 提供造假,讓簽名日期 (notBefore) 簽在 2015/12/20:

Using the value "1" led to a certificate which had a notBefore date (usage start date) of 20th December 2015, and which was signed using the SHA-1 checksum algorithm.

嗯,然後否認造假:

* WoSign deny that their code backdated the certificates in order to avoid browser-based restrictions - they say "this date is the day we stop to use this code"[4]. If that is true, it is not clear to us how StartCom came to deploy WoSign code that WoSign itself had abandoned.

嗯,然後還是沒有回報給 Mozilla:

* This misissuance incident was not reported to Mozilla by WoSign as it should have been.

稽核報告應該是因為這太新,還沒開始做?

另外在 thread 討論時,Google 的 Ryan Sleevi 澄清的更慘:

Clarification: In none of these incidents was Google notified proactively by WoSign. Instead, Google received communication from internal or external researchers regarding these issues, either prior to resolution or much later after the fact, and subsequently contacted WoSign regarding them.

It was only when Google found out recently that other programs were NOT notified, proactively, as had been expected, that Google shared the details it was aware of regarding various CA incidents, including those of WoSign, mentioned in this thread.

也就是說,是 Google 主動發現這些問題,並且通報 WoSign。後來過了許久發現 WoSign 沒有照規定通報其他 CA Root 管理單位 (以這邊來說是 Mozilla),於是 Google 決定主動通報其他單位,然後大~爆~炸~

在密碼學理論裡,CA 架構是靠著稽核建立信任的,這次的事情又再次證實這個問題 (但目前沒有其他好的機制可以做)。來猜測下場的話,我的預期是會像拔掉 CNNIC 的作法拔掉信任,但針對之前發出的 certificate 設為白名單 (直到過期):

OpenSSL 1.1.0

看到「OpenSSL 1.1.0 released」這篇得知大家期待已久的 OpenSSL 1.1.0 出了,在 1.1.0 的重要新功能中,對 ChaCha20 + Poly1305 的支援算是大家等很久的:

  • Support for ChaCha20 and Poly1305 added to libcrypto and libssl

由於 RC4 已經被證明不安全,OpenSSL 內變成沒有堪用的 stream cipher,這邊總算要補上來了...

另外兩個也頗有趣的:

  • Support for scrypt algorithm
  • Support for X25519

多了些東西...

Scylla 1.3

看到 Scylla 正式公告 1.3 版的消息了:「Scylla release: version 1.3」。

Scylla 是用 C++ 重寫 Java 版本的 Cassandra 所有東西 (包括資料結構與 Protocol),目標是做到可以完全相容替換現有 Cassandra Cluster。(號稱可以一台一台移除 Cassandra 的程式,裝上 Scylla 後就可以無痛換過去)

而 Scylla 另外一個重點是效能的提昇,官方宣稱在完整最佳化的情況下是 10x 以上的效能提昇,之前拿 AWS 實測 (沒有完整最佳化) 也可以看到 2x 到 4x 的數字,對於目前的 Cassandra 應用來說極為重要。

1.3 版最重要的功能就是對 Thrift 的支援:

Thrift support. Many Cassandra users are still using Thrift, and they can now continue doing so while benefiting from Scylla’s performance. Built on top of Scylla CQL internal implementation, Scylla Thrift provides similar throughput and latency to Scylla CQL. Users of projects like KairosDB and Titan can now migrate to Scylla while maintaining full protocol compatibility .

本來在 roadmap 上的計畫是用兩個版本支援 Thrift:(從 Google Cache 拉出來的,CSS 看起來有些問題,不過意思有到就好)

剛剛發現 1.4 的 roadmap 已經沒有列 Thrift 了:

這應該是暗示已經實作完了?透過 Thrift 界面跟 Cassandra 溝通的應用程式都可以使用 Scylla 了...

先前在「Facebook Presto · Issue #1139 · scylladb/scylla」這邊跟 ScyllaDB 的人花了不少時間,總算是給出一份 data set 可以讓他們重製 bug,也算是有代價了 XD

硬派學 JavaScript...

前幾天看到「Someone emailed me asking for tips or sites for learning JavaScript, and this is my final answer.」這篇也是頗有趣的...

Read the ECMAScript specification.

下面還花了些篇幅解釋要怎麼讀 XDDD

Don’t feel like you have to understand every word. Give yourself permission to just force the words into your brain, and move on to the next section. If you’re diligent about it, it only takes a few hours. Repeat this process every few years.

超硬派的 XDDD

更新 letsencrypt.sh 的 PPA

letsencrypt.sh 是個用 shell script 實作出來的 letsencrypt/acme client,可以對 Let's Encrypt 申請出 SSL certificate。相較於官方後來交接給 EFFCertbot,我還蠻推薦使用純粹只需要 shell script 的 letsencrypt.sh...

由於作者沒有發出新的 release tarball,加上目前最新的 release 的程式也已經無法使用,所以昨天花了點時間更新了 letsencrypt.sh 的 PPA,就弄了一個 0.2.0.20160822 (版本號碼大於目前的 release 版本的 0.2.0):「PPA for letsencrypt.sh」。

與 0.2.0 版相比有個 BC-break 的地方:新版的 config 改檔名了 (從 config.sh 變成 config),如果之前有設定的話要記得改:

$ cd /etc/letsencrypt.sh/
$ sudo mv config.sh config

也趁機把之前建立 source package 的 build.sh 改成可以吃 git hash 或是 tag name 的版本,這樣需要針對特定版本產生 source package 也簡單多了。