Home » Posts tagged "https"

SSL Certificate 的認證方式限縮

在「Ballot 218 - Remove validation methods 1 and 5 - CAB Forum」看到「Ballot 218: Remove validation methods #1 and #5」這則議案以 78% 的同意票通過,限縮 SSL Certificate 的認證方式。眼睛瞄到中華電信投下反對票:

14 Yes votes: CFCA, Cisco, Comodo CA, D-TRUST, DigiCert, GDCA, GlobalSign, GoDaddy, Izenpe, Let’s Encrypt, Logius PKIoverheid, SSL.com, TrustCor, Trustwave

4 No votes: Buypass, Chunghwa Telecom, Entrust Datacard, SwissSign

4 Abstain: Actalis, Disig, HARICA, OATI

78% of voting CAs voted in favor

找了一下在 BR (Baseline Requirements) 的 3.2.2.4.1 與 3.2.2.4.5,其中前者是透過註冊商認證:

3.2.2.4.1 Validating the Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar.

後者是透過文件認證:

3.2.2.4.5 Domain Authorization Document

Confirming the Applicant's control over the FQDN by relying upon the attestation to the authority of the Applicant to request a Certificate contained in a Domain Authorization Document.

在想投下反對的原因,會不會是因為中華自己的 domain 應該都是透過後者方式發的?透過內部公文系統...

GitHub 停用過時加密演算法的計畫

先前有提到 GitHub 廢除 SSH 中的弱演算法 (參考「GitHub 明年關閉 SSH 上 SHA1 相關的 Kx (Key Exchange) 演算法」),現在宣佈詳細作法了:「Weak cryptographic standards removal notice」。

包括 HTTPS 的 TLSv1/TLSv1.1 以及 SSH 的 diffie-hellman-group1-sha1/diffie-hellman-group14-sha1 都會被廢止。而作法跟其他家不太一樣:

  • February 8, 2018 19:00 UTC (11:00 am PST): Disable deprecated algorithms for one hour
  • February 22, 2018 19:00 UTC (11:00 am PST): Permanently disable deprecated algorithms

先關閉一個小時讓沒看公告但是有注意到的人可以發現,然後過兩個禮拜後才完全關閉。跟其他家不太一樣的作法...

Stripe 宣佈 TLS 1.0/1.1 的退場時間表

Stripe 宣佈了今年的 2/19 會停用測試環境的 TLS 1.0/1.1,並且在 6/13 全面停用:「Completing an upgrade to TLS 1.2」。

  • Monday, February 19: All servers using older versions of TLS will be blocked from the Stripe API in test mode.
  • Wednesday, June 13: All servers using older versions of TLS will be blocked from the Stripe API in live mode.

這喊好久了,總算是開槍了...

隔壁棚 PayPal 反而早就把 Sandbox 環境上 TLS 1.2-only 了,而六月底也會強制所有連線都必須是 TLS 1.2:「TLS 1.2 and HTTP/1.1 Upgrade - PayPal」。

Let's Encrypt 的 Wildcard SSL Certificate 延至二月底推出

Let's Encrypt 本來預定在一月底時推出 Wildcard SSL Certificate (參考「Let's Encrypt 決定要規劃 Wildcard SSL Certificate 了」),昨天突然想到應該是要推出了... 查了資料發現在原本的公告文章上宣佈延到二月底了:「Wildcard Certificates Coming January 2018」。

Update, January 4, 2018

We introduced a public test API endpoint for the ACME v2 protocol and wildcard support on January 4, 2018. ACME v2 and wildcard support will be fully available on February 27, 2018.

所以再等一個月吧...

Tinder 的漏洞

在「Tinder's Lack of Encryption Lets Strangers Spy on Your Swipes」這篇看到 Tinder 的實作問題,主要是兩個問題組合起來。第一個是圖片沒有用 HTTPS 傳輸:

On Tuesday, researchers at Tel Aviv-based app security firm Checkmarx demonstrated that Tinder still lacks basic HTTPS encryption for photos.

第二個是透過 side channel information leaking:即使是 HTTPS 傳輸,還是可以透過 size 知道是哪種類型的操作:

Tinder represents a swipe left to reject a potential date, for instance, in 278 bytes. A swipe right is represented as 374 bytes, and a match rings up at 581.

這兩個資訊就可以把行為組出來了。

接下來應該會先把圖片上 HTTPS 吧?然後再來是把各種類型的 packet 都塞大包一點?

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

這次 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

Archives