起因:
部落格之前一直serve在github.io上面,由於github訪問速度實在是慢,所以打算遷移到自己買的阿里雲伺服器上。
但是,當我把自己的域名解析到阿里雲伺服器上時, wtf,返回的頁面居然是一個阿里雲的頁面,要求我對伺服器進行備案。
備案?emmm...可以接受。我點進去, 結果發現下面這些東西。。。。
20個工作日!還能不能讓人好好玩耍了!
所以如何繞開煩人的備案?
我發現當我只是通過ip訪問時, 一切正常; 當我使用域名訪問時,則返回阿里雲的備案頁面。而我的域名又是在騰訊雲買的, 所以可以斷定:這是一起http劫持事件
。
阿里雲劫持了我的http請求,判斷是通過域名訪問, 則篡改我的http響應。如何解決呢?https可以完美解決這種問題。
這裡大家好像都奇怪為什麼https可以繞過備案,我補充一下:https會對資料進行加密,可以避免中間商對資料進行修改。經常發現登陸某些網站被植入聯通的廣告,實際就是運營商修改了響應。如果換成https,運營商將無法篡改你的響應。
Let's Encrypt
黑喂狗,下一步就是要讓服務可以通過https來訪問。
那麼問題來了,https要求有一張受瀏覽器信任的證書。這時, Let's Encrypt 作為一個免費、受信任廣的證書籤發機構,自然成為了我的首選。
但是,就在這時,我踩了兩個坑。
騰訊雲域名解析
let's encrypt是一家境外的CA, 所以在選擇線路型別時需要選擇預設。我當時選擇了境內而不自知,費了一番功夫才發現原來境外解析不了這個域名。
阿里雲的篡改http響應
let's encrypt 給你簽發證書的條件是證明這個域名是你的。
有兩種方式, 一種是webroot, 即你在你的域名解析到的伺服器的80埠上serve一個let's encrypt 指定的頁面。即我訪問http://www.example.com/letsencrypt,返回的需要是let's encrypt指定的文字。
我一開始就是用的這種方式,使用了let's encrypt 的certbot的webroot模式去驗證。結果發現TM返回的response被阿里雲劫持了
。發現這裡繞了個圈,又回來了。
還好let's encrypt提供了另一種方式:域名解析指定的txt。這就好辦多了, 類似下面這樣配置域名解析就可以了:
然後你可以獲得let's encrypt給你簽發的證書, 在/etc/letsencrypt/live/
域名/路徑下。
上nginx配置
最後用nginx 為你的服務serve一下即可。上nginx配置:
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
root /root/workspace/eltonzhong.github.io;
ssl_certificate "/etc/letsencrypt/live/therollingstones.cn/cert.pem";
ssl_certificate_key "/etc/letsencrypt/live/therollingstones.cn/privkey.pem";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
}
複製程式碼
The end
總體還是蠻簡單的,只要不像我一樣愚蠢地踩到騰訊雲域名解析路線的坑即可。 謝謝閱讀,如果覺得有幫助,可以點個贊嗎~謝謝!