How to detect if a server is using SPDY

Question

Any way to detect if a remote website supports SPDY and what version it is?

Something I can use from the command line like a bash script.

Tried sending custom User-Agent headers with curl but can't get any kind of response headers that would help me.

The idea is to be able to get SPDY:true/false Version:3.1/3.0... for any domain.

Superficial

Are you going to write a program to do this, or do you want this program to be written for you? – Conidium

I was hoping there was something ready out there that I could use in a bash script. – Superficial

Answer 1

openssl s_client -connect google.com:443 -nextprotoneg ''
CONNECTED(00000003)
Protocols advertised by server: spdy/3.1, spdy/3, http/1.1

Superficial

This command won't work if you are using openssl 0.9.8. If you are on a Mac you can update openssl with brew: apple.stackexchange.com/a/126832/78754 – Bloomery

My server using openssl v1.0.1 and this command helped. Thank a lot! – Antelope

Answer 2

The SPDY protocol negotiation happens during the initial TLS handshake.

There are currently two ways to negotiate the protocol: the older one is called NPN (https://datatracker.ietf.org/doc/html/draft-agl-tls-nextprotoneg-04). In the ClientHello TLS message the client sends the NPN extension with ID 0x3374. The server replies with a ServerHello TLS message that also contains the list of protocols supported by the server also in a NPN extension. The client then chooses the protocol and sends its choice, encrypted, to the server.

The newer method has been designed for HTTP 2.0 and is called ALPN (https://datatracker.ietf.org/doc/html/draft-ietf-tls-applayerprotoneg-05). The ClientHello TLS message contains the ALPN extension with ID 0x10. The client, this time, sends the list of protocols supported and the server replies with a ServerHello TLS message that contains the protocol chosen by the server, also in a ALPN extension.

In both the NPN and ALPN extension the list of protocols is sent as strings such as http/1.1 or spdy/3.

Once the protocol has been chosen, the TLS handshake continues and then both parties will start to speak immediately the protocol that they have chosen.

The only way to be aware of negotiation of the protocol is therefore to use TLS and to have a client that exposes the protocol negotiation extensions. Each client does that in a specific way, but there is not yet support for bash scripts, as far as I know.

HAProxy for example has support for both NPN and ALPN (http://cbonte.github.io/haproxy-dconv/configuration-1.5.html) and Jetty 9.2 too has support for both NPN and ALPN (both for clients and servers).

Other servers like Nginx or Apache have support for NPN with patches for ALPN (since it will be needed by HTTP 2.0 anyway).

NPN will eventually fade away; Google's Adam Langley has stated that NPN will be deprecated in favour of ALPN.

Flanigan

So you recommend using wireshark to check for SPDY? Any way to automate this process? – Superficial

Wireshark is certainly an option. The programmable option is to find an API that allows you to set/inspect TLS extensions. I know that Java does not provide one (yet), but other languages/platforms may. The Jetty project has API for both NPN and ALPN in Java, but they cannot be used together. By using the Jetty APIs it would be fairly easy to detect SPDY support (that's what the Jetty SPDY client does). – Flanigan

I think this wrongly downvoted answer is better than the accepted one. +1 – Melmela