Announcing SPDYCheck: The SPDY Lint Tool
Steam seems to be building up behind SPDY, the next generation web transportation protocol. I wrote back in June that the majority of web browsers speak SPDY, and the majority of web servers are capable of speaking SPDY. Last week, the IETF rechartered the HTTP Working Group to develop HTTP/2.0 based on SPDY. While the final HTTP/2.0 protocol may look different than SPDY, the IETF works on “rough consensus and working code”. That SPDY exists, has gone through 3 major protocol versions, and is running in the wild on some of the largest websites in the world will greatly influence the final result of HTTP/2.0.
All of this means that SPDY, and not alternatives like HTTP Speed+Mobility, is the future for delivering content quickly and efficiently to browsers. As the interest in SPDY increases so will the number of sites that want to implement SPDY. We need tools to help us validate that a SPDY-enabled web server is working properly and provide guidance on how to optimize the SPDY experience. Unfortunately, when I went looking last week, no such tools existed. So I decided to write one.
I’m happy to announce SPDYCheck.
SPDYCheck is a online tool that verifies the many different things a website must do to support SPDY. SPDYCheck also tests a test for best practices which ensures SPDY is used whenever possible. SPDYCheck is completely free: there are no accounts, no registration, no emails, or anything like that.
Currently, SPDYCheck validates that a web server can properly negotiate a SPDY connection and send traffic over the connection. I know that sounds simple. It should be boolean right? SPDY works, yes or no? SPDY support is more complex than that and SPDYCheck’s tests are actually quite involved. Here is how SPDYCheck tests a website.
SPDY works on top of SSL, so the first thing SPDYCheck does is to try and communicate with a website using SSL. This is where the majority of sites will fail, since most sites on the Internet don’t have SSL enabled.
Testing for SSL connectivity is a 2 part job. The first part is ensuring that a network service is listening for and responds to incoming traffic on port 443, the port used by SSL.
Just because something is listening on 443 doesn’t mean it speaks SSL. Misconfigured servers or even network security devices like firewalls or IDS/IPS systems can close your connection before SSL traffic is sent. In the screenshot below, we see that the Strangeloop Networks website does have something listening on port 443, but closes the SSL connection during the handshake.
This is a different condition than the Zoompf website, which simply does not support SSL at all. All Zoompf needs to do is turn SSL on, whereas Strangeloop is actually having network or configuration problems. To help detect situations like this, SPDYCheck performs a separate “Does port 443 speak SSL?” test after the initial “Can I talk to port 443?” test.
SSL Certificate Checks
All SPDY communication travels over SSL. Any problems your browser encounters establishing that SSL connection prevents SPDY from working. So a required step of SPDY support is that SSL is properly implemented.
The most common reason a browser aborts an SSL connection is an invalid X.509 certificate. The server presents the client with an X.509 certificate to verify its identity as part of the SSL handshake. This certificate is how your browser knows that the bank website you are talking to really is your bank’s website and not an impostor.
If there is a certificate error, the browser presents a scary box to the user (shown below), or automatically quits, depending on the settings. In the screenshot below we see the CloudFlare blog has an invalid certificate which stops the SSL connections and thus prevents the use of SPDY.
A X.509 certificate can be invalid for several reasons including it was signed by an untrusted party, it is expired, it is self-signed, or it was issued for a different website. SPDYCheck tests for all of these issues.
NPN Extension and SPDY Support
SSL was designed to be used with HTTP. It does not contain a native mechanism to tell the browser to use a different protocol than HTTP, such as SPDY. Instead, SPDY-enabled web servers include an SSL extension, Next Protocol Negotiation (NPN) extension, in its
ServerHello message during the SSL handshake. This extension allows the server to provide a list of protocols it support as well as the version number of each protocol. Without an NPN extension, the web server cannot tell the browser it supports SPDY. Even a SPDY supporting browsers communicating with the server will HTTP because the browser is not aware their are other options. This is where the majority of SSL-enabled websites fail in SPDYCheck. They need to update their SSL software to support the NPN extension to advertise SPDY support.
Now, just because a website is including an NPN extension doesn’t mean that SPDY is one of the protocols it supports. Facebook includes an NPN extension in its
ServerHello message, but the only protocol it lists is
http/1.1! So Facebook has put the infrastructure for SPDY support in place, but has not flipped the switch to tell browsers to use SPDY! It’s possible that Facebook is conducting a controlled experiment and only allowing SPDY for certain website visitors.
Detecting Supported Servers
If an SSL-enabled site doesn’t currently use SPDY, SPDYCheck will try to determine if the web server is capable of support SPDY and report its findings. SPDYCheck does this by examining the HTTP
Server response header from the website and comparing against web servers with known SPDY support such as Apache or nginx. If you are using Microsoft’s IIS server, SPDYCheck will tell you the web server will not support SPDY as Microsoft has not committed to adding SPDY support.
Future Thoughts and Closing
There is a lot of room from improvement with SPDYCheck. For example, currently SPDYCheck does not perform any checks beyond the SSL handshaking phase. There are all sorts of performance features instead of SPDY that should be tested such as Server Push and Server Hints. SPDYCheck should also check for recent CRIME weakness, discussed in depth last month, which in turn affects how HTTP headers get compressed inside of the SPDY stream. If you have an idea about something that SPDYCheck should do, please contact me.
I hope you find SPDYCheck useful. Even while testing over a limited number of sites I found all sorts of strange and misconfigured SPDY servers, such as the Facebook example above. SPDY is a far more complex protocol than HTTP and I believe SPDYCheck will help the community properly implement SPDY-enabled websites and make the web faster.