Home » 2018

Transport-Layer Encryption 與 End-to-End Encryption 的差異

EFF 的「Transport-Layer Encryption vs End-to-End Encryption - GIF」這篇文章介紹了 Transport-Layer Encryption 與 End-to-End Encryption 的差異,最後還給了一張 GIF 說明:

其實 GIF 給的範例還蠻清楚的,在 Transport-Layer Encryption 中服務提供商可以看到原始內容 (以 GIF 內提到的例子就是 Google),而在 End-to-End Encryption 中就不行,只有傳輸雙方可以知道原始內容。

然後文章裡也提到了 Tor Messenger,可以吃現有的通訊軟體,然後在上面疊出 End-to-End Encryption。

Stripe 也宣佈要停止支援 Bitcoin 了

Stripe 發了公告出來,要停止支援 Bitcoin:「Ending Bitcoin Support」。預定保留三個月的緩衝期,在 2018 年 4 月 23 日停掉:

Over the next three months we will work with affected Stripe users to ensure a smooth transition before we stop processing Bitcoin transactions on April 23, 2018.

跟其他單位停用的原因都差不多,愈來愈慢的交易速度與愈來愈高的手續費:

Transaction confirmation times have risen substantially; this, in turn, has led to an increase in the failure rate of transactions denominated in fiat currencies. (By the time the transaction is confirmed, fluctuations in Bitcoin price mean that it’s for the “wrong” amount.) Furthermore, fees have risen a great deal. For a regular Bitcoin transaction, a fee of tens of U.S. dollars is common, making Bitcoin transactions about as expensive as bank wires.

Steam 當時的理由很類似... (參考「Steam 停止使用 Bitcoin 購買遊戲」)

Amazon Aurora (PostgreSQL) 也支援 Read Replica 了

Amazon Aurora (PostgreSQL) 支援 Read Replica 了:「Announcing Amazon Aurora PostgreSQL Read Replica for Amazon RDS for PostgreSQL」。

馬上想到的用途是量爆增時,如果當初有作 R/W split (讀寫分離) 就可以直接用錢撐住,不過官方給的範例是降低 RDS 轉移到 Aurora 的 downtime,這點就有點微妙...:

You can now create an Amazon Aurora PostgreSQL read replica for an Amazon RDS for PostgreSQL instance, allowing you to continuously replicate to Amazon Aurora PostgreSQL. This helps you minimize downtime when migrating a live workload from Amazon RDS for PostgreSQL to Amazon Aurora PostgreSQL, by keeping the instances in sync until you're ready to move your applications and users to Amazon Aurora PostgreSQL.

所以這次算是陸陸續續把功能補上來,在 Amazon Aurora (MySQL) 有的一般性功能,這邊就跟著先實作...

AWS KMS 可以在 VPC 內直接存取了

AWS Key Management Service 宣布支援 AWS PrivateLink Endpoint 了:「How to Connect Directly to AWS Key Management Service from Amazon VPC by Using an AWS PrivateLink Endpoint」。先前需要透過 Internet 流量存取 (透過 NAT、Proxy 之類的服務),現在則是可以接到 VPC 內直接用了:

Previously, applications running inside a VPC required internet access to connect to AWS KMS. This meant managing internet connectivity through internet gateways, Network Address Translation (NAT) devices, or firewall proxies.

With support for Amazon VPC endpoints, you can now keep all traffic between your VPC and AWS KMS within the AWS network and avoid management of internet connectivity.

KMS 需要 Internet 也是之前設計架構時比較痛的地方,現在總算是有個方向可以減少痛處了...

Jeff Barr 正在努力回顧去年 re:Invent 發表的東西:Inter-Region VPC Peering

居然是在補進度 XDDD 這是去年 AWS re:Invent 發表的功能:「New – Inter-Region VPC Peering」,在去年的時候也有提到了:「AWS 總算推出跨區 VPC Peering 了...」。

不過當時不確定跨區域時怎麼處理傳輸加密 (或者沒有處理?),這邊 Jeff Barr 補充提到了一些細節:

Data that passes between VPCs in distinct regions flows across the AWS global network in encrypted form. The data is encrypted in AEAD fashion using a modern algorithm and AWS-supplied keys that are managed and rotated automatically. The same key is used to encrypt traffic for all peering connections; this makes all traffic, regardless of customer, look the same. This anonymity provides additional protection in situations where your inter-VPC traffic is intermittent.

這樣架構會簡單不少,不需要自己再疊一層確保加密這件事情 (因為當時沒翻到資料說有加密...)。

