Tag: ssh

對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)

在「Disasters」這邊列了不少對稱式加密系統 (secret-key cryptography) 爆炸的歷史，其中提到了很多 Encrypt 與 MAC 結合時的問題 (Authenticated encryption)。另外 Colin Percival 在 2009 年的時候有寫了一篇為什麼要用 Encrypt-then-MAC 的文章：「Encrypt-then-MAC」，當時 Colin Percival 寫的時候大家還是不能理解，但現在回頭看上面的爆炸歷史應該就清楚很多了 XDDD

SSH 協定是使用 Encrypt-and-MAC (傳輸「密文」與「明文的 MAC 值」)。在 2008 年時 SSH 使用 CBC 模式時會有安全問題：對 128bits CBC mode system (像是 aes128-cbc)，任意位置的 32bits 有 2-18 的機會可以解出原文。(CVE-2008-5161，論文是「Plaintext Recovery Attacks Against SSH」)

TLS 1.0 (SSLv3) 使用 MAC-then-Encrypt (傳輸「明文與明文的 MAC 值」加密後的結果)。1999 年就知道這個方法不可靠，不過到了 2011 年時才被拿出來示範，也就是 BEAST attack。(CVE-2011-3389，在 ekoparty Security Conference 上的「表演」：「BEAST: Surprising crypto attack against HTTPS」，連結1、連結2)

OpenSSL 與 GnuTLS 所實作的 DTLS 在 2011 年也被炸到，其中 OpenSSL 是 100% plaintext recovery，GnuTLS 是 4%。(CVE-2012-0390，論文是「Plaintext-Recovery Attacks Against Datagram TLS」)

而 Encrypt-then-MAC (傳輸「密文」與「密文的 MAC」) 是三者裡面最不容易出包的作法，而且被證明 Provable security：Encrypt 與 MAC 所用的 crypto system 的安全強度不會因為 Encrypt-then-MAC 而減少。而這也是 IPSec 的作法。

附帶一提，其中 Provable security 這個詞，並非表示「可被證明是安全的」，在「In defense of Provable Security」這篇文章裡有比較完整的說明。通常是指安全強度不會因為這個系統而降低：以 Encrypt-then-MAC 的例子來說，如果 Encrypt 的部份用 DES，或是 MAC 用 CRC32，那麼 Encrypt-then-MAC 並不會提供更強的安全性...

總而言之，MAC-then-Encrypt 與 Encrypt-and-MAC 的方式要小心才能避免各種攻擊 (像是不能用 CBC mode)，而 Encrypt-then-MAC 可以讓設計協定的人放鬆到「只要 Encrypt 與 MAC 都夠強」系統就沒問題。在 Authenticated encryption 裡提到的 ISO/IEC 19772:2009 支援六個模式，有些有專利問題，有些演算法看起來就很複雜 (於是就容易出包)，其中 Encrypt-then-MAC 看起來是個還不錯的方案...

把 PEM Private Key 檔轉成 SSH Public Key 格式...

在 RSA 中，單獨靠 Private Key 是無法算出 Public Key 的，不過在 PEM 檔裡因為都有紀錄，所以可以取出：

openssl rsa -in aws.pem -pubout

不過取出的格式需要再轉一次讓 OpenSSH 可以吃：(參考「Convert pem key to ssh-rsa format」這篇的方法)

ssh-keygen -f aws.pub -i -m PKCS8

雖然 ssh-keygen 不接受 - 當 stdin，但可以利用 /dev/stdin 直接串起來：

openssl rsa -in aws.pem -pubout | ssh-keygen -f /dev/stdin -i -m PKCS8

把 SSH 換成 Mosh

Mosh 是一個取代 SSH (OpenSSH) 的工具，官方網站上是這樣介紹：

Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.

Mosh 最大的特性是透過 UDP 加密傳輸 (AES-128 OCB mode)，而且不綁定 IP address 後設計出這些特性：

  • 筆電休眠後再打開電腦就可以直接連上。
  • 登入 VPN 造成 IP 改變後也沒關係。

另外 Mosh 模擬了 local echo 機制，就算在 latency 偏高的網路下也還是可以感覺到不錯的反應速度。

不過是到了 1.2 之後支援 --ssh 這個參數才變得好用，在 client 端只要這樣跑 (假設 ssh port 在 1234)：

mosh --ssh="ssh -p 1234 -v" gslin@server.example.com --server="env LANG=en_US.UTF-8 mosh-server"

Mosh 就會用 ssh 登入後自動執行 mosh-server 取得 shared key 給 mosh-client 用。如果本來就有使用 public key 機制的話就跟原來沒差了 :p

預設吃 port 60000-61000 其中的一個 UDP port，所以記得開 firewall...

