Tag: cipher

實際比較 Linode 的 Dedicated 主機與 AWS 的 c5.*

先前有提到 Linode 出了 Dedicated 主機：「Linode 推出 Dedicated CPU Instances」，現在找機會測試看看，拿了 Linode 的 Dedicated (4GB) 與 AWS 的 c5.large 比較，同樣都是 2 vCPU 與 4GB RAM。

這邊用了 n-st/nench 與 OpenSSL 的 speed (包括了 aes、md5、rsa、sha1 與 sha256) 測試，我把結果都貼到這邊：「Linode (Dedicated 4GB) v.s. AWS (c5.large)」。

可以看到在 CPU 方面主要的差異是 Linode 用的是 AMD，而 AWS 用的是 Intel，所以就會有蠻多不同的數字表現...

如果仔細看 OpenSSL 的測試數據，可以看到不同演算法的差異還蠻大的，馬上可以想到的應該是硬體加速方式與 cache 架構差異造成的：

  • 在 cipher 類的測試我只測了 AES (目前的主流)，小的 block (16/64/256 bytes) 時 AMD 會輸一些，但大的 block (1024/8192/16384 bytes) 反而會贏不少。
  • 在 hash 類的測試中，跑 MD5 時 Linode 則是輸一些，但 SHA1 反而是贏一些，然後 SHA256 時效能好到爆炸贏了一倍 XDDD
  • 在 public key 類的測試我測了 RSA，則是 Linode 輸的蠻慘的...

如果考慮到價位大約只有 AWS 的一半，應該是還不錯...

所以要開始開發 CECPQ2 了...

CECPQ1 是 Google 在研究對抗量子電腦的演算法，作為測試用的演算法，曾經在 Google Chrome 的 54 beta 版 (2016 年) 存活過一段時間，最近又開始在開發新一代的演算法 CECPQ2 了，這次會是基於 TLS 1.3 上測試：「CECPQ2」。

CECPQ2 will be moving slowly: It depends on TLS 1.3 and, as mentioned, 1.3 is taking a while. The larger messages may take some time to deploy if we hit middlebox- or server-compatibility issues. Also the messages are currently too large to include in QUIC. But working though these problems now is a lot of the reason for doing CECPQ2—to ensure that post-quantum TLS remains feasible.

目前對抗量子電腦的演算法好像都跟 Lattice 有關，找時間來補一下基礎理論... @_@

nginx 推出了 1.14.0 的 PPA

nginx 的 PPA (「NGINX Stable : “Nginx” team」這個) 推出了 1.14.0 的版本。

這個版本使用了 OpenSSL 1.1.0，對 cipher 這塊最大的差異主要是包括了 CHACHA20 與 AESCCM 演算法。後者的 CCM 指的是 CCM mode，這是當時 OCB mode 因為專利問題而發展出來的演算法，就目前的效能測試沒有 GCM 好，而且普及率也沒有 GCM 高，放進來應該是當備案 (當 GCM 有狀況時標準裡至少有方案可以選)：

The catalyst for the development of CCM mode was the submission of OCB mode for inclusion in the IEEE 802.11i standard. Opposition was voiced to the inclusion of OCB mode because of a pending patent application on the algorithm. Inclusion of a patented algorithm meant significant licensing complications for implementors of the standard.

真正的重點在於 CHACHA20 的引入，讓 OpenSSL 重新有主流 stream cipher 可以使用了... 上一個主流 stream cipher RC4 被打趴好久了。

不過 TLSv1.3 要等 OpenSSL 1.1.1 才有 (參考「Using TLS1.3 With OpenSSL」這邊的說明)，目前可以在設定檔裡面設 TLSv1.3 而不會出現錯誤訊息，但暫時還不會有效果...

TLS 1.3 進入 Proposed Standard

最近蠻熱的一個新聞，TLS 1.3 的 draft-ietf-tls-tls13-28.txt 進入 Proposed Standard 了 (在「draft-ietf-tls-tls13-28 - The Transport Layer Security (TLS) Protocol Version 1.3」這邊可以看到歷史記錄)：「Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)」。

沒意外的話這就會是最終版本了。如果要看 TLS 1.2 與 TLS 1.3 的差異，看維基百科上的 Transport Layer Security - TLS 1.3 會比較清楚。

大家等很久了... 像是 OpenSSL 1.1.1 其實一部分也是在等 TLS 1.3 正式推出：(出自「Using TLS1.3 With OpenSSL」)

OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised. In the meantime the OpenSSL git master branch contains our development TLSv1.3 code which can be used for testing purposes (i.e. it is not for production use).

主要還是期待非 NSA 派系的 cipher (其實幾乎都是 djb 的戰果) 與 1-RTT handshake，後續等 TLS 1.3 變成 Standard Track 應該就會被各家瀏覽器開預設值了...

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

IEEE P1735 漏洞，又是 Padding Oracle Attack...

在「IEEE P1735 Encryption Is Broken—Flaws Allow Intellectual Property Theft」這邊看到 US-CERT 發表的「IEEE P1735 implementations may have weak cryptographic protections」，裡面提到的主要漏洞：

