LinkedIn 忘記續約導致 SSL Certificate 過期

Netcraft 上看到 LinkedIn 出包的消息,這次是 country-mixed 的版本出包:「LinkedIn certificate blunder leaves users LockedOut!」。

在 DNS 上也可以看出來這兩個 CNAME 到不一樣的 load balancer 上:

;; ANSWER SECTION:
www.linkedin.com.       260     IN      CNAME   2-01-2c3e-003c.cdx.cedexis.net.
2-01-2c3e-003c.cdx.cedexis.net. 93 IN   CNAME   pop-ehk1.www.linkedin.com.
pop-ehk1.www.linkedin.com. 3560 IN      A       144.2.3.1
;; ANSWER SECTION:
de.linkedin.com.        86400   IN      CNAME   cctld.linkedin.com.
cctld.linkedin.com.     86400   IN      CNAME   mix.linkedin.com.
mix.linkedin.com.       213     IN      CNAME   pop-ehk1.mix.linkedin.com.
pop-ehk1.mix.linkedin.com. 3546 IN      A       144.2.3.5

SSL Labs 上也看得出來在 Alternative names 的地方是不一樣的:「SSL Server Test: www.linkedin.com (Powered by Qualys SSL Labs)」、「SSL Server Test: de.linkedin.com (Powered by Qualys SSL Labs)」。

然後因為 LinkedIn 有設定 HSTS,所以使用者在界面上完全無法登入:

Google Chrome 上可以用 badidea 繞過 (參考「在 Google Chrome 連上因 HSTS 而無法連線的網站」),但在 Mozilla Firefox 上的話目前沒找到方法可以在界面上 bypass,而是需要改 SiteSecurityServiceState.txt 這個檔案:「HTTP Strict Transport Security prevents me from accessing a server that I'm doing development on」。

不過也因為兩個 cluster 獨立運作,網址改一下應該就會動了...

這幾年比較很少看到大公司出這種包,還蠻有趣的 XD

LinkedIn 在 2012 年的密碼外洩比想像中嚴重,超過一億筆帳號密碼洩漏

在「Another Day, Another Hack: 117 Million LinkedIn Emails And Passwords」這邊看到 LinkedIn 在 2012 年的帳號密碼外洩情況比想像中嚴重許多,當時大家認為只有 650 萬筆資料洩漏,但實際上在 2016 年的現在被確認有 1.17 億筆。

官方也確認 2016 的這份洩漏是正確的,兩份公告在:

很多人都收到 password reset 信件了...

LinkedIn 的工程師分析 TCP Anycast 技術的穩定性與效能

LinkedIn 的工程師測試了 TCP Anycast 技術的穩定性以及效能:「TCP over IP Anycast - Pipe dream or Reality?」。

由於 stateless 再加上一個封包就傳的完的情況下,Anycast 技術被用在 DNS 上已經很長一段時間了,目前大多數 CDN 業者也都有用 Anycast 技術加快 CDN 的回應速度。

但 TCP 因為 stateful,如果 router 上採用的方式有問題,那麼就會導致封包可能會送到不同節點,這會是個嚴重的問題。不過很早之前,幾乎所有的骨幹 router 都已經支援 flow-based load balancing policy:

Most routers now do a per-flow load balancing, meaning packets on a TCP connection are always sent over the same path, but even a small percentage of routers with per-packet load balancing can cause the website to be unreachable for users behind that router.

所以 LinkedIn 的人試著測試 TCP Anycast 技術的穩定性:

So, to validate the assumption that TCP over anycast in the modern internet is no longer a problem, we ran a few synthetic tests.

測試的方式是設定 web server,讓下載速度不快,然後設了好幾個點並且放出對應的 routing,用 Catchpoint 服務監控,如果不穩定的話,應該就會收到 RST 中斷連線:

We configured our U.S. PoPs to announce an anycast IP address and then configured multiple agents in Catchpoint, a synthetic monitoring service, to download an object from that IP address. Our web servers were configured to deliberately send the response back slowly, taking over a minute for the complete data transfer. If the internet was unstable for TCP over anycast, we would observe continuous or intermittent failures when downloading the object. We would also observe TCP RSTs at the PoPs.

而好消息是,測試起來相當穩定:

But even after running these tests for a week, we did not notice any substantial instability problems! This gave us confidence to proceed further.

所以也因此可以看到 CacheFlyCloudFlare 兩家採用 TCP Anycast 技術:

[S]ome popular CDNs have also started using anycast for HTTP traffic.

由於穩定性的部份沒問題,所以接下來就是討論效率。

Anycast 是基於 routing 而決定要怎麼走,目標是希望可以透過 routing 取得 latency 最低的點。但實務上會把成本考慮進去,有可能會走到比較遠的點。在測試中可以發現北美的部份 Anycast 表現的比 GeoIP 好,但離開北美就掉很多:

所以 LinkedIn 決定用「Regional Anycast」,先用 GeoIP 決定要丟到哪個洲,而每個洲共用一個 Anycast 位置,這個方法讓效能提昇不少,全球在分配時 sub-optimal 的比率從 31% 降到 10% (i.e. 沒有分配到最好的點的比率):

上面主要是讀 LinkedIn 文章的心得,後面就是感想了。

TCP Anycast 用 CDN 上其實是相當吃虧的技術,由於 routing 的掌控權不再自己手上,有很多重要的手段是沒辦法做到的。

首先是當對外流量已經滿載時,不能切換到其他機房的機器,這邊講的「對外流量」不是 CDN 本身而已,而是中途任何的線路滿載都算,像是 HiNet 對 CloudFlare 香港機房的情況就很明顯。

另外在被 DDoS 時,由於沒辦法導流,在被攻擊時幾乎只剩下 clean pipe 類的解法,而同時間其他用戶會因為流量大量流入機房而一起被波及到。GeoIP 的方式彈性就大很多。

當然,還是有可以列出來的好處。主要是對於需要有固定 IP 應用來說 (像是 firewall 設定需求),TCP Anycast 滿足了這點。

只能說不同市場有不同的產品線在供應啦,不同的情境下有不同的需求...

LinkedIn 依照他們的資料對美國的大專院校排名

Slashdot 上看到 LinkedIn 對美國的大專院校排名:「Be True To Your CS School: LinkedIn Ranks US Schools For Job-Seeking Programmers」。

軟體工程師的部份在這邊:「LinkedIn 大學排名 — 軟體開發人員」。Slashdot 上的 comment 瞬間就戰起來,然後還有人跑出來問怎麼沒有美國外的資料 XDDD

CMU 第一名不算奇怪,但 Stanford 意外的後面?

WebScaleSQL

WebScaleSQLFacebookGoogleLinkedIn 以及 Twitter 四家公司對 MySQL 5.6 的 fork。

Percona 的人也針對 WebScaleSQL 與 Percona Server 5.6 的比較,寫了一篇技術分析的文章:「A technical WebScaleSQL review and comparison with Percona Server」。

Percona 那篇分析文章提到不少改善屬於比較激進類型,對於 Percona Server 以及 MySQL 官方版本的定位並不適合。

而在開發上,語法也換到 C99C++11,也就是打算拋棄很舊的系統 (沒有 C99/C++11 compiler)。不過就這點來說,使得這上面的 patch 要 backport 回 MySQL 又增加了一些狀況...

WebScaleSQL 的出現代表 MySQL fork 又多一家,而且因為背後是這四家公司搞出來的,看起來聲勢會很浩大。進入「合久必分」的階段...