將找 Origin Server IP 位置自動化的 CloudFlair

Twitter 上看到 CloudFlair 這個工具,可以找被 Cloudflare 保護的網站,將尋找後面 Origin Server 的 IP address 的過程自動化:

這隻程式配合 Censys 的資料去找,而不是自己獨立掃整個 IPv4 address。

另外這隻程式也不保證掃的出來,像是透過 Cloudflare 去年十一月推出的新服務 Wrap,就不需要將 Port 80/443 對 Internet 公開 (參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」)。

不過還是蠻好玩的工具啦 XDDD

Rust 版本 Mercurial

看到「Mercurial: 964212780daf」這則 commit log,看起來 MercurialPython 換成 Rust 的計畫正在進行中:

rust: implementation of `hg`

This commit provides a mostly-working implementation of the `hg` script in Rust along with scaffolding to support Rust in the repository.

之前從朋友那邊聽到,在 F 公司用 Mercurial 用到覺得很厭世,主要是因為 repository 太大,一跑下去就會發現記憶體用量與速度都很無奈 (即使內部已經有不少工具改善速度),所以就啟動專案要換一個程式語言,直接拼最後那段的效能 XD

如果是隔壁棚的 Git... 就沒這個問題,一開始 Git 就用 C 寫,所以如果厭世的話也不太容易生出什麼進展了 XDDD

FreeBSD 上的 ccp (AMD Crypto Co-Processor)

看到 FreeBSD 上的「[base] Revision 328150」,將 AMD 的 AMD Crypto Co-Processor。

然後實測效能頗爛 XDDD 不過本來就不是以效能為主吧... 應該是以安全性與 Trusted Platform Module 考量?

像是 4KB buffer 的效能明顯比 AES-NI 慢了一大截 (少了一個零 XDDD):

aesni:      SHA1: ~8300 Mb/s    SHA256: ~8000 Mb/s
ccp:               ~630 Mb/s    SHA256:  ~660 Mb/s  SHA512:  ~700 Mb/s
cryptosoft:       ~1800 Mb/s    SHA256: ~1800 Mb/s  SHA512: ~2700 Mb/s

如果是 128KB buffer 時會好一些:

aesni:      SHA1:~10400 Mb/s    SHA256: ~9950 Mb/s
ccp:              ~2200 Mb/s    SHA256: ~2600 Mb/s  SHA512: ~3800 Mb/s
cryptosoft:       ~1750 Mb/s    SHA256: ~1800 Mb/s  SHA512: ~2700 Mb/s

然後 AES 也類似:

aesni:      4kB: ~11250 Mb/s    128kB: ~11250 Mb/s
ccp:               ~350 Mb/s    128kB:  ~4600 Mb/s
cryptosoft:       ~1750 Mb/s    128kB:  ~1700 Mb/s

所以是 sponsor 有認證需要的關係嗎...

Sponsored by:Dell EMC Isilon

在 ThinkPad T530 上跑 FreeBSD 的介紹

作者在「FreeBSD on a Laptop」這邊寫下了在 ThinkPad T530 上跑 FreeBSD 的完整攻略。

查了一下 ThinkPad T530,這應該是 2012 年就推出的筆電了 (五年多前),所以文章的重點在於要去那邊找解法 (i.e. 方向性)。另外作者有提到文章是假設你已經對 FreeBSD 生態算熟悉 (像是 Ports 以及 /etc 下設定檔習慣的格式與設定方式):

Unlike my usual posts, this time I'm going to assume you're already pretty familiar with FreeBSD.

然後有點無奈的地方... 即使是 2012 年的電腦,為了 driver 問題他還是得跑 -CURRENT

In my case, I run 12-CURRENT so I can take advantage of the latest Intel drivers in the graphics/drm-next-kmod port.

這有點苦 XD

Slack 推出 Private Shared Channel,在兩個團體中間開 Private Channel

Slack 推出的新功能 Private Shared Channel:「Private shared channels are now available」,當然,這是付費功能 XD

Shared channels (beta) are currently only available for paid teams on Standard and Plus plans; Enterprise Grid support will be coming soon.

兩個都用 Slack 的團體可以開 Shared Channel,但之前只支援 Public Channel (參考「兩個都用 Slack 的公司可以直接在 Slack 上合作了」),現在則是支援 Private Channel 了。

可以兩個團體都是 Private:

也可以是單邊 Private,對另外一邊完全開放:

這個功能主要是用在 secret project 但又需要跟外部溝通的情況...

Archives