幹壞事是進步最大的原動力
AWS ACM 推出了 Private CA 服務：「How to host and manage an entire private certificate infrastructure in AWS」。
以前需要 Private CA 的話，會找個地方丟 Root CA 的 key，然後有權限的人可以連到那台機器上跑 OpenSSL 指令生出對應的 SSL certificate，現在 AWS 則是利用 HSM 架構提供服務：
主要是因為 HSM 的關係，安全性會比較好... 另外也因為是 AWS 服務的關係，上面可以看到相關的記錄，相較於以前的作法安全不少。
先前提到的「所以 Google 要對 ad blocker 全面宣戰了...」，現在朝著幾個方向在發展：一個是寄託在反托拉斯法的部份，另外一個是市場的替代方案。
Firefox 算是常被提出來的替代方案，但 Firefox 的流暢度比 Chromium 差了一大截，所以目前主要的替代方案應該還是在各家使用 Chromium 核心的瀏覽器身上。
ZDNet 詢問了這些瀏覽器的人，大多數都表態會維持 webRequest 的原來運作：「Opera, Brave, Vivaldi to ignore Chrome's anti-ad-blocker changes, despite shared codebase」。
目前只剩下剛換到 Chromium 核心的 Microsoft Edge 還沒有回應 ZDNet。
先繼續看看吧...
在 Slack 上看到同事丟出來的，關於之後要推出的 iOS 13 與 macOS 10.15 會對憑證限制的項目：「Requirements for trusted certificates in iOS 13 and macOS 10.15」。
主要是把不安全的演算法淘汰掉 (RSA 小於 2048 bits，以及 SHA-1 類的 hash algorithm)，這兩個部份相關的新聞應該不少，沒有什麼太大問題：
TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.
TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.
然後是要求憑證使用 SAN (Subject Alternative Name)，舊的標準 CN (CommonName) 將不會再被信任。
如果是公開簽發的憑證應該都沒問題 (像是 Let's Encrypt，或是花錢買的那些)，主要的問題應該會出現在自己建立的憑證，網路上蠻多舊資料還是產生 CN...
TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.
另外是 2019/7/1 之後發出的憑證，有額外兩個規範要注意，第一個是強制要透過 EKU 指定 id-kp-serverAuth，這是出自 RFC 5280：
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreementTLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
再來是時間的限制，接下來的憑證最長只認得 825 天 (大約 27 個月多一些)，以前都惡搞 -days 3650，現在得兩年簽一次了：
TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).
整體看起來主要是影響自己簽的部份...
Let's Encrypt 推出 ACMEv2 後要終止 ACMEv1 的計畫，是今年三月發的消息，但一直沒注意到，剛剛翻到「acme-client(1) moves to Let's Encrypt v02 API」時才看到的：「End of Life Plan for ACMEv1」。
日落分成幾個階段，第一個階段是今年十一月終止透過 ACMEv1 註冊新帳號：
In November of 2019 we will stop allowing new account registrations through our ACMEv1 API endpoint. Existing accounts will continue to function normally.
第二個階段是明年六月終止透過 ACMEv1 申請新的 certificate：
In June of 2020 we will stop allowing new domains to validate via ACMEv1.
第三個階段是 2021 年會開始測試關閉 ACMEv1 的 renew 功能，一個月不會超過一次，每次大約 24 小時，這是讓 client 有機會丟出錯誤訊息：
Starting at the beginning of 2021 we will occasionally disable ACMEv1 issuance and renewal for periods of 24 hours, no more than once per month (OCSP service will not be affected).
最後的階段是 2021 年的六月，會完全關閉 ACMEv1 所有的服務：
In June of 2021 we will entirely disable ACMEv1 as a viable way to get a Let’s Encrypt certificate.
目前在用的都支援 ACMEv2 了，應該是 ok...
AWS 可以設定 IAM 使用者強制使用 MFA (包括 API 的操作)，在這種情況下如果要使用 AWS Command Line Interface 就得透過 AWS STS (AWS Security Token Service) 產生另外一組 key + secret + session key，然後這組通行時間預設是 12 小時。
相關的文章可以參考「How do I use an MFA token to authenticate access to my AWS resources through the AWS CLI?」這篇，然後我就寫了一段 shell script 來做這件事情。
首先是在 ~/.aws/config 內放入 MFA 的 ARN，像是這樣：
[profile mycompany] mfa = arn:aws:iam::012345678901:mfa/gslin region = us-east-1
然後就可以用 aws.mfa mycompany 指令產生出一個會把 key + secret + session key 包進去的 shell：
function aws.mfa() {
local MFA_ARN
local MFA_TOKEN
local PROFILE="$1"
local STSDATA
MFA_ARN="$(python3 -c "import configparser; import os; c=configparser.ConfigParser(); c.read('{}/.aws/config'.format(os.environ['HOME'])); print(c['profile ${PROFILE}']['mfa'])")
"
echo "Reading ${PROFILE} and going for token ${MFA_ARN} ..."
echo -n 'MFA Password: '
read -r MFA_TOKEN
STSDATA="$(aws --profile "${PROFILE}" sts get-session-token --serial-number "${MFA_ARN}" --token-code "${MFA_TOKEN}")"
export AWS_ACCESS_KEY_ID="$(echo "${STSDATA}" | jq -r .Credentials.AccessKeyId)"
export AWS_SECRET_ACCESS_KEY="$(echo "${STSDATA}" | jq -r .Credentials.SecretAccessKey)"
export AWS_SESSION_TOKEN="$(echo "${STSDATA}" | jq -r .Credentials.SessionToken)"
echo 'Running an independant shell...'
${SHELL}
}很明顯的裡面用到了 Python 3 與 jq，這兩個應該都可以直接裝系統的版本就可以了。
後續的操作就跟原來的用法都一樣，像是 aws --region=us-east-1 s3 ls 這樣的指令。
EBS 有選項可以預設開加密了：「New – Opt-in to Default Encryption for New EBS Volumes」。
不算太意外的，這個選項要一區一區開：
Per-Region – As noted above, you can opt-in to default encryption on a region-by-region basis.
也不太意外的，無法完全公開共用：
AMI Sharing – As I noted above, we recently gave you the ability to share encrypted AMIs with other AWS accounts. However, you cannot share them publicly, and you should use a separate account to create community AMIs, Marketplace AMIs, and public snapshots. To learn more, read How to Share Encrypted AMIs Across Accounts to Launch Encrypted EC2 Instances.
然後有些服務有自己的 EBS 設定，這次不受影響。而有些底層其實是用 EC2 的服務 (然後開 EBS) 就會直接套用了：
Other AWS Services – AWS services such as Amazon Relational Database Service (RDS) and Amazon WorkSpaces that use EBS for storage perform their own encryption and key management and are not affected by this launch. Services such as Amazon EMR that create volumes within your account will automatically respect the encryption setting, and will use encrypted volumes if the always-encrypt feature is enabled.
在「Intel Performance Hit 5x Harder Than AMD After Spectre, Meltdown Patches」這邊看到的測試：
把現有的安全性更新都開啟後，Intel CPU 的效能掉了 20% 左右 (在 Intel 上需要把 HT 關掉)：
While the impacts vary tremendously from virtually nothing too significant on an application-by-application level, the collective whack is ~15-16 percent on all Intel CPUs without Hyper-Threading disabled. Disabling increases the overall performance impact to 20 percent (for the 7980XE), 24.8 percent (8700K) and 20.5 percent (6800K).
The AMD CPUs are not tested with HT disabled, because disabling SMT isn’t a required fix for the situation on AMD chips, but the cumulative impact of the decline is much smaller. AMD loses ~3 percent with all fixes enabled
可以注意到兩家目前桌機的頂規在上了安全性更新後，AMD 的 2990WX 比 Intel 的 7980XE 快了一些些... 當初擠牙膏擠出來的都吐回去了，不知道之後出的 security issue 還需要再吐多少回去。
Elasticsearch 決定將基本的安全功能從付費功能轉為免費釋出，很明顯的是受到 Open Distro for Elasticsearch 的壓力而做出的改變：「Security for Elasticsearch is now free」。
要注意的是這不是 open source 版本，只是將這些功能放到 basic tier 裡讓使用者免費使用：
Previously, these core security features required a paid Gold subscription. Now they are free as a part of the Basic tier. Note that our advanced security features — from single sign-on and Active Directory/LDAP authentication to field- and document-level security — remain paid features.
這代表 Open Distro for Elasticsearch 提供的還是比較多：
With Open Distro for Elasticsearch, you can leverage your existing authentication infrastructure such as LDAP/Active Directory, SAML, Kerberos, JSON web tokens, TLS certificates, and Proxy authentication/SSO for user authentication. An internal user repository with support for basic HTTP authentication is also avaliable for easy setup and evaluation.
Granular, role-based access control enables you to control the actions a user can perform on your Elasticsearch cluster. Roles control cluster operations, access to indices, and even the fields and documents users can access. Open Distro for Elasticsearch also supports multi-tenant environments, allowing multiple teams to share the same cluster while only being able to access their team's data and dashboards.
目前看起來還是可以朝 Open Distro for Elasticsearch 靠過去...
AWS 弄出來的 Open Distro for Elasticsearch 因為內建了安全性的功能 (參考「AWS 對 Elastic Stack 實作免費的開源版本 Open Distro for Elasticsearch」)，應該是目前新架設 Elasticsearch 的首選。
不過裝好後預設有五個帳號，但從 Open Distro 的 Kibana 介面無法修改改其中兩個使用者的密碼 (admin 與 kibanaserver)，要修改密碼發現得花不少功夫，不知道為什麼要這樣設計 :/
這邊講的是透過 RPM (以及 deb) 的方式的修改方式，如果是 Docker 的方式請參考後面提到在 AWS blog 上的文章：「Change your Admin Passwords in Open Distro for Elasticsearch」。
首先先透過 hash.sh 產生 bcrypt 的 hash，像是這樣 (輸入 password 當密碼)：
bash /usr/share/elasticsearch/plugins/opendistro_security/tools/hash.sh WARNING: JAVA_HOME not set, will use /usr/bin/java [Password:] $2y$12$QchkpgY8y/.0TL7wruWq4egBDrlpIaURiBYKoZD50G/twdylgwuhG
然後修改 /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml 檔案裡面的值，順便改掉 readonly 的部分。
接下來是把這個 internal_users.yml 檔案的設定更新到 Elasticsearch 裡。由於這邊需要讀 /etc/elasticsearch/ 的東西，所以偷懶用 root 跑 ：
sudo bash /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -cd ../securityconfig/ -icl -nhnv -cacert /etc/elasticsearch/root-ca.pem -cert /etc/elasticsearch/kirk.pem -key /etc/elasticsearch/kirk-key.pem
做完後可能要重跑 Elasticsearch 與 Kibana：
sudo service elasticsearch restart sudo service kibana restart
或是重開機... 順便測試看看重開後有沒有生效。理論上修改完成後，就是用新的帳號密碼連到 Kibana。
上面的方法是參考了「Default Password Reset」(先找到這篇) 與「change admin password」(後來在 AWS blog 的文章上發現的 GitHub issue 連結) 這邊的資訊。
官方的說明文件則是在寫這篇文章時才找到的，平常搜尋時不太會出現：「Apply configuration changes」。
Let's Encrypt 宣佈了以後的憑證的簽發計畫：「Transitioning to ISRG's Root」。
主要的改變是 2019/07/08 之後提供的 intermediate CA 會改變，從現在的 cross-sign 變成只有自己的 Root CA：
On July 8, 2019, we will change the default intermediate certificate we provide via ACME. Most subscribers don’t need to do anything. Subscribers who support very old TLS/SSL clients may want to manually configure the older intermediate to increase backwards compatibility.
目前的簽發用的兩個中介憑證 (Let's Encrypt Authority X3 與 Let's Encrypt Authority X4) 是由 Let's Encrypt 自己的 ISRG Root X1 與 IdenTrust 的 DST Root CA X3 所 共同簽署的：
這是因為 IdenTrust 的 DST Root CA X3 憑證很久前就被各家瀏覽器信任 (像是 Mozilla 的「Request to add two additional IdenTrust root CA certificates」這篇，可以看到 2007 年就被放進去了)，而 Let's Encrypt 當時為了更快把可用的產品推出，所以跟 IdenTrust 合作，採用 cross sign 的方式讓 Let's Encrypt 簽出來的憑證被一般瀏覽器與函式庫所信任。
現在差不多過了三年半，Let's Encrypt 成為目前世界上最大的 SSL Certificate 發放單位，加上自己的 Root CA (ISRG Root X1) 也都差不多被整合進各家系統內了，所以打算要獨立自己簽了。
不過系統上可以設定，使用者如果有遇到相容性問題 (太舊的系統可能還是不包含 Let's Encrypt 自家的 ISRG Root X1)，還是可以設定使用有 cross-sign 的版本 (維持現狀)。與 IdenTrust 的 cross-sign 會維持到 2021 年九月，大約再兩年多一些：
Our current cross-signature from IdenTrust expires on March 17, 2021. The IdenTrust root that we are cross-signed from expires on September 30, 2021. Within the next year we will obtain a new cross-signature that is valid until September 29, 2021. This means that our subscribers will have the option to manually configure a certificate chain that uses IdenTrust until September 29, 2021.
對於自用來說應該沒什麼大影響，主要是企業用戶要注意相容性...