其他非 Google 的 Email Hosting 服務

先前在「Cloudflare 的 Email Routing 功能可以讓一般人用 (包括免費帳號)」這邊有提到,因為 Google Workspace 要廢掉免費版本,所以 Cloudflare 推出了 E-mail forwarding 的方案讓大家用,所以一種簡單的解決方法就是註冊另外一個免費的 Gmail 帳號,然後用 Cloudflare 把信件 forward 到新的帳號裡。

但如果想要避開 Google 的服務的話,在 Hacker News 上的「Ask HN: Best hosted alternative to Google Workspace for email?」這邊就有討論不少可能的替代方案,主要是付費的為主。

討論裡常被提起的方案:

我自己是很愛 Fastmail,他的 webmail 界面速度很快 (即使 www.fastmail.com 需要連到美國的伺服氣上),而且鍵盤快速鍵與 Gmail 幾乎相同,所以學習成本很低,就把其中一個 domain 掛上去用,然後把一些服務的註冊 email 都往這邊掛。

而費用的部份,除了可以月繳外,年繳與三年繳都有另外再給 discount (30GB 版本是 US$5/mo、US$50/y 與 US$140/3y),第一次用一年後,後面就是刷三年了...

如果有在用 Office 的話,Microsoft 365 應該也是個選擇方案,不過我對 Outlook 的 folder-based 的設計邏輯用不慣...

然後是 iCloud+,看討論裡面提到穩定度似乎不太行,但也有人用的好好的,我自己是只有拿來同步 Apple 裝置用,沒有用到郵件服務的部份...

另外是自己有架設 Email service,話說這年頭自己搞 Email system 超麻煩的,對於沒搞過的人 SPFDKIM 加上 DMARC 絕對會搞死自己,乖乖丟雲端服務比較省事,我純粹是要保持多路暢通而已...

Cloudflare 的 Email Routing 功能可以讓一般人用 (包括免費帳號)

Cloudflare 宣佈 Email Routing 這個 beta 功能可以讓一般人用 (包括免費帳號):「Email Routing is now in open beta, available to everyone」。

當然,你要先有心裡準備 Cloudflare 會看得到信件裡面的內容,之後可能會幹些有的沒的事情...

這次會把這個功能開放出來,可以看到主要是 G Suite legacy 宣佈要收費的關係:

Most recently, with users wanting to set up Email Routing for more of their domains and with some of G Suite legacy users looking for an alternative to starting a subscription, we have been onboarding tens of thousands of new zones every day into the closed beta.

透過這個功能,至少收信的部份可以透過 Custom addresses 這個功能轉到個人版的 Gmail 或是其他的 email system 上,另外也可以透過 Catch-all address 的功能直接收所有信件,以免費的系統來說,看起來還行,而發信的部份就透過自己本來的 email system 來發,這樣 Cloudflare 看起來也不需要處理 spam 之類的問題。

掃網域下主機名稱的方式...

原文是講滲透測試的前置作業,需要將某個特定 domain 下的主機名稱掃出來:「A penetration tester’s guide to sub-domain enumeration」。

最直接的還是 DNS zone transfer (AXFR),如果管理者沒設好 DNS server 的話,這會是最快的方式。當沒有這個方法時就要用各種其他方式來掃了。

看了一下有幾種方式:

應該有人可以提到所有的東西再寫成程式 XD

Outlook 裡 Ctrl-F 的設計

OSNew 上看到為什麼 Outlook 裡 Ctrl-F 不是 find 的原因:「Why does Outlook map Ctrl+F to forward instead of find?」。

先引用這句話:

Before clicking the link to go to the full story, try to guess the answer. I'm pretty sure you're going to be wrong.

原文在「Why does Outlook map Ctrl+F to Forward instead of Find, like all right-thinking programs?」這邊,1995 年發生的事情。

AWS ELB 加強安全性...

AWS ELB 加強對 SSL 安全性的功能:「Elastic Load Balancing – Perfect Forward Secrecy and Other Security Enhancements」。

