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 網頁伺服器

隨著資安意識提升、 Google 把網站的 https 列為搜尋引擎的排行指標,越來越多的網站開始導入 https 以確保伺服器以及使用者端兩個端點之間的安全溝通,先前在 10 web server online https/ssl testing services 有列出了一些可以協助網管人員測試網頁伺服器安全性強度的服務(注意是”網頁伺服器”而不是”網頁應用程式”),讓大家可以參考看看,其中 Qualys SSL LabsSSL 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資訊隱藏起來,那接下來就講這次的重點,關於伺服器的安全性設定以及該如何提高分數!

閱讀全文

11 web server online https/ssl testing services

http/2.0 will need encryption, also Google says HTTPS is a ranking signal – https://www.peterdavehello.org/2014/08/google-https-as-a-ranking-signal/, after set up https on our websever, what should we do next? It’s to confirm and make sure the cer and configure is safe enough to prevent from attack, here are some online testing service to help you confirm your cert and config on your webserver.

SSL Server Test by Qualys, Inc. SSL LABS (supports IPv6):
https://www.ssllabs.com/ssltest/
qualys_ssl_labs

qualys_ssl_labs_2

SSL Checker – SSL Certificate Verify:
https://www.sslshopper.com/ssl-checker.html

ssl_shopper

FairSSL BlueSSL Online Server SSL Test:
https://www.fairssl.se/en/ssltest

閱讀全文

[Google] HTTPS as a ranking signal

security

原文 : HTTPS as a ranking signal

大意是Google很重視安全,除了自家產品預設都是走https外,也希望讓整個網路世界更佳的安全,所以網站有沒有使用https來保障傳輸之間的加密也成了Google搜尋引擎排序演算法的一部份,但目前比重仍然低於其他項目,例如[內容品質]這個項目,但為了鼓勵所有網站從http轉到https,之後可能會增加權重

然後接下來幾個禮拜Google會發布一些優秀的實作細節資訊來幫助大家更容易使用TLS加密,並且避免犯上一些常見的錯誤,例如要選擇怎樣的憑證、protocol-relative URL之類的,實在是就甘心…

所以走https可能會變成SEO要做的事情之一、而免費的StartSSL可能又會突然爆走然後暫停申請xD?

不知道之後Extended Validation、憑證的class、簽憑證的機構對於ranking的影響又是多少?