Google Chrome 要推動預設使用 HTTPS 連線

Google Chrome 從 90 版要把 https:// 變成網址輸入時的預設值:「A safer default for navigation: HTTPS」。Hacker News 上的「Chrome’s address bar will use https:// by default (chromium.org)」也可以看一下。

也就是說,沒有輸入 schema 的網址,預設會用 https:// 方式連線,以往這點需要透過 HTTPS Everywhere 這種套件,然後開啟「Encrypt All Sites Eligible」這樣的參數,像是這樣:

這樣會再推一把...

Amazon (AWS) 手上有全世界 3% 的 IPv4 可用位置?

看到「Amazon owns more than $2B worth of IPV4 addresses」這篇提到,算了一下才發現 Amazon (AWS) 手上有超多 IPv4 位置...

As of today, December 11, 2020 AWS self reports owning 109,847,486 IPV4 addresses - at a price of $20 this is almost $2.2B and at $30 it’s almost $3.3B.

這邊要算可用的 IPv4 位置不能直接拿 2^32 算,需要扣掉特殊用途的...

最大的兩組是 Multicast 與保留不用的部份,分別是 224.0.0.0/4240.0.0.0/4,這邊有 32 個 Class A 的空間,再扣掉 0.0.0.0/810.0.0.0/8127.0.0.0/8 這三個 Class A 的空間,然後其他零星小的算一算再全部抓起來扣一扣,Amazon (AWS) 手上掛了將近全世界 3% 的 IPv4 可用位置,相當驚人...

Google 的好像沒有完整的,只有 Google 自家服務的,沒有包括 GCP...

Cloudflare 與 ISP 合作推出 ODoH 加強隱私,然後 Google 想要看 HTTPS 流量

Cloudflare 推出了 ODoH (目前是 IETF 的 draft:「Oblivious DNS Over HTTPS」):「Improving DNS Privacy with Oblivious DoH in 1.1.1.1」,在 Hacker News 上面也有討論:「 Improving DNS Privacy with Oblivious DoH (cloudflare.com)

基本上就是 DNS over HTTPS 在上面架一層 Proxy,但這層 Proxy 不能是 Cloudflare 自己:

這樣一來 Cloudflare 知道 IP address 的機會就會比較小,藉以達到要求,先前要達到這樣的效果必須透過 ISP 提供的 HTTP/HTTPS Proxy (像是已經淘汰的 proxy.hinet.net:「HiNet 宣佈年底關閉 Proxy 服務」),或是透過 Tor,但 Tor 的效能會讓 query 速度慢不少。這次的這個服務的確是好不少...

技術上來說,當 Cloudflare 與 ISP 都把所有的 packet 記錄下來後,兩邊合作還是可以取得原始的 IP 資訊,以這個例子來說,你跟總部在香港的 PCCW 集團合作,看起來就不怎麼吸引人啊...

不過隔壁棚的 Google 則是讓人吐血中,打算用 Prefetch 名義看到你的 HTTPS 流量:「Continuing our journey to bring instant experiences to the whole web」,這樣一來,就有不少的機會 Google 可以分析出來使用者在看什麼 Netflix 影片了 (要看 Prefetch 到什麼程度,2017 年的時候做出來有 99.99% 的準確度):「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」。

來坐著等看 Google 這邊的好戲...

升級跳板機

算是做個記錄...

差不多是 2014 年的時候,因為 xDSL 網路的頻寬拉起來比較夠用了,加上當時發生一些事情,而且 HiNetPPPoE 可以申請發一個固定 IP (即「非固固 IP」),所以就用這個功能架了一台小的 server,這樣一來就有一台小的 server 可以用,另外很多 firewall 之類的操作就方便很多。

當時買的機子是 GigabyteGB-XM12-3227Intel i3-3227 + 4GB RAM + 128GB mSATA SSD:

幾年前 CPU 風扇掛過一次,去淘寶上挖了一顆回來後又可以繼續用。

不過後來在上面跑的東西愈來愈多,加上現在的軟體開發愈來愈吃各種資源 (就算只是 command line 環境),i3-3227 的 CPU Benchmarks 跑分也才 1274,記憶體也只裝了 4GB,跑起來還是愈來愈吃力... 大概在年初的時候就有打算要換,直到看到了這個機殼的影片:

我買了一個機殼回來 (還找到 $350 含運的店家),在客廳裝了一台 Intel J1900 + 8GB RAM 的機器接電視用 (不過這又是另外一個故事了),對這款機殼還算滿意,就再去下了一顆回來...

接下來就是湊其他的零件了,既然這次要拿來當半個開發機用,上面的等級要好一點,但又不希望太吃電 (畢竟是一直開著的機器),所以就找了一顆二手的 Intel i3-8100T (35W,CPU Benchmarks 分數 5319),然後在 PChome 24h 上面找了張 H310 的主機板,一個全新的 350W 電源供應器,以及 2*16GB RAM + 500GB SATA SSD。風扇的話是之前 Intel E3-1230 v3 留下來的風扇 (現在上面是掛水冷),扣具的位置是相同的 (LGA115x),就直接拿來用了。

弄好後裝個 Ubuntu 20.04,然後在只有兩顆風扇的環境下 (電源供應器的風扇與 CPU 風扇),CPU idle 只有 35 度上下,壓測也只有 55 度上下,本來還在糾結後方要不要還是裝個 8cm 系統風扇,後來決定還是放一顆上去好了,用負壓的方式把熱帶出來。

如果之後真的遇到灰塵太多的問題,再考慮用先前在「無風扇系統的 CPU 散熱片」提到的方案來換:

