Tag: service

Facebook 證明 Tor 的 Hidden Service 不安全

Facebook 宣佈了 https://facebookcorewwwi.onion/ 這個 Tor hidden service：「Making Connections to Facebook more Secure」，讓人可以直接在 Tor 的網路裡連上 Facebook。

Facebook 的人用的方法與其他人一樣，是透過 brute force 算出這個 hidden service。

但這也直接證明了 Tor Hidden Service 不安全：(參考這個註解的說明)

If Facebook has the resources to brute force their own full key, then you better believe the NSA and GCHQ do too. Which means that you will no longer know if the hidden service you're connecting to is the real one or the NSA/GCHQ version. Tor hidden services are now dead.

這次未免太精彩了 XDDD

DigitalOcean 也提供 metadata service 了

DigitalOcean 在「Easily Automate The Provisioning Of Your DigitalOcean Droplets!」這篇裡面提到了 metadata server：「An Introduction to Droplet Metadata」。

完整的資料可以看「Droplet Metadata Overview」這邊，不過直接看 code 就知道大概是什麼樣子的服務了：

export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)

這對於自動化時要取得資訊 (或是傳入參數) 會很有幫助，有這個東西會省不少功夫... (以往要自己架一組 cluster，以 public ip 對 API 交叉查詢後傳回)

Percona 的 MySQL 備份服務

Percona 前幾天發表的新服務，Percona Backup Service：「MySQL Backup Service from Percona」。

只提供人力服務，而非雲端服務：

You provide the backup servers – on premise, in the cloud, or any combination. We implement the tools and processes to run your backups.

你還是要自己準備備份的設備，所以資料都還是可以控制在自己的手上。這個服務是借重 Percona 的人對 MySQL 的專長所發展的服務。

不過目前官網上沒有列出價錢，要寫信去問。

另外文章裡有提到「MySQL Backup and Recovery Best Practices」這份投影片，可以看一看 Percona 對備份的規劃，主要是從技術的方面討論 (尤其是備份時產生的 LOCK 問題)。

ptt.cc 偶而會解不出 IP 的問題

Update：感謝正妹 wens 幫忙，現在已經先上 workaround 了，狀況暫時解除...

最近發現 168.95.1.1 有時會找不到 ptt.cc 這個 domain (參考 gist:9995821)，原因是 ptt.cc 在 whois 上登記的是：

Name Server: NS0.PTT.CC
Name Server: NS1.PTT.CC
Name Server: NSOUT1.PTT.CC

用 dig 對 cc 的 NS server 查詢也可以確認：

;; AUTHORITY SECTION:
ptt.cc.                 172800  IN      NS      ns0.ptt.cc.
ptt.cc.                 172800  IN      NS      ns1.ptt.cc.
ptt.cc.                 172800  IN      NS      nsout1.ptt.cc.

;; ADDITIONAL SECTION:
ns1.ptt.cc.             172800  IN      A       140.112.172.10
ns0.ptt.cc.             172800  IN      A       140.112.172.16
nsout1.ptt.cc.          172800  IN      A       112.121.80.227

但 ptt.cc 的三台 NS server 上都找不到 nsout1.ptt.cc：

; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @140.112.172.10

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600
; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @140.112.172.16

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600
; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @112.121.80.227

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600

於是就錯亂了...

可以先解決的方法是先把 nsout1.ptt.cc 加上去，然後再規劃要怎麼修改兩邊的 record (Ptt 這側的 A/NS record，與 cc 的 A/NS record)。

補充一下，ptt2.cc 也有同樣問題。

架設 Tor 的 Hidden Service

會想要寫這篇是因為前陣子警察施暴影片在 YouTube 上一直被下架。

Tor 最常用到的是「隱藏使用者」的功能：使用者從 Internet 連到 Tor network 的進入節點 (entry node) 後，透過全世界的 Tor 節點加密傳輸，最後在出口節點 (exit node) 再連回 Internet 上的服務，藉此隱匿行蹤。

另外一個比較少被提到的用途是「架站」，也就是 Hidden Service。

在傳統的 Internet 架構上，知道 IP address 就容易發現機器所在地，要抄台或是在 ISP 端直接 ban IP address 也就相對容易。而 Hidden Service 就是想把服務藏到 Tor network 裡，讓外部不知道是哪一台伺服器，達成無法審查內容的目標。

官方的文件是「Configuring Hidden Services for Tor」這份。而這邊以 Ubuntu 12.04 的環境為例。

首先是先架設 web server，可以是 apache 或是 nginx，這不是本篇文章的重點 :p

然後在 /etc/tor/torrc 裡面加上：

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80

表示 hidden service 的相關資料會放在 /var/lib/tor/hidden_service/ 下，並且提供 port 80 的服務 (轉到本機 127.0.0.1 的 port 80)。

接下來重跑 tor：

service tor restart

然後看 hostname 是什麼：

cat /var/lib/tor/hidden_service/hostname

會看到一個 *.onion 格式的 hostname，像我架設的機器就會看到：

btyz5lgqirxipopo.onion

*.onion 的網址必須透過 Tor 的機制連，對一般人會比較麻煩。所以這邊要教的是透過 proxy 提供服務：

這樣就變得有很多用途...

Amazon SES 的認證延伸到 subdomain

以前 Amazon SES 每個 domain 都要認證一次，也就是說，就算我認證了 gslin.org，如果我要從 gslin@my.gslin.org 寄信，會因為 my.gslin.org 與 gslin.org 不同而被擋下來。

在官方的 blog 上宣佈認得 subdomain 了：「Subdomain Support is Now Available!」。

這樣就更省事了...

Google 推出的 Page Speed Service

以 Google 在全球的機房數量當然是一個賣點，不過除了 Geo-based 外，Google 還做了很多很多調整，至於這些調整會不會讓效能變好，就不曉得了...

Google 的說明頁面上以 www.ramkikrishnan.com 這個網站當作範例，目前這個網站是指回 original site，如果你要看輸出效果的話可以設 proxy 到 ghs.google.com 硬抓 www.ramkikrishnan.com 的 html 下來看，我把 diff 結果貼到這邊。

可以看出 Google 做了一些事情：

  • 重新判讀 html 後再丟出來，所以有些 html attribute 的順序被改變。
  • 如果配合 IE 的 conditional comments 讀入其他的 css，順序有可能被改變，但不確定是 Google 沒有針對 IE 的 conditional comments 判斷，還是將 css 讀出來後認為順序沒有差異 (我是用 curl 去抓，會因為 User-agent 給不同內容嗎？不確定...)。
  • 上面除了可能是 conditional comments 的處理外，也有可能是把 link 放到 script 後面，或是因為要放到 head 尾段造成的。
  • 會把 &copy; 轉成 ©，但也會把 ' 轉成 &#39;，看不太出來原因是什麼...

目前還看不出來比較複雜的 case，等帳號下來後再實際測試看看會比較準...