幹壞事是進步最大的原動力
Update：Google 的憑證也被 revoke 了，另外 Facebook 的恢復內部使用的部分了：「Apple blocks Google from running its internal iOS apps」。
昨天是 Facebook 被發現在 iOS 上使用 Enterprise Certificate 取得使用者的行為記錄 (參考「Facebook 花錢向使用者購買他們的行為記錄」)，後來 Apple 撤銷了這張 Enterprise Certificate (因為不符合 Enterprise Certificate 的使用條款)，並且使得 Facebook 內部符合 Enterprise Certificate 的應用程式都失效。
而 Google 也被抓出幹同樣的事情，叫做 Screenwise Meter：「Google will stop peddling a data collector through Apple’s back door」。
目前 Google 自己已經下架，但這表示已經有的 spyware 還是會生效，就看 Apple 要不要拔了...
這則從 Nuzzel 上看到的，國外討論得很凶：「Facebook pays teens to install VPN that spies on them」。
Facebook 付錢給使用者，要他們安裝 VPN (以及 Root CA，看起來是為了聽 HTTPS 內容)，然後從上面蒐集資料，這本身就不是什麼好聽的行為了，但更嚴重的問題在於包括了未成年人：
Since 2016, Facebook has been paying users ages 13 to 35 up to $20 per month plus referral fees to sell their privacy by installing the iOS or Android “Facebook Research” app. Facebook even asked users to screenshot their Amazon order history page. The program is administered through beta testing services Applause, BetaBound and uTest to cloak Facebook’s involvement, and is referred to in some documentation as “Project Atlas” — a fitting name for Facebook’s effort to map new trends and rivals around the globe.
這個計畫在 iOS 平台下架了，但 Android 平台看起來還是會繼續：
[Update 11:20pm PT: Facebook now tells TechCrunch it will shut down the iOS version of its Research app in the wake of our report. The rest of this article has been updated to reflect this development.]
Facebook’s Research program will continue to run on Android. We’re still awaiting comment from Apple on whether Facebook officially violated its policy and if it asked Facebook to stop the program. As was the case with Facebook removing Onavo Protect from the App Store last year, Facebook may have been privately told by Apple to voluntarily remove it.
未成年人部份應該會是重點，拉板凳出來看...
在 trimstray/the-practical-linux-hardening-guide 這邊看到保護 Linux 系統的方式，列成清單：
This guide details the planning and the tools involved in creating a secure Linux production systems - work in progress.
從實體的開始講，然後 BIOS，再來是 OS 層，接下來是基本服務，再來到應用程式，一般人做的到的該涵蓋的都有涵蓋到了...
不過在一般情況下要全部都完成不太可能 (通常是人太懶)，但可以當清單掃一輪挑著做，加強系統的安全性...
前幾天寫的「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)，所以應該還是會繼續爭吵吧...
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)。這點倒是頗有趣...
居然有個獨立的網站在說明：「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 機制上提供。
剛剛才注意到 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，列出了不少商家：「Comparing secondary authoritative DNS service providers」。
這種通常是已經有習慣的管理模式 (像是用 Git 管 zone file 已經習慣了)，不方便或是不想要轉移到雲服務上面 (像是「
StackOverflow 對於多 DNS 商的同步方式...」或是「
GitHub 也自己搞了一套管理多家 DNS 的程式...」這樣的方式)，所以想要找 secondary DNS service 提供服務。
雖然作者主要是針對 DNSSEC 相關的情境在評估，但也因此列了不少 provider 在上面，之後有需要用到的時候可以研究看看...
Google Public DNS (也就是 8.8.8.8 與 8.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 可以取得的資料。