標籤彙整: tls

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 的畫面

閱讀全文 →

Test if your web server supports http/2.0 or spdy via Protocol Negotiation

發佈日期: 作者:
回覆

Cloudflare started to support http/2.0 in production environment yesterday(HTTP/2 is here! Goodbye SPDY? Not quite yet), not like NGINX open source version(NGINX Open Source 1.9.5 Released with HTTP/2 Support), which dropped spdy support, Cloudflare supports them both like Google and Facebook does. Cloudflare is not the first CDN company to support http/2, KeyCDN launched there http/2.0 support from the early Oct 2015(KeyCDN Launches HTTP/2 Support), cdn77 started their http/2.0 support since Aug 2015(HTTP/2 Support for All Customers), but both of KeyCDN and cdn77 doesn’t support http/2 + spdy, now Cloudflare supports both, so maybe it’s just worthy(BTW, akamai also support them both), without a doubt it’s a good very good news to us, but how to test if a web server support http/2.0? Here we go.

In the beginning, I think you should know a little bit about the Application-Layer Protocol Negotiation , on Wikipedia:

Application-Layer Protocol Negotiation, on Wikipediais a Transport Layer Security (TLS) extension for application layer protocol negotiation. ALPN allows the application layer to negotiate which protocol should be performed over a secure connection in a manner which avoids additional round trips and which is independent of the application layer protocols. It is used by HTTP/2.

We can use TLS-ALPN to get the supported protocols by the server desired order, here we will use OpenSSL client as an example.

On OpenSSL man page:

-nextprotoneg protocols
enable Next Protocol Negotiation TLS extension and provide a list of comma-separated protocol names that the client should advertise support for. The list should contain most wanted protocols first. Protocol names are printable ASCII strings, for example “http/1.1” or “spdy/3”. Empty list of protocols is treated specially and will cause the client to advertise support for the TLS extension but disconnect just after receiving ServerHello with a list of server supported protocols.

The syntax should be like this:
openssl s_client -nextprotoneg NULL -servername host.domain.name -connect host.ip.or.domain:port

Because there may be many domains pointing to a same IP address, we should tell the server which domain we are going to connect by servername, and I don’t want to get a verify error, so I will also tell OpenSSL the path we store certificates by CApath, for example, on Ubuntu 14.04 LTS:

[bash]
$ openssl s_client -CApath /etc/ssl/certs -nextprotoneg NULL -servername www.peterdavehello.org -connect www.peterdavehello.org:443 | grep ‘Protocols advertised by server’
[/bash]

We will get this result:

depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority
verify return:1
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
verify return:1
depth=0 C = TW, CN = www.peterdavehello.org, emailAddress = hsu @peterdavehello.org
verify return:1
Protocols advertised by server: h2, http/1.1

Which means www.peterdavehello.org wanna use http/2.0 first, and then http/1.1, if you do this test on www.google.com, you’ll get another result like this:

depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com
verify return:1
read:errno=0
Protocols advertised by server: h2, spdy/3.1, http/1.1

So we know that Google supports http/2.0, spdy/3.1 and http/1.1!

The funniest thing I noticed is that the result of Facebook is a little bit more complex and also unstable, test result 1:

depth=3 C = US, O = GTE Corporation, OU = “GTE CyberTrust Solutions, Inc.”, CN = GTE CyberTrust Global Root
verify return:1
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify return:1
depth=1 C = NL, L = Amsterdam, O = Verizon Enterprise Solutions, OU = Cybertrust, CN = Verizon Akamai SureServer CA G14-SHA2
verify return:1
depth=0 C = US, ST = CA, L = Santa Clara, O = Akamai Technologies Inc., CN = http2.akamai.com
verify return:1
Protocols advertised by server: h2, h2-14, spdy/3.1, spdy/3, http/1.1, http/1.0

Test result 2:

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, ST = CA, L = Menlo Park, O = “Facebook, Inc.”, CN = *.facebook.com
verify return:1
Protocols advertised by server: spdy/3.1-fb-0.5, spdy/3.1, spdy/3, http/1.1

I guess Facebook is still testing their http/2.0 feature.

用 nginx 建置一個 A+ 等級的 https 網頁伺服器

發佈日期: 作者:
2

隨著資安意識提升、 Google 把網站的 https 列為搜尋引擎的排行指標，越來越多的網站開始導入 https 以確保伺服器以及使用者端兩個端點之間的安全溝通，先前在 10 web server online https/ssl testing services 有列出了一些可以協助網管人員測試網頁伺服器安全性強度的服務(注意是”網頁伺服器”而不是”網頁應用程式”)，讓大家可以參考看看，其中 Qualys SSL Labs 的 SSL Server Test 算是近期非常熱門的一個測試跟服務，其測試報告以及評分標準算是非常簡單易懂，以截至目前為止(2015年10月25日)的最新版本”2009j (20 May 2015)“為例，給分主要從 A ~ F，Protocol support、Key exchange 及 Cipher strength 分別占總分的30%、30%及40%，相關的細節都可以在SSL Server Rating Guide (PDF) – Qualys SSL Labs 裡面找到，Qualys SSL Labs也提供了一份 SSL/TLS Deployment Best Practices Guide，但看起來近期沒更新就是了，停留在 Version 1.4 / 8 December 2014。

對於一些非網管或是相關背景的網站管理員來說，該如何有效的提升自己架設的伺服器安全性強度? 又如何改善各安全測試出來的分數? 由於最近有些人在問相關的問題，我找了一下發現好像沒有中文的資源在提供這方面的指南，所以決定野人獻曝一下稍微分享我知道的做法。另外必須說明的是，安全性跟方便性從以前到現在就是兩難，例如夠安全的密碼基本上都是由不同的元素以及夠長的長度組成，相對來講就會不好記，在伺服器安全性上的問題亦然，較好的安全性會使得 Windows XP，Java 6 的使用者受到影響，如果還有遇到這使用如此老舊軟體的使用者，還是勸他趕緊換個平台吧 …

開頭先說一個比較不影響這次評分 (https) 但大家可能也會想要處理的一塊，關於 Web server 的 response header 處理的部分，可以參考先前寫的 “用Apache/nginx&PHP架網站要注意的安全事項” ，將不必要的Server資訊隱藏起來，那接下來就講這次的重點，關於伺服器的安全性設定以及該如何提高分數！

閱讀全文 →