AWS EC2 全面支援 64bits，並補上產品線...

之前用 AWS EC2 的人常遇到的狀況是，t1.micro 記憶體太小會常常 out of memory (用 EBS 硬撐當 swap 效能不好)，但 m1.small 只能跑 32bits，為他做完整的 32bits image 維護成本實在不划算，因為等到之後變大後又得改做一份 64bits 的 image，如果從 t1.micro 改用 m1.large 又嫌太大台...

現在這個問題總算是解決了：「Announcing three new Amazon EC2 features」，EC2 這次提供新功能包括：

  • 推出新的 instance 種類 m1.medium，收費是 m1.small 的兩倍，所以規格大致上也是 m1.small 的兩倍，其中記憶體是 3.5GB RAM。
  • m1.small 與 m1.medium 除了可以跑 32bits 以外，也可以跑 64bits。

於是本來的問題可以用不同方向解決：

  • 本來做的 32bits image 當 m1.small 不夠用時也可以先拿 m1.medium 擋著。
  • 既然所有 EC2 instances 都可以跑 64bits，以後只要做 64bits image 就好了。
  • 同樣的，現在用 m1.large 嫌太大台的可以降到 m1.medium 或是 m1.small。

另外這次提供 Java SSH client，可以讓你直接在 Web Console 上面一貫作業，這個就比較用不到了...

GitHub 要求全面檢查 SSH Key

在 GitHub 被攻擊成功後 (參考 GitHub 官方所說的「Public Key Security Vulnerability and Mitigation」這篇)，官方除了把漏洞修補完以外，接下來做了更積極的措施：暫停所有的 SSH key 存取權限，一律等到用戶 audit 確認過後才開放：「SSH Key Audit」。

這次 GitHub 除了修正問題、audit key 以外，另外還提出了新的機制讓用戶更容易發現異常存取行為，包括了：

  • 新增 SSH public key 時要輸入密碼。
  • 新增 SSH public key 成功後會寄信通知。
  • 新增「Security History」頁面可以看到帳戶的安全狀況。

算是很積極補救的作法。

另外說明，要如何 audit key，也就是要如何取得你的 public key fingerprint：

ssh-keygen -lf .ssh/id_rsa.pub (如果你是用 RSA)
或是
ssh-keygen -lf .ssh/id_dsa.pub (如果你是用 DSA)

出現的訊息就是你要比對的值。記住！既然是 audit，請一個一個比對確認 fingerprint 全部都正確。

附上原始信件：(好像還沒在 blog 上說明)

A security vulnerability was recently discovered that made it possible for an attacker to add new SSH keys to arbitrary GitHub user accounts. This would have provided an attacker with clone/pull access to repositories with read permissions, and clone/pull/push access to repositories with write permissions. As of 5:53 PM UTC on Sunday, March 4th the vulnerability no longer exists.

While no known malicious activity has been reported, we are taking additional precautions by forcing an audit of all existing SSH keys.

# Required Action

Since you have one or more SSH keys associated with your GitHub account you must visit https://github.com/settings/ssh/audit to approve each valid SSH key.

Until you have approved your SSH keys, you will be unable to clone/pull/push your repositories over SSH.

# Status

We take security seriously and recognize this never should have happened. In addition to a full code audit, we have taken the following measures to enhance the security of your account:

- We are forcing an audit of all existing SSH keys
- Adding a new SSH key will now prompt for your password
- We will now email you any time a new SSH key is added to your account
- You now have access to a log of account changes in your Account Settings page
Sincerely, The GitHub Team

--- https://github.com support@github.com

PuTTY 0.61

昨天看到 PuTTY 出 0.61 了：「PuTTY version 0.61 is released」，相隔四年多的另外一個新版。

看 New features 裡面，我看到一點還蠻有趣的：

On Windows: the Appearance panel now includes a checkbox to allow the selection of non-fixed-width fonts, which PuTTY will coerce into a fixed-width grid in its terminal emulation. In particular, this allows you to use GNU Unifont and Fixedsys Excelsior. (Thanks to Randall Munroe for a serious suggestion that inspired this.)

這代表可以用各種奇怪的字體嗎？主力系統換成 Ubuntu 後就沒用 PuTTY 了...

AWS EC2 可以匯入自己的 SSH public key 了...

今天 AWS EC2 一口氣丟出一堆小功能：

其實這些功能都沒什麼大不了的，Idempotent Instance Creation 可以避免重複產生 instance，而 Resource Tagging 暫時想不到用途，Filtering 則是 describe 的功能加強...

對現在最有幫助的是第四個，ssh 時可以不用指定 -i .ssh/ooxx.pem 算是有直接影響的吧？目前還不能透過 Web Console 匯入，必須用 ec2-import-keypair 指令匯入。