Home » Posts tagged "tls" (Page 3)

Amazon CloudWatch Logs 換 SSL Certificate 的 CA

收到標題是「Upcoming Changes to SSL Certificates in Amazon CloudWatch Logs」的信件,說明 Amazon CloudWatch Logs 要換 SSL Certificate 的 CA,看起來是要換成自家的:

We will be updating the certificate authority (CA) for the certificates used by Amazon CloudWatch Logs domain(s), between 8 January 2018 and 22 January 2018. After the updates complete, the SSL/TLS certificates used by Amazon CloudWatch Logs will be issued by Amazon Trust Services (ATS), the same certificate authority (CA) used by AWS Certificate Manager.

然後有提到 cross-sign 的部份,有透過 Starfield 的 Root CA 簽,所以只要下面有任何一個有在 Root CA store 裡面就應該會信任:

The update means that customers accessing AWS webpages via HTTPS (for example, the Amazon CloudWatch Console, customer portal, or homepage) or accessing Amazon CloudWatch Logs API endpoints, whether through browsers or programmatically, will need to update the trusted CA list on their client machines if they do not already support any of the following CAs:
- "Amazon Root CA 1"
- "Starfield Services Root Certificate Authority - G2"
- "Starfield Class 2 Certification Authority"

另外條列出有哪些 API endpoint 會改變:

This upgrade notice covers the following endpoints:
logs.ap-northeast-1.amazonaws.com
logs.ap-northeast-2.amazonaws.com
logs.ap-south-1.amazonaws.com
logs.ap-southeast-1.amazonaws.com
logs.ap-southeast-2.amazonaws.com
logs.ca-central-1.amazonaws.com
logs.eu-central-1.amazonaws.com
logs.eu-west-1.amazonaws.com
logs.eu-west-2.amazonaws.com
logs.eu-west-3.amazonaws.com
logs.us-east-1.amazonaws.com
logs.us-east-2.amazonaws.com
logs.us-west-1.amazonaws.com
logs.us-west-2.amazonaws.com
logs.sa-east-1.amazonaws.com

然後也列出了有哪些系統「應該」會支援:

* Operating Systems With ATS Support
- Microsoft Windows versions that have January 2005 or later updates installed, Windows Vista, Windows 7, Windows Server 2008, and newer versions
- Mac OS X 10.4 with Java for Mac OS X 10.4 Release 5, Mac OS X 10.5 and newer versions
- Red Hat Enterprise Linux 5 (March 2007), Linux 6, and Linux 7 and CentOS 5, CentOS 6, and CentOS 7
- Ubuntu 8.10
- Debian 5.0
- Amazon Linux (all versions)
- Java 1.4.2_12, Java 5 update 2, and all newer versions, including Java 6, Java 7, and Java 8

不過沒看到 Windows XP 耶,不知道是怎樣 XD

2017 年 CA/Browser Forum 在台北辦的見面會議的會議記錄出爐了...

2017 年 CA/Browser Forum 在台北舉辦的見面會議,會議記錄總算是出爐了:「2017-10-04 Minutes of Face-to-Face Meeting 42 in Taipei - CAB Forum」。

由於是辦在台北,所以台灣很多單位都有出席,像是中央警察大學 (1)、中華電信 (11)、日盛聯合會計師事務所 (1)、TWCA (3):

Attendance: Peter Bowen (Amazon); Geoff Keating and Curt Spann (Apple); Jeremy Shen (Central Police University); Franck Leroy (Certinomis / Docapost); Wayne Chan and Sing-man Ho (Certizen Limited); Wen-Cheng Wang, Bon-Yeh Lin, Wen-Chun Yang, Jenhao Ou, Wei-Hao Tung, Chiu-Yun Chuang, Chung-Chin Hsiao, Chin-Fu Huang, Li-Chun Chen, Pin-Jung Chiang, and Wen-Hui Tsai (Chunghwa Telecom); Alex Wight and JP Hamilton (Cisco), Robin Alden (Comodo), Gord Beal (CPA Canada), Ben Wilson and Jeremy Rowley (DigiCert), Arno Fiedler and Enrico Entschew (D-TRUST); Kirk Hall (Entrust Datacard); Ou Jingan, Zhang Yongqiang, and Xiu Lei (GDCA); Atsushi Inaba and Giichi Ishii (GlobalSign); Wayne Thayer (GoDaddy); Devon O’Brien (Google); David Hsiu (KPMG); Mike Reilly (Microsoft); Gervase Markham and Aaron Wu (Mozilla); Hoang Trung La (National Electronic Authentication Center (NEAC) of Vietnam); Tadahiko Ito (Secom Trust Systems); Leo Grove and Fotis Loukos (SSL.com); Brian Hsiung (Sunrise CPA Firm); Steve Medin (Symantec); Frank Corday and Tim Hollebeek (Trustwave); Robin Lin, David Chen, and Huang Fu Yen (TWCA); and Don Sheehy and Jeff Ward (WebTrust).

