B612 字型

B 612 是小王子裡的星球,被拿來引用當作字型名稱了:「B612 – The font family」。

這是空中巴士設計給飛機上的系統用的,所以包括了「舒服」(長時間) 與「易讀」,算是某種以「安全」為考量的字體?

In 2010, Airbus initiated a research collaboration with ENAC and Université de Toulouse III on a prospective study to define and validate an “Aeronautical Font”: the challenge was to improve the display of information on the cockpit screens, in particular in terms of legibility and comfort of reading, and to optimize the overall homogeneity of the cockpit.

然後包括了 regular 與 monospace 兩種:

Git 的記錄已經 open source 一陣子了,拿來當 sans-serif 用一段時間看看好了...

apt-get 的安全性漏洞

前幾天寫的「APT 不使用 HTTPS 的說明」的當下就已經有看到在講這個漏洞,但沒讀完就一直放著沒寫:「Remote Code Execution in apt/apt-get」。

漏洞出在實作上的問題,對於 HTTP 重導的程式碼沒有處理好外部字串,在還沒修正的機器上用這個指令關閉 redirect,避免在修正的過程反而被 RCE 打進去:

sudo apt update -o Acquire::http::AllowRedirect=false
sudo apt upgrade -o Acquire::http::AllowRedirect=false

但也不是 HTTPS 就能避免這個問題,因為 HTTPS 連線用的程式碼又是另外一份,裡面不知道有沒有問題 (像是之前經典的 Heartbleed),所以應該還是會繼續爭吵吧...

NLB 也可以幫忙處理 TLS 了...

AWS 推出的新功能,讓 NLB (network load balancer) 可以直接做完 SSL offload:「New – TLS Termination for Network Load Balancers」。

而且 NLB 可以保留 source ip,不需要在 web server 上處理特殊的 header (像是 X-Forwarded-For 這類的 HTTP header)。這點倒是頗有趣...

APT 不使用 HTTPS 的說明

居然有個獨立的網站在說明:「Why does APT not use HTTPS?」。主要是 HTTPS 沒有增加太多保護,但會使得維護的複雜度變高很多。

首先是被竄改的問題,APT 本身就有簽名機制 (參考「SecureApt」),即使 mirror site 被打下來也無法成功竄改內容,反而比起單純的 HTTPS 保護還好。

而對於隱私問題,由於內容是可以公開取得的,這代表可以看封包的大小與流動順序猜測是哪些 package 被下載 (也就是類似「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」這篇提到的方法),加上 APT 這邊還多了時間性的資訊 最近被更新的軟體被下載的機率比較高),所以隱私的保護上其實有限。

而針對攻擊者刻意提供舊版的問題 (某種形式的 replay attack),APT 降低風險的解法是把時間簽進去,當用戶端發現太久沒更新時,就當作過期失效而提出警告。

就以上來看,把所有的 APT 伺服器都加上 HTTPS 的工程太浩大,而得到的效益太小。所以願意提供 HTTPS 的站台就提供,但主要的保護還是從本來的 SecureApt 機制上提供。

在 2019 年出的 PHP 5.6.40...

剛剛才注意到 PHP 5.6 在 2019 年還有新的版本:「PHP 5.6.40 Released」。

在「Supported Versions」可以看到 PHP 5.6 應該是在 2018 年年底就終止更新,看起來是 5.6.39 在 2018/12/06 出之後,把剩下的一包都累積起來,「原則上」後面不會有更新:

Please note that according to the PHP version support timelines, PHP 5.6.40 is the last scheduled release of PHP 5.6 branch. There may be additional release if we discover important security issues that warrant it, otherwise this release will be the final one in the PHP 5.6 branch.

不過看起來官方的態度是「儘量幫」,如果有太嚴重的漏洞還是會補... :o

前員工監控公司網路的抓包過程...

看到「The curious case of the Raspberry Pi in the network closet」這篇有趣的過程,先從開頭與最後面開始看。首先是他們在辦公室裡面發現有個奇怪的設備:

追查後發現不是公司的人放的,最後發現是前員工放的,後來轉給法務部門處理了:

I checked the DNS logs and found the exact date and time when the Pi was first seen in the network. I checked the RADIUS logs to see which employee was at the premises at that time and I saw multiple error messages that a deactivated account tried to connect to wifi.

That deactivated account belongs to an ex employee who (for some reason) made a deal with management that he could still have a key for a few months until he moved all his stuff out of the building (don't ask..).

中間的過程還蠻有趣的,包括研究是什麼擴充卡 (以及用途),然後從 SD card 上面挖資料,配合 Google 找線索,還有透過 WiGLE 定位,以及透過內部系統交叉比對,最後找到兇手...

然後發現是離職員工以搬東西當作理由,讓他在離職後還有辦公室鑰匙而導致的 XDDD

Secondary DNS Service

看到有人想要找個 secondary DNS service,列出了不少商家:「Comparing secondary authoritative DNS service providers」。

這種通常是已經有習慣的管理模式 (像是用 Git 管 zone file 已經習慣了),不方便或是不想要轉移到雲服務上面 (像是「
StackOverflow 對於多 DNS 商的同步方式...」或是「
GitHub 也自己搞了一套管理多家 DNS 的程式...」這樣的方式),所以想要找 secondary DNS service 提供服務。

雖然作者主要是針對 DNSSEC 相關的情境在評估,但也因此列了不少 provider 在上面,之後有需要用到的時候可以研究看看...

Google Public DNS 也提供 DNS over TLS 服務

Google Public DNS (也就是 8.8.8.88.8.4.4) 也提供 DNS over TLS 了:「Google Public DNS now supports DNS-over-TLS」。

DNS over TLS 可以保護使用者端到 DNS Resolver 端的傳輸過程,包括了安全性與隱私都有幫助 (降低 ISP 從中可以做的事情)。

不過應該還是會繼續用 Cloudflare 提供的 1.1.1.1,latency 低一些 (也快一些) 而且降低 Google 可以取得的資料。

幫你在本機產生 localhost 的 SSL Certificate

mkcert 這個工具可以產生出讓系統 (包括瀏覽器) 信任的 https://localhost/:「mkcert: valid HTTPS certificates for localhost」。

先建立 CA 的 root key 與 root certificate,然後把 root certificate 塞到系統與各軟體的信任清單內,再產生 localhost 的 key 與 certificate 出來給前面的 CA root key 簽名。把這些事情包裝起來就是 mkcert 了。

拿來開發軟體時比較方便一點,HSTS 的程式碼就可以全環境共用了...