Home » Posts tagged "isp"

Telegram 使用 CDN 加速下載

Telegram 說明他們將會使用 CDN 加速:「More Speed and Security!」。

資料在 CDN 的節點上是加密的,金鑰需要透過 Telegram 的 key server 提供:

While these caching nodes are only used to temporarily store public media (imagine Telegram versions of superpopular YouTube hits), all data that goes through them is encrypted with a key unknown to the caching nodes. In other words, we treat these CDN caching nodes just like we treat your internet provider – they only ever get encrypted junk they can't decipher.

但這表示 Telegram 本身有能力解開這些資料?不知道這邊講的是什麼行為...

使用者如果選擇願意公開的話當然沒問題,但這種情況下也不需要 CDN 加密;而當使用者不願意公開時,應該是期望 Telegram 也無法解開這些資料?再來看看到底是怎麼樣的功能要上 CDN?

利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊

在「Netflix found to leak information on HTTPS-protected videos」這篇看到了研究員透過 VBR 所透露出的 side channel 資訊,成功的取得了被 HTTPS 保護的 Netflix 影片資訊。這對於美國的 ISP 是個大利多 (加上之前通過的法案),但對於個人隱私則是嚴重的打擊。

這項研究的準確率非常高:

To support our analysis, we created a fingerprint database comprised of 42,027 Netflix videos. Given this collection of fingerprints, we show that our system can differentiate between videos with greater than 99.99% accuracy. Moreover, when tested against 200 random 20-minute video streams, our system identified 99.5% of the videos with the majority of the identifications occurring less than two and a half minutes into the video stream.

而且他們居然是用這樣的單機分析:

null

苦啊...

英國通過法案要求 ISP 記錄使用者觀看過的網站

英國前幾天通過了最激烈的隱私侵犯法案,要求 ISP 必須記錄使用者觀看過的網站:「Britain has passed the 'most extreme surveillance law ever passed in a democracy'」:

The law forces UK internet providers to store browsing histories -- including domains visited -- for one year, in case of police investigations.

不愧是 George Orwell 生前的國家,居然先實現了他的理想國... 接下來 Let's EncryptTor 的重要性就更高了。

遠傳的 DNS 改成 139.175.1.1

找資料的時候發現原來在六月底的時候換掉了:「2016/06/30 起 遠傳大寬頻(Seednet) DNS主機異動公告說明」:

感謝您對本遠傳大寬頻(Seednet)長期的支持與愛護,因DNS主機將進行異動,
DNS IP將調整為139.175.1.1,原有的DNS IP(139.175.55.244、139.175.252.16),
將於2016年06月30日不再提供對外連線服務。

這樣的話三大 ISP 都放到最好記的網段下了 (另外兩個分別是台灣固網的 61.31.1.1 與中華的 168.95.1.1)。

印度 ISP 跟 Torrent 站台合作加速下載

在「Indian ISPs Speed Up BitTorrent by ‘Peering’ With a Torrent Site」這篇講到印度的 ISP 跟 torrent 站台 TorBox 合作,加速下載的速度。

裡面提到了蠻有趣的加速技巧:

They help users to download content faster by linking them to local peers in their own network.

不知道是不是指 Local Peer Discovery (BEP-14) 的技術,如果是的話大概可以猜出作法... 這樣可以降低不少 ISP 對外頻寬的流量與成本。

CloudFlare 對 HiNet 成本的抱怨 (還有其他 ISP...)

CloudFlare 特地寫了一篇討拍文在分析對六個 ISP 的超高成本:「Bandwidth Costs Around the World」。

其他的就不講了,先看對價錢的定義:

As a benchmark, let's assume the cost of transit in Europe and North America is 10 units (per Mbps).

然後來看亞洲區以及 HiNet 的部份寫了什麼:

Two Asian locations stand out as being especially expensive: Seoul and Taipei. In these markets, with powerful incumbents (Korea Telecom and HiNet), transit costs 15x as much as in Europe or North America, or 150 units.

成本大約是 15 倍。另外說明這六個 ISP 佔了他們 50% 的頻寬成本 (以及 6% 的流量):

Today, however, there are six expensive networks (HiNet, Korea Telecom, Optus, Telecom Argentina, Telefonica, Telstra) that are more than an order of magnitude more expensive than other bandwidth providers around the globe and refuse to discuss local peering relationships. To give you a sense, these six networks represent less than 6% of the traffic but nearly 50% of our bandwidth costs.

為什麼有種濃濃的既視感 XDDD

一張網卡上面從 ISP 取得多個 DHCP IP 或是取得多個 PPPoE IP

昨天跟朋友吃飯的時候談到這個問題,回家幫他找一下解法。主要的限制是各 ISP 對單一 mac address 限制分配一個 IP,所以問題只在於要怎麼在 Linux 下的單一網卡建立多個不同的 mac address,後續的就好做了。

主要是參考 Macvlan and IPvlan basics 這篇文章的指令測試。

首先是建立 fakevlan1 (卡號系統會隨機產生),然後啟用他,最後呼叫 dhclient 請 ISP 提供 IP:

# ip link add fakevlan1 link eth1 type macvlan mode bridge
# ifconfig fakevlan1 up
# dhclient fakevlan1

這邊細部沒有處理 routing 的問題 (dhclient 會收到 ISP 提供的各種 routing 與 dns 資訊),看起來可以透過「Can I prevent a default route being added when bringing up an interface?」這邊的方法處理掉。

PPPoE 的方法我相信也類似啦... (手邊沒有 HiNet 線路可以測試 XD)

Amazon CloudFront 加拿大機房 (然後順便提一下 CloudFlare...)

Amazon CloudFront 增加了加拿大的點:「Amazon CloudFront Expands to Canada」,一次開了兩個機房:

I am happy to announce that we are adding CloudFront edge locations in Toronto and Montreal in order to better serve our users in the region, bringing the global count up to 59 (full list).

價錢跟美國一樣,但是流量是分開計算累計值的:

總算記得加拿大這個國家了 XDDD

另外一個是昨天發現 CloudFlare台灣固網 (以及台灣大哥大用戶) 已經直連了,看起來是六月底的時候就通了,只是一直沒注意到:

這樣台灣主要的 ISP 對 CloudFlare 都有直連了...

利用 CloudFlare 的 reCAPTCHA 反向找出真正的 Tor 使用者

Cryptome 這邊看到可能可以被拿來用的技巧:「Cloudflare reCAPTCHA De-anonymizes Tor Users」。

Tor 使用者連到 CloudFlare 上時,常常會出現 reCAPTCHA 的提示,要求你驗證,而這個驗證過程的 traffic pattern 太龐大而且很明顯,當情治單位同時可以監控 CloudFlare 的上游 (像是「Airtel is sniffing and censoring CloudFlare’s traffic in India and CloudFlare doesn’t even know it.」這篇提到的問題) 或是監控 Tor 的 exit node 的上游,再加上同時監測使用者可能的 ISP,就可以對照湊出使用者:

Each click on one of the images in the puzzle generates a total of about 50 packets between Tor user's computer and the Cloudflare's server (about half are requests and half are real-time responses from the server.) All this happens in less than a second, so eventual jitter introduced in onion mixing is immaterial. The packet group has predictable sizes and patterns, so all the adversary has to do is note the easily detectable signature of the "image click" event, and correlate it with the same on the Cloudflare side. Again, no decryption required.

短短的一秒鐘內會產生 50 個封包,而且 pattern 很清楚...

Archives