接下來就是搭車把機器帶老家裝,就順便被老人家餵食:

回家升級跳板機,然後就被餵食了...

換完後當然如同預期的速度快不少,接下來應該會考慮把線路升級到 300M/100M (現在只有 100M/40M),不過看起來 IP 一定會變,就比較麻煩了,之後再看看機會...

抓出正在使用的 DNS Server

Hacker News 上看到的方式:「Which DNS」,另外在「Show HN: Which DNS servers are you pointing to? (nameserve.rs)」這邊也有一些討論。

這個方式是去抓 DNS server 對外的 IP,像 HiNet168.95.1.1 這種 DNS server 後面都有一堆 resolver,這個方式可以知道出去的 IP 是哪個,可以幫助分析 routing 之類的問題...

記得 Akamai 有類似的服務,不過查了一下沒找到之前有印象的那個,反倒是查到另外一組可以用的:「Introducing a New whoami Tool for DNS Resolver Information」。

Google Chrome 的顯示完整 URL 的方式又改了...

剛剛更新 Google Chrome 後發現 address bar 又被動手腳了 (我是 beta channel 的版本),在網址列上的 Protocol (Scheme) 與 www subdomain 不見了,而本來裝 Suspicious Site Reporter 可以讓 URL bar 恢復的方式也失效了。

翻了一下老問題「Chrome address bar no longer shows protocol or www subdomain」,裡面有提到新的解法 (他寫的當下) 是「The current solution in Chrome 83+」這個,直接在網址列上選右鍵,可以看到 Always show full URLs 這個選項,這是整個 Google Chrome 的選項,而非單一站台選項,選下去後就生效了:

而本來的 Suspicious Site Reporter 也可以拔掉了 (沒有用處了)。

Cloudflare 推出了 BYOIP 的服務

Cloudflare 推出了 BYOIP 的服務,用客戶的 IP address 放 routing 出去:「Bringing Your Own IPs to Cloudflare (BYOIP)」。

照敘述上看起來應該是 anycast,不過這邊沒明講:

When you BYOIP with Cloudflare, this means we announce your IP space in over 200 cities around the world and tie your IP prefix to the service (or services!) of your choosing.

裡面沒有提到 IPv4 或是 IPv6,在 https://developers.cloudflare.com/byoip/ 這邊看起來也沒提到,以 Cloudflare 的技術架構,應該是都支援?

用自己的 IP 的好處,一個明顯的方向就是 firewall 會好設不少,另外如果需要服務中國或是其他管制地區,比較不會因為 IP space 混用誤殺受到影響?

前陣子爆出「不保留記錄的 VPN」保留了大量的客戶與連線資訊

前陣子 comparitech 發現了宣稱不保留記錄的 VPN 廠商 UFO VPNElasticsearch 伺服器沒有設定好,造成外部可以直接存取,然後發現裡面包含了大量記錄:「“Zero logs” VPN exposes millions of logs including user passwords, claims data is anonymous」,這篇文章的小標把重點先說完了:

UFO VPN exposed millions of log files about users of its service, including their account passwords and IP addresses, despite claiming that it keeps no logs.

目前還是建議在有能力的情況下都自己架,一般常見就是用 OpenVPN,但設定上會比較麻煩一些。如果要方便的話可以用 Openconnect VPN Server (ocserv) 架 server,然後在手機上可以直接用 Cisco 官方提供的用戶端接,像是 Cisco AnyConnect (iOS) 與 AnyConnect (Android),在桌機上一般則是用 OpenConnect 自家的軟體連接。

家裡有 HiNet 的網路的話,可以申請一個固定 IP (透過 PPPoE 的),然後用一台 Raspberry Pi 之類的設備架設。

倒不是說這些 VPN 廠商的服務不能用,只是你必須認知這些 VPN 是拿來繞過地區限制的,而不是為了安全性或是隱私,所以如果是人在外面使用網路,想要避免被商家或是外面的 ISP 看到流量內容,透過自己架設的 VPN 應該會好不少。

阻擋網站透過瀏覽器掃 localhost

五月的時候,DuckDuckGoCharlie Belmer 發了一篇關於網站透過瀏覽器掃 localhost 的文章,引起了不少重視:「Why is This Website Port Scanning me?」。

這個月陸陸續續看到一些反制方式了,比較簡單的是透過像 uBlock Origin 這類可以擋特定 url 的方式,像是 EasyPrivacy 裡面把一些大站台的 javascript script 擋下來:「uBlock Origin ad blocker now blocks port scans on most sites」。

在同一篇文章的 comment 處也有人提到 uBlock Origin 可以做的更廣泛:「Block access to 127.0.0.1/localhost and LAN address from the internet #4318」,裡面有人已經整理好丟出來了:「lan-block.txt」,看起來也可以擋一些...

要擋得比較完整的還得考慮 scan.example.com IN A 127.0.0.1 這種方式繞過去的情況?這可能需要用 extension 了...

架設 MTProxy 加快 Telegram 的速度

在台灣如果是透過 HiNetTelegram 是沒什麼問題 (不需要翻牆),不過連結的 preview 以及圖片影片讀取的速度實在很慢,試著在 GCP (彰濱機房) 跟 Vultr (東京機房) 上架 Proxy 測試看看,發現速度都改善很多...

這邊用的是官方提供的 MTProxy,我把安裝的懶人包放在自己的 wiki 上了:「MTProxy」,在 AWS 或是 GCP 上安裝時,因為網卡拿到的是 Private IP 而非對外的 Public IP,需要指定 --nat-info 告訴 MTProxy 要針對協定裡面的 IP address 另外處理。

跑一陣子再來看看有什麼可以調整的...