台灣 5G 網路偵測「分享」的方式

Twitter 上看到 zmx 分享的 tweet:

原始文章在「[教學]讓5G網路分享不被限速 —— 更改TTL」這邊,目前已經自刪,但已經有人在 Internet Archive 上面先 archive 起來了:「[教學]讓5G網路分享不被限速 —— 更改TTL」。

技術上是偵測 TTL 的數字來決定要怎麼擋 (一般機器的預設是 64),而 TTL 在過 router (像是分享器) 時會自動減一,所以可以用這點來偵測。另外找了一下資料,看起來這個方式應該很久前就有在傳:「[問題] 5G熱點分享問題 (USB分享算不算?) (2020)」、「[問題] 5G熱點分享限制有可能破解嗎? (2021)」。

另外 Nahcoroyk 有提到要關掉 IPv6:

如果你5G是C/F/T家的記得把電腦的ipv6關掉,因為ipv6還是可以分辨你是不是有做分享,剛實測某家ipv6下載一樣會扣 但ipv4就列入行動網路了XD (我用iphone13pro分享給電腦)

在猜之前有些手機不限流,但分享只有 1GB 的海外 SIM 卡應該也是類似的方法在偵測?之後能出國的時候可以研究看看...

從 EC2 的價格表上發現 AWS 多了好多區...

剛剛翻 Amazon EC2 的價格頁面,發現多了好多有趣的區域,多了不少 ISP-based 的區域,像是 VerizonKDDI 以及 SKT

翻了一下好像沒有講過,但都已經放上價格頁了,應該是晚點就會放消息?

把 b-mobile 的おかわりSIM 換成 190PadSIM 了

因為有養一個日本號碼的需求 (收簡訊),加上去日本時希望可以有個當地的上網方案,可以在還沒到民宿時使用 (不少民宿會提供分享器讓你帶出去),所以當初辦了 b-mobile 的「b-mobile おかわりSIM 5段階定額」這個方案:第一次的設定費是 JPY¥3000,之後每個月基本費用是 JPY¥630,方案包含了每個月 1GB 的流量,可以付費使用到 5GB 的流量 (額外多收 JPY¥250/GB),用完後限速 200kbps。

一開始的速度不太行,就當作養門號用:「b-mobile 的おかわり的速度」,但後來幾次去日本發現好不少 (Twitch 的 720p 也還看的動),就當作是去日本的網路方案之一了 (會準備備案在需要的時候啟用)。這個方案後來停止申請了,但原來的申請者還是可以繼續用。

後來推出的方案是「b-mobile S 190PadSIM」,從名稱可以看出是設計給平板用的。一樣是 JPY¥3000 的設定費用,但之後每個月的基本費用降到 JPY¥190,不過這個方案只包括了 100MB 的流量,但因為是設計給 Pad 使用者,所以方案設計可以付費使用到 15GB 的流量 (分階段是 JPY¥480/1GB,JPY¥850/3GB,JPY¥1450/6GB,JPY¥2190/10GB 與 JPY¥3280/15GB)。

這個方案就流量單價來說比おかわりSIM 便宜 (差不多是 JPY¥200/GB 上下),不過對於流量在 1GB~2GB 與 3GB~5GB 的部份會變得比較貴,所以切過去也不一定比較好。但可以看到因為基本費用變低不少,對於養門號的人來說省了不少...

先前以為需要重新辦一張卡,就一直沒有動力處理 (設定費用與弄回台灣的成本),直到登入到 b-mobile 後台後發現可以直接改服務就改過去了,要注意的是改完後下個 cycle 才會是新的方案。

AWS Direct Connect 在台北又增加可以接的機房了...

先前 AWS Direct Connect 在今年二月的時候公佈了台北第一個開放的接點,是方的麗源機房 (Chief Telecom LY, Taipei, Taiwan,參考「AWS 公開了在台北的 Direct Connect 接口」),現在公佈第二個點了:「New AWS Direct Connect locations in Paris and Taipei」。

第二個點在中華電信的機房 (Chunghwa Telecom, Taipei, Taiwan),但這樣只這樣標,不知道實際上是哪個,會不會是愛國東路的國分機房?那邊有不少非中華電信網路的客戶,只是租那邊的機房在用...

不過有需求的可以問一下 AWS,應該就會有答案了,畢竟總是得讓客戶知道要接到哪邊...

SSL Certificate 的認證方式限縮

在「Ballot 218 - Remove validation methods 1 and 5 - CAB Forum」看到「Ballot 218: Remove validation methods #1 and #5」這則議案以 78% 的同意票通過,限縮 SSL Certificate 的認證方式。眼睛瞄到中華電信投下反對票:

14 Yes votes: CFCA, Cisco, Comodo CA, D-TRUST, DigiCert, GDCA, GlobalSign, GoDaddy, Izenpe, Let’s Encrypt, Logius PKIoverheid, SSL.com, TrustCor, Trustwave

