省頻寬的方法:終極版本...

看到「Three ways to reduce the costs of your HTTP(S) API on AWS」這邊介紹在 AWS 上省頻寬費用的方法,看了只能一直笑 XD

第一個是降低 HTTP response 裡沒有用到的 header,因為每天有五十億個 HTTP request,所以只要省 1byte 就是省下 USD$0.25/day:

Since we would send this five billion times per day, every byte we could shave off would save five gigabytes of outgoing data, for a saving of 25 cents per day per byte removed.

然後調了一些參數後省下 USD$1,500/month:

Sending 109 bytes instead of 333 means saving $56 per day, or a bit over $1,500 per month.

第二個是想辦法在 TLS 這邊下手,一開始其中一個方向是利用 TLS session resumption 降低第二次連線的成本,但他們發現沒有什麼參數可以調整:

One thing that reduces handshake transfer size is TLS session resumption. Basically, when a client connects to the service for the second time, it can ask the server to resume the previous TLS session instead of starting a new one, meaning that it doesn’t have to send the certificate again. By looking at access logs, we found that 11% of requests were using a reused TLS session. However, we have a very diverse set of clients that we don’t have much control over, and we also couldn’t find any settings for the AWS Application Load Balancer for session cache size or similar, so there isn’t really anything we can do to affect this.

所以改成把 idle 時間拉長 (避免重新連線):

That leaves reducing the number of handshakes required by reducing the number of connections that the clients need to establish. The default setting for AWS load balancers is to close idle connections after 60 seconds, but it seems to be beneficial to raise this to 10 minutes. This reduced data transfer costs by an additional 8%.

再來是 AWS 本身發的 SSL certification 太肥,所以他們換成 DigiCert 發的,大幅降低憑證本身的大小,反而省下 USD$200/day:

So given that the clients establish approximately two billion connections per day, we’d expect to save four terabytes of outgoing data every day. The actual savings were closer to three terabytes, but this still reduced data transfer costs for a typical day by almost $200.

這些方法真的是頗有趣的 XDDD

不過這些方法也是在想辦法壓榨降低與 client 之間的傳輸量啦,比起成本來說反而是提昇網路反應速度...

StackOverflow 預設全上 HTTPS 了...

HTTPS Everywhere 沒什麼感覺,但對於一般人應該不簡單,所以 Nick Craver (根本就是他們家非正式的 PR Engineer XDD 他這幾年寫了不少內部的資訊...) 寫了一篇關於上 HTTPS 的故事:「HTTPS on Stack Overflow: The End of a Long Road」。

其中他們為了支援舊設備 (沒有支援 SNI 的),決定直接把所有 wildcard 類的 SSL certificate 都包進去 (另外找 DigiCert 處理):

然後中間提到這個真的頗無奈的,抱怨 SVG 的 XML... XDDD:

Finding and killing these was a little fun because you can’t just search for "http://". Thank you so much W3C for gems like this:

<svg xmlns="http://www.w3.org/2000/svg"...

一條辛苦路 XD

Thawte (Symantec) 發出 www.google.com 的 EV SSL certificate

Google Online Security Blog 上公佈了一篇他們最近的發現,並且發佈 Google Chrome 的安全性更新:「Improved Digital Certificate Security」。

原因出自於 Thawte (Symantec) 發出 www.google.com 的 EV SSL certificate:

On September 14, around 19:20 GMT, Symantec’s Thawte-branded CA issued an Extended Validation (EV) pre-certificate for the domains google.com and www.google.com. This pre-certificate was neither requested nor authorized by Google.

GoogleCertificate Transparency 上發現:

We discovered this issuance via Certificate Transparency logs, which Chrome has required for EV certificates starting January 1st of this year. The issuance of this pre-certificate was recorded in both Google-operated and DigiCert-operated logs.

對應的 certificate 紀錄可以在「crt.sh | 9314698」這邊看到,包括了 public key 資訊。

然後 Google 跟 Symantec 確認後認定是內部測試造成的 (...):

During our ongoing discussions with Symantec we determined that the issuance occurred during a Symantec-internal testing process.

並且發出安全性更新把這把 key 放到 Google Chrome 的 revocation metadata 裡:

We have updated Chrome’s revocation metadata to include the public key of the misissued certificate. Additionally, the issued pre-certificate was valid only for one day.

一天的內部測試嗎?我怎麼覺得更像是 APT 攻擊?

最後補充一下,在 Google Chrome 裡面 *.google.com 的網段的 SSL certificate 是被特別保護的,可以參考「transport_security_state_static.json」這邊的 JSON 資料,裡面可以看到這幾段:

    {
      "name": "google",
      "static_spki_hashes": [
        "GoogleBackup2048",
        "GoogleG2",
        "GeoTrustGlobal"
      ],
      "report_uri": "http://clients3.google.com/cert_upload_json"
    },

以及:

    // (*.)google.com, iff using SSL, must use an acceptable certificate.
    { "name": "google.com", "include_subdomains": true, "pins": "google" },

也就是只有 Google 自己的 CA 與 GeoTrust 的 CA 是被允許發出 www.google.com 的 SSL certificate (至少在 Google Chrome 裡面會被保護到)。而 GeoTrust 也是 Symantec 的牌子。

如果讓我以陰謀論的角度來猜,這更像是在測試有會有哪些管道通報會讓 Google 發現。

DigiCert 考慮開放 .onion 的 SSL certificate 簽章

前陣子 Facebook 提供 Tor 的 hidden service 時還提供了 SSL certificate,是由 DigiCert 簽的:「Supporting the Anonymous Use of Facebook via Tor」。

而 DigiCert 打算開放給一般人申請 .onion 的 SSL certificate:「DigiCert Considering Certs for Hidden Services」。

這件事情除了在技術的角度很特別外,在政治面的角度也值得被拿出來討論,也就是 DigiCert 承認 .onionTLD

各家搜尋引擎 (像是 GoogleDuckDuckGo) 開始爬 .onion 的資料也應該是遲早的事情?