Can I use (瀏覽器功能支援速查網站) … 終於加入 SSL / TLS 的支援資訊

caniuse 是一個整理了各個瀏覽器針對不同功能的支援性做整理的專案,網頁前後端的開發者需要速查某一個 feature 有沒有被特定的 browser 支援、或是被各個瀏覽器支援的情形的時候,caniuse 算是一個方便好用的服務, 網站本身丟在 http://caniuse.com/ (很可惜沒走 https),專案則是 open source 丟在 GitHub 上: https://github.com/Fyrd/caniuse

CanIuse.com

直接在網站首頁的 Can I use ______ ? 的搜尋框輸入相關的關鍵字,下面會列出相關的結果,首頁本身也有列出一些 features 可以給大家參考,如果想對搜尋的結果做進一步的設定,Settings 裏面也可以控制譬如像是針對哪些功能分類、不同的瀏覽器做搜尋、只顯示市佔率超過多少百分比的瀏覽器、排序等等的資訊,不過很可惜的是一直沒有 https / SSL /TLS 支援性的相關資訊,剛剛在 Fyrd/caniuse#1144 這個 GitHub 上的討論串可以看到在今天稍早作者已經表示加入對應的支援了 (在 Fyrd/caniuse@960f5419a ),雖然拖了很久,不過總算是開始把這部份補起來了。

SSL 和 TLS 1.0 的部份分別是現在瀏覽器全面棄用/支援的兩個協定,不過在 caniuse 上沒有獨立的頁面,只會在搜尋結果呈獻說明:

而 TLS 1.1 和 TLS 1.2 則有獨立的頁面顯示目前瀏覽器的支援情況:

TLS 1.1: http://caniuse.com/#feat=tls1-1
CanIuse_TLS-1.1

繼續閱讀

除了 Let’s Encrypt 以外的免費 SSL 憑證

使用 SSL 憑證一直以來的一個門檻是費用問題,在沒有閒錢 (對於小朋友來說還有付款方式的問題) 的情況下想要練習架設有 https 保護的網站而且要能正常運作就有其一定的難度,自簽憑證雖然也可以達到類似的效果,不過整個流程以及最終驗證的方式都還是跟實際上有出入,即便這幾年已經有了很多便宜的 SSL,這個門檻一直都還存在,這也是為什麼會蹦出一個 Let’s Encrypt 要來推免費的 SSL 憑證的主因,目的就是降低甚至消除門檻、普及網路連線的加密, Let’s Encrypt 同時也推自動化工具來簡化整個流程,Let’s Encrypt 推出至今已經簽出超過五百萬張憑證了 ,既然不用錢、也有自動化工具,那為什麼還會用到別家的憑證?

我要找 Let’s Encrypt 以外的免費 SSL 憑證主要有兩個原因:

  1.  Let’s Encrypt 的整個簽證流程不同於以往 (產生 private key, CSR 再送給廠商,完成驗證後簽發),要讓沒經驗的人來學怎麼做這件事情我還是偏好走傳統的方式整個帶過一遍,而不是只透過自動化工具進行部署,這樣觀念上還是會比較好一點,另外就是現在的自動化工具只適用於 domain validation (dv) 的驗證,如果要有 OV (Organization Validated) 或 EV (Extended Validated) 的話還是需要走傳統的作法。
  2. Let’s Encrypt 憑證有效期較短 ,雖然這個問題可透過工具自動 renew 來補足,但仍有其限制,使用憑證的主機如果沒辦法定期或常態對外連網就不見得適用,例如我想要在內部網路環境架設受簽證保護的內部服務,又不想要平常就把對外網路打開、或是自簽憑證再把憑證塞到使用者裝置上等情況。

目前看到的兩家免費憑證,一家是老牌的 StartSSL 、 另一家是對岸的 WoSign,兩者我都有用過,前者曾經被爆出一些潛在的安全性問題,但是問題持續的時間看起來不長,那後者本身是對岸的公司,所以可想而知對一些人來說是有潛在的安全疑慮的,不過不考慮這些為安全考量以及政治因素,丟給新手拿來當練習我覺得是很好的選擇,不知道還有沒有其他可以推薦的?