開頭有提到會議記錄 delay 的情況:

Preliminary Note: The CA/Browser Forum was delayed in completing the minutes for its last Face-to-Face meeting Oct. 4-5, 2017 in Taipei, and the proposed final Minutes were only sent by the Chair to the Members on December 13, 2017 for their review. There was not enough time for Members to review the draft before the next teleconference of December 14, and the teleconference of December 28 was cancelled due to the holidays. The next Forum teleconference is scheduled for January 11, 2018.

會議記錄很長,主要是有不少主題被拿到見面會議上討論,另外有一半的篇幅是在說明各家 root program policy 的變化。

下次的見面會議會在三月,然後會由 Amazon 辦在東岸:

Peter confirmed the next F2F meeting will be hosted by Amazon on March 6-8, 2018 at its Herndon, Virginia location. More information will be provided in the coming months.

這次 PKCS #1 1.5 的 ROBOT 攻擊,Cisco 沒打算修...

1998 年就發現的 security issue 因為 workaround 也很複雜,所以不是每一家都修對方法,於是 19 年後又被爆破了。這次叫做 ROBOT:「1998 attack that messes with sites’ secret crypto keys is back in a big way」。

可以看到中獎的表:

這次的攻擊在 client 端無法修正,只能在 server 端修正:

Do I need to update my browser?
No. This is an implementation bug in servers, there is nothing clients can do to prevent it.

如果 server 端無法盡快修正的話,想辦法避開 RSA encryption 可以躲開這個問題,而且因為現代瀏覽器都有非 RSA 的替代方案,這樣做應該都還有退路,可以維持連線的可能性:

Disable RSA encryption!
ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures. We believe RSA encryption modes are so risky that the only safe course of action is to disable them. Apart from being risky these modes also lack forward secrecy.

但使用 Cisco ACE 就哭了,因為 Cisco ACE 只支援 RSA encryption,而 Cisco 官方以產品線已經關閉,不再提供維護而沒有提供更新的計畫,所以就進入一個死胡同...

不過 Cisco 自己也還在用 Cisco ACE 就是了,不在意就不會痛的感覺 XD

I have a Cisco ACE device.
Cisco informed us that the ACE product line was discontinued several years ago and that they won't provide an update. Still, we found plenty of vulnerable hosts that use these devices.

These devices don't support any other cipher suites, therefore disabling RSA is not an option. To our knowledge it is not possible to use these devices for TLS connections in a secure way.

However, if you use these products you're in good company: As far as we can tell Cisco is using them to serve the cisco.com domain.

LinkedIn 忘記續約導致 SSL Certificate 過期

Netcraft 上看到 LinkedIn 出包的消息,這次是 country-mixed 的版本出包:「LinkedIn certificate blunder leaves users LockedOut!」。

在 DNS 上也可以看出來這兩個 CNAME 到不一樣的 load balancer 上:

;; ANSWER SECTION:
www.linkedin.com.       260     IN      CNAME   2-01-2c3e-003c.cdx.cedexis.net.
2-01-2c3e-003c.cdx.cedexis.net. 93 IN   CNAME   pop-ehk1.www.linkedin.com.
pop-ehk1.www.linkedin.com. 3560 IN      A       144.2.3.1
;; ANSWER SECTION:
de.linkedin.com.        86400   IN      CNAME   cctld.linkedin.com.
cctld.linkedin.com.     86400   IN      CNAME   mix.linkedin.com.
mix.linkedin.com.       213     IN      CNAME   pop-ehk1.mix.linkedin.com.
pop-ehk1.mix.linkedin.com. 3546 IN      A       144.2.3.5

SSL Labs 上也看得出來在 Alternative names 的地方是不一樣的:「SSL Server Test: www.linkedin.com (Powered by Qualys SSL Labs)」、「SSL Server Test: de.linkedin.com (Powered by Qualys SSL Labs)」。

然後因為 LinkedIn 有設定 HSTS,所以使用者在界面上完全無法登入:

Google Chrome 上可以用 badidea 繞過 (參考「在 Google Chrome 連上因 HSTS 而無法連線的網站」),但在 Mozilla Firefox 上的話目前沒找到方法可以在界面上 bypass,而是需要改 SiteSecurityServiceState.txt 這個檔案:「HTTP Strict Transport Security prevents me from accessing a server that I'm doing development on」。

不過也因為兩個 cluster 獨立運作,網址改一下應該就會動了...

這幾年比較很少看到大公司出這種包,還蠻有趣的 XD

Amazon Lightsail 推出 Block Storage 與 Load Balancer

Amazon Lightsail 推出了 Block Storage (11/14) 與 Load Balancer (11/29):「Introducing additional block storage for Amazon Lightsail」、「Amazon Lightsail adds load balancers with integrated certificate management」。

兩個是不同時間點發表的,當時懶的寫所以這次一起寫...

