Ubuntu 下雙螢幕進入省電模式後再起不能的問題

Update:後來還是有狀況,這篇的方法沒有完全解決... 等找出解法後再回來更新。

前陣子把家裡的 Ubuntu 桌機多塞了一顆 Dell 的 P2317H,打直拿來看程式碼,大致上是沒什麼問題,不過螢幕進入省電模式後就再起不能... (NVIDIA 的顯卡,一顆接 DisplayPort,另外一顆接 HDMI)

後來找到這一串討論:「DP1.2 connected monitor cannot be turned on again with DPMS」。

這串討論裡官方的人有給不少方式,後來試到第二頁的發法,是在 /etc/modprobe.d/disable-nouveau.conf 裡設定一些參數,重開機後就解決了:

blacklist nouveau
options nouveau modeset=0

看起來是 nouveau 的關係,現在總算是可以比較正常的使用了... (還有不少眉眉角角的地方要再找方法解...)

iOS 阻擋 WoSign 憑證

mozilla.dev.security.policy 上看到有人行動了:「Apple's response to the WoSign incidents」。這使得 Apple 成為 WoSign 事件中第一個行動的單位。

Apple 這次先把 WoSign 放入 iOS 憑證清單的黑名單公告在這邊:「Blocking Trust for WoSign CA Free SSL Certificate G2」。

WoSign 在 iOS 產品線中是靠 StartComComodo 的交叉簽章,所以如果 Apple 只想擋 WoSign 憑證的話,必須以阻擋 Intermediate CA 的方式避開:

Although no WoSign root is in the list of Apple trusted roots, this intermediate CA used cross-signed certificate relationships with StartCom and Comodo to establish trust on Apple products.

不過為了降低對 user 的影響,這次的阻擋會有例外。當 CT log server 在 2016-09-19 前收到的 SSL certificate 還是會信任 (要注意的重點是,這邊的日期不是簽發,是送到 CT log server 上):

To avoid disruption to existing WoSign certificate holders and to allow their transition to trusted roots, Apple products will trust individual existing certificates issued from this intermediate CA and published to public Certificate Transparency log servers by 2016-09-19.

接下來會開始更深入的調查 WoSign 與 StartCom:

As the investigation progresses, we will take further action on WoSign/StartCom trust anchors in Apple products as needed to protect users.

另外本來的棚子裡,Qihoo 360 與 StartCom 正式提出要求在 2016/10/04 與 Mozilla 的人面對面討論 (在英國):「WoSign and StartCom: next steps」:

Following the publication of the recent investigative report, representatives of Qihoo 360 and StartCom have requested a face-to-face meeting with Mozilla. We have accepted, and that meeting will take place next Tuesday in London.

繼續來看進度... 下個禮拜應該會有更多的資料出來。

SSL Blacklist

現在新的 malware 或是 botnet 為了避免被 IDS/IPS 之類的設備抓包,大多都使用 SSL 連線傳遞資料在技術上躲避偵測。

而為了因應新型態的 malware 與 botnet,就有人想到去建立 SSL certificate SHA-1 的資料庫來偵測:「SSL Black List Aims to Publicize Certificates Associated With Malware」,也就是「SSL Blacklist」這個服務。

不過這應該會再演變成透過 malware 與 botnet 改用 PKI 架構而變成要偵測 CA 簽名的部份?還可以想出一些變形...

歷史上的爆炸記錄?

在「a brief history of one line fixes」列出了許多經典的問題...

裡面最有印象的還是 2008 年 Debian OpenSSL 問題,也因為這個問題影響太嚴重,後來預設會安裝 openssl-blacklist 這個套件,在連線時檢查是不是有問題的 key...

然後 Android memset() 那個很精彩啊 XDDDDDDDDDDD

AWS SES 總算可以「手動」把 Blacklist 拿掉...

AWS SESAWS 服務裡面設計問題超多的一個服務,在推出兩年後 (2011 年一月) 總算是提供把 Blacklist 拿掉的功能...

原始的設計是,只要對方位置不存在,這個 e-mail 就會進黑名單 14 天,無法刪除。而一次寄給多人的信件,只要有一個人是黑名單就會全部擋掉 XDDD

再來是這個 14 天限制,並不是「第一次被擋掉後 14 天」,而是「最後一次失敗後 14 天」,而「最後一次失敗」包括 retry... =_=

弄到最後反而是自己架 mail server 比較快,針對問題很多的 @yahoo.com 系列與 @*.hinet.net 透過 AWS SES 寄就好...