The methods are flawed and, in the most egregious cases, enable attack vectors that allow recovery of the entire underlying plaintext IP.

主要應該是第一包：

CVE-2017-13091: improperly specified padding in CBC mode allows use of an EDA tool as a decryption oracle.

又是 CBC 的 padding oracle attack 啊... 看起來是標準沒有強制定義好造成的？

The main vulnerability (CVE-2017-13091) resides in the IEEE P1735 standard's use of AES-CBC mode.

Since the standard makes no recommendation for any specific padding scheme, the developers often choose the wrong scheme, making it possible for attackers to use a well-known classic padding-oracle attack (POA) technique to decrypt the system-on-chip blueprints without knowledge of the key.

去年 Cloudflare 寫的「Padding oracles and the decline of CBC-mode cipher suites」這邊有提到 padding oracle attack 的方式，比較一般性的解法是避開要自己決定 Encrypt-then-MAC (IPsec；也是數學上證明安全性) 或 Encrypt-and-MAC (SSH) 或是 MAC-then-Encrypt (SSL)，而是用 AEAD 類的加密元件直接躲開 padding oracle attack 的某些必要條件 (像是 AES-GCM 或是 ChaCha20-Poly1305)。

不過這也是這幾年大家才了解這樣做的重要性，當年在訂規格的時候都比較沒在在意這些...

nginx 記錄 TLS 連線資訊

想要在 nginx 的 access log 裡面記錄使用者在 HTTPS 連線使用的 TLS protocol 與 cipher。

在「How can I let nginx log the used SSL/TLS protocol and ciphersuite?」這邊有提到方向是 $ssl_protocol 與 $ssl_cipher (出自「Module ngx_http_ssl_module」內的 Embedded Variables 章節)。

他的方式是在前面就插入 protocol，但我希望前面的欄位保持不變，把 protocol & cipher 放到後面，所以我就加了一個 /etc/nginx/conf.d/combined_ssl.conf (這邊我用 ondrej 的 PPA，在設定檔裡會撈 /etc/nginx/conf.d/ 下的設定，不確定其他的情況如何)：

#
log_format combined_ssl '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $ssl_protocol/$ssl_cipher';

然後本來用 combined 的 HTTPS 設定就改成 combined_ssl。

來放一陣子再來分析，然後想看看要怎麼調整 cipher...

OpenSSL 1.1.1 將支援 TLS 1.3

OpenSSL 的文章「Using TLS1.3 With OpenSSL」提到了：

The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3.

另外也提到了 TLS 1.3 的標準是 blocker，在 TLS 1.3 沒出來前不會出 OpenSSL 1.1.1：

OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised.

OpenSSL 實做的 TLS 1.3 支援了這些 cipher：

  • TLS13-AES-256-GCM-SHA384
  • TLS13-CHACHA20-POLY1305-SHA256
  • TLS13-AES-128-GCM-SHA256
  • TLS13-AES-128-CCM-8-SHA256
  • TLS13-AES-128-CCM-SHA256

GCM 的部份不算意外，比較特別的是包括了 ChaCha20 與 Poly1305 (喊很久了)，另外包括了 CCM mode 的實做...

OpenSSL 1.1.0

看到「OpenSSL 1.1.0 released」這篇得知大家期待已久的 OpenSSL 1.1.0 出了，在 1.1.0 的重要新功能中，對 ChaCha20 + Poly1305 的支援算是大家等很久的：

  • Support for ChaCha20 and Poly1305 added to libcrypto and libssl

由於 RC4 已經被證明不安全，OpenSSL 內變成沒有堪用的 stream cipher，這邊總算要補上來了...

另外兩個也頗有趣的：

  • Support for scrypt algorithm
  • Support for X25519

多了些東西...

SWEET32：攻 Blowfish 與 3DES

最新的攻擊算是實戰類的攻擊，理論基礎以前都已經知道了，只是沒有人實際「完成」。算是近期少數直接對演算法的攻擊，而這些演算法剛好還是被用在 TLS 與 OpenVPN 上，所以嚴重性比較高：「SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN」。

攻擊的條件是 block cipher 的 block size，而非 key length，所以就算是 256 bits 的 Blowfish 也一樣也受到影響。

這次順利打下 Blowfish 與 3DES。這兩個 cipher 的 block size 都是 64 bits，所以對於 birthday attack 來說只要 232 就可以搞定：

This problem is well-known by cryptographers, who always require keys to be changed well before 2n/2 blocks. However it is often minimized by practitioners because the attacks require known plaintext, and reveal only little information. Indeed, standard bodies only recommend to change the key just before 2n/2 blocks, and many implementations don't enforce any limit on the use of a key.

在 OpenVPN 打 Blowfish 的部份 (Blowfish 是 OpenVPN 預設的 cipher)：

In our demo, it took 18.6 hours and 705 GB, and we successfully recovered the 16-byte authentication token.

以及 HTTPS 打 3DES 的部份 (為了相容性問題)：

Experimentally, we have recovered a two-block cookie from an HTTPS trace of only 610 GB, captured in 30.5 hours.

都是有可能的等級。也該來拔掉對 IE8 的支援了... orz