Block Storage 有不少 VPS 都有提供了,像是 Linode 的「Linode Block Storage (Fremont beta)」(雖然還在 beta)、DigitalOcean 的「Storage on DigitalOcean | Highly available Block Storage」以及 Vultr 的「High Performance and Cheap Block Storage - Vultr.com」。

AWS 算是很早就有這個服務 (Amazon EBS),這邊應該只是把系統整合進來...

另外一個是這幾天推出的 Load Balancer,目前應該只有 Linode 的「Ensure High-Availability with NodeBalancers - Linode」比較知名。AWS 上的 ELB 有不少選擇可以用 (ELB Classic、ALB 以及 NLB),不過公告裡沒特別提到... 比較特別的是提供免費的 SSL Certificate 吧?這在其他家主要得靠 Let's Encrypt 來做,在 AWS 上應該是整合了 ACM

AWS Certificate Manager 支援 DNS 認證的方式頒發憑證了

AWS Certificate Manager (ACM) 可以用 DNS 的方式認證了:「Easier Certificate Validation Using DNS with AWS Certificate Manager」。

不過這不同於 Let's Encrypt 在推的 dns-01,而是 AWS 自己定義的方式:

然後文章後面又再次提醒了一次,如果要用在 Amazon CloudFront,必須使用 us-east-1 的 ACM:

Note that your certificate must be in the US East (N. Virginia) Region to use the certificate with CloudFront.

這個方式讓自動化更容易做... 以前需要收信確認,雖然也是可以寫程式硬幹,但就得冒著 AWS 改版造成程式失效的風險。

StartCom 決定關門

Hacker News 上看到 StartCom 決定關門的消息:「Termination of the certificates business of Startcom」。

2018 停發新的憑證,然後維護兩年 CRLOCSP 服務:

We´ll set January 1st 2018 as the termination date and will stop issuing certificates therefrom. We will maintain our CRL and OCSP service for two more years from January 1st 2018. The three pairs of StartCom key Roots will be eliminated after that time.

在不斷的抵制下總算關了...

Savitech (盛微) 的 USB 音效驅動程式會安裝 Root CA (被發了 CVE-2017-9758)

Hacker News 上看到 CERT 的「Savitech USB audio drivers install a new root CA certificate」提到 Savitech USB audio driver 會安裝自己的 Root CA:

Savitech provides USB audio drivers for a number of specialized audio products. Some versions of the Savitech driver package silently install a root CA certificate into the Windows trusted root certificate store.

出自「Inaudible Subversion - Did your Hi-Fi just subvert your PC? (原網站已經無法訪問,參考備份連結 https://archive.is/K6REr)」,CVE 編號是 CVE-2017-9758,最初是由 n3kt0n 提出的:「某單位 drivers silently install certificate in trusted root certificate authorities store [CVE-2017-9758]」:

Mitre assigned this exposure the identifier CVE-2017-9758, but was initially tracked by HITCON ZeroDay project as ZD-2017-00386.

有兩把 CA public key 被塞進去。雖然目前還沒有徵兆 private key 有外洩,但還是建議儘快移除:

There is currently no evidence that the Savitech private key is compromised. However, users are encouraged to remove the certificate out of caution. The two known certificates are:

SaviAudio root certificate #1
‎Validity: Thursday, ‎May ‎31, ‎2012 - ‎Tuesday, ‎December ‎30, ‎2036
Serial number: 579885da6f791eb24de819bb2c0eeff0
Thumbprint: cb34ebad73791c1399cb62bda51c91072ac5b050

SaviAudio root certificate #2
Validity: ‎Thursday, ‎December ‎31, ‎2015 - ‎Tuesday, ‎December ‎30, ‎2036
Serial number: ‎972ed9bce72451bb4bd78bfc0d8b343c
Thumbprint: 23e50cd42214d6252d65052c2a1a591173daace5

另外 Savitech 也放出了新版的 driver,不包含 Root CA:

Savitech has released a new driver package to address the issue. Savitech drivers version 2.8.0.3 or later do not install the root CA certificate. Users still must remove any previously installed certificate manually.

看了一下說明,看起來是當時為了支援 Windows XP 而做的,但微軟已經不提供驅動程式的數位簽章了,所以就只好這樣搞...

CloudFlare 也要提供 Certificate Transparency 的 Log 伺服器了...

看到 CloudFlare 請求加入 Chromium (Google Chrome) 的伺服器列表:「Certificate Transparency - Cloudflare "nimbus2017" Log Server Inclusion Request」。

對照之前的「Chromium 內提案移除 HPKP (HTTP Public Key Pinning)」以及「Let's Encrypt 的 Embed SCT 支援」,這樣看起來是瀏覽器內會有一份白名單,只有在這白名單上的 Embed SCT 才會被信任...

但弄到這樣的話,log server 是不是也要有稽核機制?

好像哪邊搞錯了方向啊...

Archives