FreeBSD & pfSense 上的 WireGuard 問題

FreeBSDpfSense 上的 WireGuard 實做問題前幾天被 Ars 的人整理出來:「Buffer overruns, license violations, and bad code: FreeBSD 13’s close call」,文章有點長度,但整個劇情有種在看八點檔的感覺... 在 Hacker News 上的「Buffer overruns, license violations, and bad code: FreeBSD 13’s close call (arstechnica.com)」與後續的「In-kernel WireGuard is on its way to FreeBSD and the pfSense router (arstechnica.com)」都值得翻翻。

目前 FreeBSD 與 pfSense 都已經把現有的 WireGuard 實做拿掉,主要原因是實做本身的品質很差 (以及安全性問題),而且沒有將 WireGuard 的功能實做完整。

文章裡面有提到兩個組織面上的問題 (還有攻擊個人的部份,這邊就不提了),第一個是 FreeBSD 的 review process,看起來比較像是系統面的問題,目前還是缺乏人力。

另外一個是 Netgate 本身 (pfSense 後面的公司),本來沒有太多背景知識,但這次事件發生後跑去翻了一下資料,發現原來之前就有一些「記錄」了,像是註冊競爭對手的產品 OPNsense 沒有註冊的網域 opnsense.com,然後導去 pfSense 家的事情,最後使得 Deciso (OPNsense 後面的公司) 到 WIPO 上搶回來:「WIPO Domain Name Decision: D2017-1828」。

可以花些時間來看看替代方案...

NordVPN 綁架使用者的方式...

Hacker News Daily 上看到「NordVpn disables features when you turn off auto-renew」這個,這也太厲害了:

NordVPN 設計成只要關掉 auto-renewal 就直接拔掉一些功能,一臉 WTF...

Hacker News 的「NordVPN disables features when you turn off auto-renew (reddit.com)」看到這段提出來的論點蠻有趣的,當作一個參考觀點:

By now these VPN providers are like toothpaste, diapers or soft drinks: completely undifferentiated between competitors, and so only able to maintain their market share by spending loads on marketing. Of course the company with most egregious dark patterns and aggressive churn dampening wins.

Thankfully a tube of toothpaste doesn't allow implementing dark patterns like this... yet.

AWS Site-to-Site VPN 支援 AES-GCM 了

AWS 更新了 Site-to-Site VPN:「AWS Site-to-Site VPN now supports additional encryption, integrity and key exchange algorithms」。

這次更新支援了一些新的演算法,其中 AES-GCM 的部份看起來是這次這波最重要的:

Encryption: AES128-GCM-16, AES256-GCM-16.
Integrity: SHA2-384, SHA2-512.
Diffie-Hellman groups: 19, 20, 21.

傳統的方式是 encryption algorithm + hash algorithm 搭配,所以就會出現各種排列組合,而不同的方式在實做上很容易出現安全問題,也就是這篇在討論的:「Should we MAC-then-encrypt or encrypt-then-MAC?」。

AEAD 試著用一包解決,對於實做的安全性好不少...

前陣子爆出「不保留記錄的 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 應該會好不少。

WireGuard 的 OpenBSD porting

在「WireGuard patchset for OpenBSD」這邊看到有人試著把 WireGuard 放入 OpenBSD 的消息。

整包 patchset 包括了 kernel 與 userland 的實做,可以在 mailing list 上「WireGuard patchset for OpenBSD」這邊可以看到,整串討論可以在「'WireGuard patchset for OpenBSD' thread - MARC」這邊看到,目前看起來還在 code review 的階段,有看到討論提到應該用 OpenBSD 內已經實做的 Chacha20-Poly1305,所以可能還會需要一些時間...

看起來慢慢的在滲進每個作業系統中,蠻有希望在幾年後成為業界標準...

WireGuard 1.0.0 的釋出

