Category Archives

18 Articles

用 OpenResty 寫了一個 SNI 代理

0   14015 轉為簡體

功能類似於dlundquist/sniproxy

推薦 OpenResty 加上 stream 模塊和 ngx_stream_lua_module 模塊。在 1.9.15.1 上測試通過。

示例配置:

A Lua table sni_rules should be defined in the init_worker_by_lua_block directive.

The key can be either whole host name or regular expression. Use . for a default host name. If no entry is matched, connection will be closed.

The value is a table containing host name and port. If host is set to nil, the server_name in SNI will be used. If the port is not defined or set to nil, 443 will be used.

Rules are applied with the priority as its occurrence sequence in the table. In the example above, twitter.com will match the third rule rather than the fourth.

If the protocol version is less than TLSv1 (eg. SSLv3, SSLv2), connection will be closed, since SNI extension is not supported in these versions.

Let’s Encrypt集中化管理

9   11778 轉為簡體

Let’s Encrypt的證書籤發原理實際上和傳統的PKI一樣,只不過自動化完成了生成CSR和私鑰、提交CSR、取回證書的過程。

此外還要驗證域名所屬,這一部分和傳統的簽發機構是一樣的,不過傳統的簽發機構還允許我們使用域名whois中填寫的郵箱來驗證,而Letsencrypt貌似只能通過http challenge的方式來驗證。即和驗證服務器約定一個uri和隨機字符串,驗證服務器請求這一uri,如果得到的內容和約定的隨機字符串相同,則驗證通過。如圖所示:

letsencrypt_howitworks

官網上抄的)

這意味着我們得在每台部署https的前端的負載均衡服務器上都裝一個letencrypt工具。有沒有什麼集中化管理的辦法的呢?

實際上,由於challenge的uri的有規律,我們可以將前端服務器收到的這類請求代理到同一台專門用來簽發、更新證書的服務器上。如圖所示:

letsencrypt_howitworks_proxypass

  1. 當在服務器B上發起域名a.example.com新的簽發請求後,Let’s Encrypt的簽發服務器返回一個challange uri (8303)和response (ed98)。
  2. 服務器B使用webroot插件將這個uri和response寫入本地磁盤上對應的文件。
  3. Let’s Encrypt的簽發服務器為了驗證example.com的所屬,查詢到example.com指向前端服務器A,於是發送一個HTTP請求/.well-known/acme-challenge/8303到服務器A
  4. 服務器A反代這一請求到服務器B
  5. B讀取剛才第二步時寫入到response,返回到A;A返回到Let’s Encrypt的簽發服務器
  6. 驗證成功,發證!

然後,我們只要從服務器A上取回存儲在B上到證書就可以了。可以在B上做一個RESTful的api。注意要配置allow和deny。

A服務器(前端)的nginx配置如下:

B服務器的nginx配置如下:

然後在B上運行:

搭建一個不被審查的串流站點

17   48895 轉為簡體

原標題:被害妄想症該如何生存

先看配置:

假設:

審查機關擁有運營商級別的入侵檢測設備(比如GFW)

說明:

  1. 全站使用https,關閉SSLv3,關閉弱加密組件
  2. default_server開啟80端口,使用自簽名證書;真實需要訪問的域名(example.com)必須使用有效的證書,或者在本地信任根證書。注意example.com不能開啟80端口,且與default_server使用的證書不能相同。不要使用泛域名證書。這是為了防止審查機關通過直連IP查看返回的證書中的Common Name來得到真實域名。這樣配置之後,直連IP https://xxx.xxx.xxx.xxx默認是返回自簽名證書,無法得到真實example.com。
  3. 選擇性開啟autoindex,通過cookie鑒別。注意也可以通過HTTP Basic Authenication認證。對匹配文件夾的uri(”/”結尾)做認證,示例中只有帶cookie coo=coo的請求才會返回autoindex,否則返回404。
  4. 在location /中禁用目錄末尾自動加斜杠,因為如果自動加斜杠,審查機關可以通過暴力猜測出服務器上有哪些目錄確實存在(返回了301到末尾加/的url)。方法是if (-d $request_filename)返回404。

nginx 批量配置同步

0   71476 轉為簡體

在編譯了lua-nginx-module的nginx上,可以方便地使用shared dict特性,在不reload配置文件的情況下實現配置同步。

由於shared dict使用一塊共享內存,因此所有worker均可讀寫,也就不存在一致性的問題。

使用shared dict

Read More

nginx/openresty的一些記錄

28   41230 轉為簡體

日誌

屏蔽user-agent並屏蔽日誌

不屏蔽user-agent(允許其訪問),但屏蔽日誌

按uri屏蔽日誌(可以和上面的按user-agent用同一個變量來同時過濾uri和user-agent)

 

Header

按mime type設置緩存時間

防攻擊

簡單的無狀態cookie challenge(需要lua-nginx-module)

crawlers塊中可以手動填寫要屏蔽的IP

將其中的s改成隨機字符串+時間戳可以變成有狀態版本(需使用redis/memcached/shared memory存儲生成的隨機字符串)

將set-cookie改成通過js生成cookie可以變成javascript challenge,注意要在js里加上瀏覽器上下文判斷,如var cookie=location.protocol?cookie:””; 或者DOM操作

這裡有個更高級的輸驗證碼的示例

其他

植入cookie

需要注意的是使用ngx.time()產生秒級的時間,用來做隨機數種子可能會衝突,因此建議加上另外的隨機變量(如下面的例子用的是客戶端的ip) 可以使用ngx.now()產生毫秒精度時間