4 No votes: Buypass, Chunghwa Telecom, Entrust Datacard, SwissSign

4 Abstain: Actalis, Disig, HARICA, OATI

78% of voting CAs voted in favor

找了一下在 BR (Baseline Requirements) 的 3.2.2.4.1 與 3.2.2.4.5,其中前者是透過註冊商認證:

3.2.2.4.1 Validating the Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar.

後者是透過文件認證:

3.2.2.4.5 Domain Authorization Document

Confirming the Applicant's control over the FQDN by relying upon the attestation to the authority of the Applicant to request a Certificate contained in a Domain Authorization Document.

在想投下反對的原因,會不會是因為中華自己的 domain 應該都是透過後者方式發的?透過內部公文系統...

AWS 公開了在台北的 Direct Connect 接口

也是個很久前就聽到傳言的消息... AWS 剛剛公佈了在台北的 Direct Connect 接口,用戶可以在台北內租用線路進機房就連上 Direct Connect:「New AWS Direct Connect sites land in Paris and Taipei」。

AWS Direct Connect also launched its first site in Taiwan at Chief Telecom LY, Taipei. In the Management Console, Taipei is located in the Asia Pacific (Tokyo) Region. With global access enabled for AWS Direct Connect, these sites can reach AWS resources in any global AWS region using global public VIFs and Direct Connect Gateway.

以往需要透過像 GCX 這樣的公司租用國際頻寬,再從 GCX 在台北的機房拉到自家機房 (通常是市內專線),現在只需要在台北對接的這段就可以了。

台北的接點在 AWS 上寫的是 Chief Telecom LY, Taipei, Taiwan,查了一下是是方電訊的「是方麗源大樓 (台北市內湖區陽光街250號)」,也就是之前有發生過火災而大斷線的那棟。對接的 AWS Home Region 是 Asia Pacific (Tokyo),所以使用 ap-northeast-1 的人可以規劃...

美國的電信商提供 API,讓第三方透過 IP 就可以知道你的真實身份

前陣子的報料,美國的電信商提供 API 給第三方,讓第三方可以用 IP address 查出你的真實身份:「Want to see something crazy? Open this link on your phone with WiFi turned off.」,像是這樣:

These services are using your mobile phone’s IP address to look up your phone number, your billing information and possibly your phone’s current location as provided by cell phone towers (no GPS or phone location services required).

目前所有的網站都已經被下架了,但可以從當時的截圖看到有多少資訊。AT&T 的新聞稿在「AT&T Helps Businesses Improve Mobile Transaction Security with New Mobile Identity API Toolkit」,新聞稿沒被下掉我猜可能是因為上市公司受法令限制的關係?

這其實是一個警示,說明了美國的電信商開始把大家一直認為極為隱私的資料賣給第三方:

But what these services show us is even more alarming: US telcos appear to be selling direct, non-anonymized, real-time access to consumer telephone data to third party services — not just federal law enforcement officials — who are then selling access to that data.

而且作者在 GitHub 上看到有程式碼針對韓國電信商提供的 API 呼叫,所以韓國也有類似服務:

I found what looks like a third-party API implementation for a Korean Danal API on GitHub. The author wrote the code for South Korean telcos, so there may be differences with US carriers. The query parameters in the HTTP requests are similar to what I remember seeing in the Danal demo. It’s unclear from my reading of the code whether or not this API requires operation inside of e.g. a Danal Inc. hosted-iframe for identity confirmation. The diagram on page 4 of this documentation describing the Korean “Danal Pay” service appears to show the client interacting with the customer’s servers only.

台灣呢,嘿嘿...

伊朗透過 BGP 管制網路的手段影響其他國家網路...

Dyn (之前被 DDoS 打爆,過一陣子被 Oracle 買去的那個 Dyn) 的這篇「Iran Leaks Censorship via BGP Hijacks」講到他們偵測到伊朗透過 BGP hijack 管制網站的問題。

前陣子伊朗透過 private ASN 放了 99.192.226.0/24 出來,影響到其他國家:

Last week, Iranian state telecom announced a BGP hijack of address space (99.192.226.0/24) hosting numerous pornographic websites.

由於這段 IP address 在 internet 上是以 99.192.128.0/17 在放,就因為 /24 優先權比較高而被蓋過去影響到全世界...

然後過了幾天,開始攻擊蘋果的 iTunes 服務,不過這次是以 /32 放出來。由於大多數收的最小單位是 /24,這次的影響沒有上次大:

In addition, TIC announced BGP hijacks for 20 individual IPs associated with Apple’s iTunes service. These too were carried by Omantel to the outside world, albeit with a smaller footprint due to the fact that BGP routes for /32’s typically don’t propagate very far.

這看得出來 routing 在 internet 上還是非常脆弱...

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