WoSign 的免費憑證申請在這邊:https://buy.wosign.com/free/?lan=en,一個憑證可以簽 5 個 domain,有效期限可選則一年或兩年,要額外數量的網域認證或是更長的年限就必須另外付錢,不考慮是對岸公司疑慮的情況下,WoSign 本身因為是對岸公司,有提供簡體中文的說明文件、且產生的憑證會按照不同的 httpd 如 IIS、nginx、apache 不同的需求分開提供,不用煩惱Intermediate的問題,我覺得對新手來說是很好的入門。

WoSignFreeSSL

WoSign 申請 Certificate 的畫面

繼續閱讀

Let’s Encrypt 已經簽出超過五百萬張憑證了 …

Progress Towards 100% HTTPS, June 2016 這邊看到的資訊,Let’s Encrypt 從去年 (2015) 年底 public beta 到現在已經簽署超過 500 萬張的憑證,扣掉被撤回以及已經過期的,大概有 380 萬張憑證還是有效的,而這些有效的憑證總共涵蓋了超過 700 萬個獨立的網域 (一張憑證可以簽給多個 domain),因為 Let’s Encrypt 憑證有效期只有 90 天,所以可以想像最近這三個月簽出的憑證數量佔的比例非常的高,官方也用時間/憑證數量的關係畫了一張圖出來給大家參考:

le-certs-issued-june-22-2016

其中有一些成長比較快的時間點是其他網站服務、虛擬主機、CDN 等廠商把 Let’s Encrypt 整合進自家服務的結果,例如文中提到的 OVHWordPress.comAkamaiShopifyDreamhostBitly,另外像是 KeyCDNCDN77 等 CDN 廠商也都陸續把 Let’s Encrypt 憑證簽署自動拉近自家的服務中,使用者因此在價錢以及部署的流程上受惠,同時對 Let’s Encrypt 的推廣及使用量產生相當程度的助長。

文章最後提到 Let’s Encrypt 在去年底剛公開測試的時候,整個 www 大概只有 40% 的網站有使用 https,現在已經長到 45% 了,可以預期今年 (2016) 這個數字可以長到 50% 以上,怎麼看都覺得很驚人!

The new security panel for Chrome/Chromium from v48

Google announced the new security panel for Chrome from v48 in Chrome’s DevTools, this feature can help users easily know the security information for every network connection/request in a certain website, including the certificate info, now it’s been easier to debug what’s the reason why a website didn’t get a green lock on the url bar(A website using https with enough strengh will have a green lock icon).

Screenshots as example (using my blog):

www.peterdavehello.org_chrome_security_panel2

www.peterdavehello.org_chrome_security_panel

References:

Security Panel debuts in Chrome DevTools
https://developers.google.com/web/updates/2015/12/security-panel

Introducing the Security Panel in DevTools – Chromium Blog
https://blog.chromium.org/2016/01/introducing-security-panel-in-devtools.html

自行架設的 BitBucket server 在 git push 遇到 RPC failed 的問題

先說 … 我個人覺得 BitBucket 不是很好用,尤其是自己架設 … 很多眉角、小問題要處理

這次的環境是 BitBucket + nginx (reverse proxy) + git https access 會遇到的問題 (基本上是版本無關)

症狀長這樣:

$ git push origin master
Counting objects: 4372, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (138/138), done.
error: RPC failed; result=22, HTTP code = 413
Writing objects: 100% (147/147), 1.10 MiB | 0 bytes/s, done.
Total 147 (delta 75), reused 0 (delta 0)
fatal: The remote end hung up unexpectedly

從 http 413 的解釋 Request Entity Too Large 可以看出來是 request 太大了,我猜是 git 的 objects pack 吧

解法是調整 nginx 的 client_max_body_size,預設值是 1M,我們可以把他改為更大的值,或是改為 0 來停用大小檢查

例如:

server {
#…
client_max_body_size 1000m;
#…
}

改完之後重新啟動 nginx 就沒問題了!

我範例是把 size 調到 1000m ,因為 cdnjs 的 objects pack 已經長到 900MB 了,如果你沒有一個特別肥大臃腫的 git reposiroty,我想應該1000m已經夠用了,剛剛把linux kernel 拉下來看,objects pack 也大概是 1GB左右而已

至於要用 nginx 來做 reverse proxy 的原因,主要是 Bitbucket 安裝完後 Tomcat 預設沒辦法 bind 在 1024 以下的 port ,加上他的 https 很難設定,為了拿到 A+ 確保https 安全強度,這段還是讓 nginx 來做比較簡單一點,也許之後有空會想辦法把 static file 讓 proxy 來做 cache 提升一些速度。