Category Archives

17 Articles

Let’s Encrypt集中化管理

9   4593 轉為簡體

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   39794 轉為簡體

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

先看配置:

假設:

審查機關擁有運營商級別的入侵檢測設備(比如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   64113 轉為簡體

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

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

使用shared dict

Read More

nginx/openresty的一些記錄

28   29437 轉為簡體

日誌

屏蔽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()產生毫秒精度時間

mongo好大一個坑

2   69672 轉為簡體

因為種種原因被逼着寫mongo……

作為一個初學者,我發現了幾個坑:

新的協議沒文檔

官網上只有Legacy Driver Implementation Documentation這箇舊的協議文檔,新的文檔的鏈接是一個死循環,繞一圈可以回到原地(不信你試試)。可能有用的只有一個視頻,還是2011年的,不想看了,哦草。這裡還有一個2013年的,從stackoverflow看來的

當然官方給的各種語言的SDK里倒是一直在更新的。

但是給個文檔會死啊!

雖然是在用lua寫,所以本來也是作死。

但是給個文檔會死啊!

因為lua-resty-mongol沒有支持新協議,所以會有這麼個問題

在update里使用$pull,lua-resty-mongol用getLastError取被修改的行數,永遠是返回1(這特么誰設計的),沒辦法知道改成功了沒有。只能update前後各find一次比較了哈哈哈哈哈哈。

設計太坑爹

除了之前的getLastError永遠返回1以外,還有一個問題:

之前是2.4.x版本,升級到3.x之後,告訴我admin庫需要升級,否則沒法登陸,而且需要用2.6.x版本來升級

呵呵

還有一個問題:

現在我有這麼個文檔post,每個記錄是這樣的:

首先(只)取所有評論的話是沒有問題的↓:

現在我想取出_id是5下的前15條評論

這麼寫↑,post_content也出來了,post_content好大的啊,不想取怎麼辦啊

這麼寫↑,_id沒了,其他post_content還在

↑並沒有什麼卵用


↑這樣_id有,其他鍵沒了。

所以結果是_id必須留着……

沒錯我是強迫症,強迫症多着呢

 

從目前的我所遇到的情況來看,似乎mongodb能幹的奇妙功能用SQL數據庫一樣能搞,無非要再配合別的靠譜的nosql數據庫(比如redis這種)。至少寫了代碼還能預測能發生什麼。像mongo這樣寫着寫着給你個驚♂喜的實在受不了了。哦不過也有可能被虐着虐着就有感♂覺了呢(ง •̀_•́)ง

 

PS : 我是mongo初學者,歡迎大神來鞭撻我