第一個是支援 PFS (Perfect Forward Secrecy),愈大多數的實做相同,是使用 ECDH

第二個是 Server Order Preference,由 server 這邊決定最終的 cipher。

最重要的是第三個,也就是「懶人包」。推出新的 security policy ELBSecurityPolicy-2014-01,把上面兩個都設進去了。

這次的升級是對安全性的提昇...

GitHub 的 SSL (HTTPS) 也支援 PFS 與 AE 了...

GitHub 在 2013 年底的公告:「Introducing Forward Secrecy and Authenticated Encryption Ciphers」。

愈來愈多服務升級 & 調整 SSL (HTTPS) 的設定,支援 PFS (Perfect Forward Secrecy) 與 AE (Authenticated Encryption)。

PFS 要預防的事情我可以理解,但對 AE 的必要性不熟啊... 再去看看整個理論基礎與目的好了...

Twitter 也要上 PFS 了...

Twitter 宣佈他們的 HTTPS 連線要上 PFS (Perfect Forward Secrecy) 了:「Forward Secrecy at Twitter」。

回頭查了 F5 要到哪個版本才支援 PFS,看起來要 11.2.1 之後的版本有支援... (出自「BIG-IP LTM and TMOS 11.3.0」這份文)

目前有一組已經是 11.2.1 之後的版本,這樣看起來好像也可以開看看?

SSL/TLS 的 Perfect Forward Secrecy...


寫這篇順便測試 MathJax 的效果...

因為 NSA 的惡搞,這陣子 PFS (Perfect Forward Secrecy) 突然被拿出來討論:

在講 PFS 前,得先講 Diffie-Hellman key exchange (D-H)。

D-H 是利用這個等式:

$$(g^a)^b \equiv (g^b)^a \mod p$$

其中 \(p\) 是大質數,而 \(g\) 是 \(p\) 的 primitive root (即不存在任何 \(n < p\) 可以使得 \(g^n \equiv 1 \mod p\))。 而因為當 \(p\) 夠大時,要從 \(g^a \mod p\) 計算 \(a\) 就是離散對數問題,而離散對數問題是已知沒有有效率計算的問題,所以我們會假定當 \(p\) 夠大時,傳輸 \(g^a \mod p\) 是無法用合理資源計算得知 \(a\)。

因此,Alice 與 Bob 就可以產生自己的 private secret \(a\) (Alice) 與 \(b\) (Bob),計算出 \(g^a\) 與 \(g^b\) 後公開傳輸給對方,當 Bob 收到 Alice 提供的 \(g^a\) 時就計算 \((g^a)^b \equiv g^{ab} \mod n\),而 Alice 收到 Bob 提供的 \(g^b\) 後可以計算 \((g^b)^a \equiv g^{ba} \equiv g^{ab} \mod n\)。

而攻擊者只拿到公開的 \(g^a\) 與 \(g^b\) 以及 \(g\),無法計算出 \(g^{ab}\),於是就雙方就建立一組 shared secret 了。

回到 SSL/TLS 的問題上,由於 RSA 加解密的速度並不快,所以 SSL/TLS 是在 RSA 的保護下交換 RC4 或是 AES 所需要的金鑰 (key)。

交換 key 這件事情除了可以直接交換以外,還可以利用 D-H 交換。

D-H 交換可以確保當 RSA key 被破解時還要再破每個 session 的 D-H 所產生出來的 key,而直接交換的話,只要破一把 RSA key 就可以解出所有 traffic 了。

而 PFS 會被提出來,是因為目前消息指出 NSA 其實有在錄下 SSL/TLS 流量,等哪天有機會取得 RSA key 的時候 (無論是硬解,或是其他方式),就有機會能夠一次破一卡車資料... (因為目前大部分的 SSL/TLS 流量都沒有上 PFS)

雖然 PFS 會慢一些,不過已經確認 NSA 打算來搞了,所以還是乖乖加上去吧... @_@