Home » Posts tagged "http" (Page 3)

Apache 的 Optionsbleed

Apache 也出了類似 Heartbleed 的包:「Apache bug leaks contents of server memory for all to see—Patch now」,原文出自「Optionsbleed - HTTP OPTIONS method can leak Apache's server memory」。

這掛上 CVE-2017-9798 了,影響版本包括了:

This affects the Apache HTTP Server through 2.2.34 and 2.4.x through 2.4.27.

發生在對 OPTIONS 處理出問題:

Optionsbleed is a use after free error in Apache HTTP that causes a corrupted Allow header to be constructed in response to HTTP OPTIONS requests. This can leak pieces of arbitrary memory from the server process that may contain secrets. The memory pieces change after multiple requests, so for a vulnerable host an arbitrary number of memory chunks can be leaked.

就... 更新吧 @_@

Mozilla 的提案「HTTP Immutable Responses」

狀態已經是 Category: Standards Track 了,RFC 8246 的「HTTP Immutable Responses」:

The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.

Cache-Control 介紹了 immutable,像是這樣:

Cache-Control: max-age=31536000, immutable

依照 MDN 上的資料 (Cache-Control - HTTP | MDN),目前只有 EdgeFirefox 支援,不過既然成為標準了,後續其他瀏覽器應該都會支援 (吧):

nginx 的 mirror 功能

nginx 1.13.4 出的新功能,ngx_http_mirror_module

The ngx_http_mirror_module module (1.13.4) implements mirroring of an original request by creating background mirror subrequests. Responses to mirror subrequests are ignored.

範例其實就講的還蠻清楚的:

location / {
    mirror /mirror;
    proxy_pass http://backend;
}

location /mirror {
    internal;
    proxy_pass http://test_backend$request_uri;
}

如果拿 nginx 當 load balancer 的人,可以用這個功能做些事情...

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

curl 的 refactor 減少 malloc() 的次數

curl 的作者 Daniel Stenberg 寫了一篇關於他 refactor 大幅改善了 curl 的效能:「Fewer mallocs in curl」。

藉由大幅減少 malloc() 次數,在抓大檔案時會有明顯的改善:

7.54.1-DEV repeatedly performed 30% faster! The 2200MB/sec in my build of the earlier release increased to over 2900 MB/sec with the current version.

另外如果對 localhost 抓 80GB 的話,可以看到時間大幅縮短:

Old code:

real    0m36.705s
user    0m20.176s
sys     0m16.072s

New code:

real    0m29.032s
user    0m12.196s
sys     0m12.820s

Cloudbleed:Cloudflare 這次的安全問題

Cloudflare 把完整的時間軸與影響範圍都列出來了:「Incident report on memory leak caused by Cloudflare parser bug」。

出自於 2/18 時 GoogleTavis Ormandy 直接在 Twitter 上找 Cloudflare 的人:

Google 的 Project Zero 上的資料:「cloudflare: Cloudflare Reverse Proxies are Dumping Uninitialized Memory」。

起因在於 bug 造成有時候會送出不應該送的東西,可能包含了敏感資料:

It turned out that in some unusual circumstances, which I’ll detail below, our edge servers were running past the end of a buffer and returning memory that contained private information such as HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data.

不過這邊不包括 SSL 的 key,主要是因為隔離開了:

For the avoidance of doubt, Cloudflare customer SSL private keys were not leaked. Cloudflare has always terminated SSL connections through an isolated instance of NGINX that was not affected by this bug.

不過由於這些敏感資料甚至還被 Google 收進 search engine,算是相當的嚴重,所以不只是 Cloudflare 得修好這個問題,還得跟眾多的 search engine 合作將這些資料移除:

Because of the seriousness of such a bug, a cross-functional team from software engineering, infosec and operations formed in San Francisco and London to fully understand the underlying cause, to understand the effect of the memory leakage, and to work with Google and other search engines to remove any cached HTTP responses.

bug 影響的時間從 2016/09/22 開始:

2016-09-22 Automatic HTTP Rewrites enabled
2017-01-30 Server-Side Excludes migrated to new parser
2017-02-13 Email Obfuscation partially migrated to new parser
2017-02-18 Google reports problem to Cloudflare and leak is stopped

而以 2/13 到 2/18 的流量反推估算,大約是 0.00003% 的 request 會可能產生這樣的問題:

The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests).

不過不得不說 Tavis Ormandy 真的很硬,在沒有 source code 以及 Cloudflare 幫助的情況下直接打出可重製的步驟:

I worked with cloudflare over the weekend to help clean up where I could. I've verified that the original reproduction steps I sent cloudflare no longer work.

事發後完整的時間軸:

2017-02-18 0011 Tweet from Tavis Ormandy asking for Cloudflare contact information
2017-02-18 0032 Cloudflare receives details of bug from Google
2017-02-18 0040 Cross functional team assembles in San Francisco
2017-02-18 0119 Email Obfuscation disabled worldwide
2017-02-18 0122 London team joins
2017-02-18 0424 Automatic HTTPS Rewrites disabled worldwide
2017-02-18 0722 Patch implementing kill switch for cf-html parser deployed worldwide
2017-02-20 2159 SAFE_CHAR fix deployed globally
2017-02-21 1803 Automatic HTTPS Rewrites, Server-Side Excludes and Email Obfuscation re-enabled worldwide

另外在「List of Sites possibly affected by Cloudflare's #Cloudbleed HTTPS Traffic Leak」這邊有人整理出受影響的大站台有哪些 (小站台就沒列上去了)。

Plurk 的 API 將在五月強制走 HTTPS

Plurk 的 API 之前一直都是走 HTTP,現在總算是要改 HTTPS 了,出自這邊

有在用噗浪 API 開發程式的噗友們請注意~Plurk API 將於5月1日之後全面強制改用 HTTPS 更安全的通訊協定。如果您在這之後仍使用 HTTP 來呼叫 API,將會被 301 Moved Permanently 重導到 HTTPS 的版本,而這非常可能導致您原來的程式無法正常運作,請儘速更新您的程式喔~

不過官網還沒強制切到 HTTPS 上...

Cloudflare 因為閏秒炸掉...

Cloudflare 這次閏秒炸掉:「How and why the leap second affected Cloudflare DNS」,影響範圍包括了 DNS query 與 HTTP request:

At peak approximately 0.2% of DNS queries to Cloudflare were affected and less than 1% of all HTTP requests to Cloudflare encountered an error.

主要的原因在於 Gotime.Now() 不保證遞增:

RRDNS is written in Go and uses Go’s time.Now() function to get the time. Unfortunately, this function does not guarantee monotonicity. Go currently doesn’t offer a monotonic time source (see issue 12914 for discussion).

修正的方式是針對時間回朔時處理:

In this patch we allowed RRDNS to forget about current upstream performance, and let it normalize again if time skipped backwards.

應該是因為 Cloudflare 這段程式還沒遇過 leap second 造成的...

下一個版本的 Chrome (56) 將會對要求卡號或是密碼的 HTTP 站台標示「Not Secure」

如同之前在「Google Chrome 56 將會對 HTTP 網站標示「Not secure」」提到的規劃,Google Chrome 56 (也就是下一個版本) 將會對要求卡號或是密碼的站台標示「Not Secure」:「Chrome 56 Beta: “Not Secure” warning, Web Bluetooth, and CSS position: sticky」。

比較九月的 screenshot 與最近的 screenshot,從「Not secure」變成「Not Secure」了... 這是九月的:

而這是最近的:

可能是這樣標示會讓使用者更有警覺?

Archives