在「[ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released」這邊看到的消息,看起來 WireGuard 1.0.0 會回過頭來 backport 到幾個重要的版本:

We'll also continue to maintain our wireguard-linux-compat [2] backports repo for older kernels. On the backports front, WireGuard was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7], and we'll see where those wind up; 5.4.y is an LTS release.

包括 DebianUbuntu 的新版,以及 5.4.x 的 LTS 版本,讓使用起來更方便一些...

Avast 與 Jumpshot 販賣使用者瀏覽記錄與行為

過了一陣子了,可以整理一下資料記錄起來...

報導可以看 PCMag 的「The Cost of Avast's Free Antivirus: Companies Can Spy on Your Clicks」與 Motherboard (VICE) 的「Leaked Documents Expose the Secretive Market for Your Web Browsing Data」這兩篇,大綱先把重點列出來了,Avast 在賣使用者的瀏覽記錄與行為:

Avast is harvesting users' browser histories on the pretext that the data has been 'de-identified,' thus protecting your privacy. But the data, which is being sold to third parties, can be linked back to people's real identities, exposing every click and search they've made.

Avast 利用免費的防毒軟體,蒐集使用者的瀏覽記錄與行為,然後透過 Jumpshot 這家子公司販賣出去:

The Avast division charged with selling the data is Jumpshot, a company subsidiary that's been offering access to user traffic from 100 million devices, including PCs and phones.

算是「免費的最貴」的標準型。另外比較有趣的是「資料賣給了誰」這件事情:

Who else might have access to Jumpshot's data remains unclear. The company's website says it's worked with other brands, including IBM, Microsoft, and Google. However, Microsoft said it has no current relationship with Jumpshot. IBM, on the other hand, has "no record" of being a client of either Avast or Jumpshot. Google did not respond to a request for comment.

Microsoft 說「現在沒有關係」,IBM 說「沒有 client 的記錄」,Google 則是不回應。

然後配合解釋資料長什麼樣子,以及可以怎麼用:

For instance, a single click can theoretically look like this:

Device ID: abc123x Date: 2019/12/01 Hour Minute Second: 12:03:05 Domain: Amazon.com Product: Apple iPad Pro 10.5 - 2017 Model - 256GB, Rose Gold Behavior: Add to Cart

At first glance, the click looks harmless. You can't pin it to an exact user. That is, unless you're Amazon.com, which could easily figure out which Amazon user bought an iPad Pro at 12:03:05 on Dec. 1, 2019. Suddenly, device ID: 123abcx is a known user. And whatever else Jumpshot has on 123abcx's activity—from other e-commerce purchases to Google searches—is no longer anonymous.

所以,如果 Google 手上有這個資料,就可以交叉比對自家的記錄,然後得到使用者完整的記錄。

在消息一公開後沒多久後,Avast 就宣佈關閉 Jumpshot,感覺連被抓包後的反應動作都超流暢,一臉就是排練過:「A message from Avast CEO Ondrej Vlcek」。

看了一下,Avast 旗下還有 AVG,還有個 VPN 服務...

AWS 的 VPC 在 Routing 上的改善

在這次 re:Invent 發表會上,AWS 也宣佈了一些跟 VPC routing 有關的改善。

第一個是 AWS Transit Gateway 彼此可以互串了:「New for AWS Transit Gateway – Build Global Networks and Centralize Monitoring Using Network Manager」。

第二個是可以拿 EC2 的機器 (實際上應該是 ENI) 當作 routing 的目標:「New – VPC Ingress Routing – Simplifying Integration of Third-Party Appliances」。

不過我記得第二個好像早就可以了啊,這次不知道是簡化了什麼東西...

在 AWS 上用 pfSense 串接的細節

這邊講的是在 AWS 上想要串接不同帳號的流量 (也就是 site-to-site VPN),不使用 AWS 自己提供的串接服務,而是用 pfSense 串接。

會自己搞主要有幾個考慮:

  • 考慮到 AWS Transit Gateway 的費用,每掛一個上去就要多收一次錢,另外上面處理的流量要再收費。
  • 應用的流量不大,所以用個 t2.nano 跑也有個 100Mbps 左右的 capacity,算是夠用了。
  • 而且應用在寫的時候也考慮到斷線後的處理,加上用戶端的網路本來就不怎麼穩定,AWS Transit Gateway 的 SLA 再怎麼高,我也還是得處理斷線時的後續機制,不如就不要那麼緊張...

在設定的時候要注意的事情:

  • EC2 的 Source IP/Destination IP 檢查要關掉,這算是基本盤。
  • VPC 內的 Routing 要確認過一輪。
  • EC2 上的 Security Group 對於 pfSense 的主機得全開,因為 pfSense 會丟出不屬於他自己 IP address 的封包,也會接收不屬於自己 IP address 的封包 (透過上面提到的 routing),這些都還是會經過 Security Group 的檢查,而 Security Group 能設定的數量有限,基本上應該會全開...
  • pfSense 在設完 IPsec 後,同樣在 pfSense 上面的 firewall 需要手動加開,因為預設是關的。

其實這套作法就是在 AWS 還沒推出 Transit Gateway 前的作法,只是老方法還是很好用...

AWS Client VPN 支援 Split-tunnel

VPN 的 Split-tunnel 指的是 partial routing,也就只針對部份 IP range 走進 VPN,其餘大多數的流量還是走原來的 Internet。

這個方式的安全性通常會比 full routing 低一些,因為這個方式會使得 internet 流量有機會穿進 VPN 內 (像是透過瀏覽器),但因為這可以讓使用者避免越洋的 VPN 導致速度下降過多,算是 VPN 常用的功能。

這次 AWS Client VPN 實做了這個功能:「AWS Client VPN now adds support for Split-tunnel」。

不過 AWS Client VPN 相較於自己架設貴不少,目前知道的單位大多也都還是自己架...