Facelift: Upgraded to Twenty Twelve

I’ve upgraded to the new WordPress Twenty Twelve theme.  I’m pretty impressed with the look.  I did have to go through and remove my “featured images,” since I upgraded from Twenty Ten.  Twenty Twelve does not use a banner image and during the live preview I noticed that it just stuck the featured image at the top of the post, which didn’t work for me.

Also, as this probably will affect a very small amount of users (probably just me 🙂 ), it appears that HTTPS Everywhere makes the page look wonky (see below).  Of course, I’m using Chrome and HTTPS Everywhere is still in alpha for Chrome…  Begrudgingly, I turned off WordPress.com from the HTTPS Everywhere config, but I’ve had a similar problem on some sites, so I’ll have to check the HTTPS Everywhere mailing list.  However, the mobile version of the site looks great!

Viewing the site with Chrome and HTTPS Everywhere turned on… should be called the “Nineteen Ninety Eight” Theme.

One of the features in Twenty Twelve that I’m looking forward to is the static homepage.  It’s a nice customization option for a splash page and should look good, once I figure out what to put there.  Inline \LaTeX has a nice drop shadow-like look too!  The only thing I’m missing from the old look is my photo of the Jungfrau, but maybe it’ll find a new home on the static homepage.

Mönch, Jungfrau, and Eiger

TLS False Start is dead

So for about a year and half, Chrome has been speeding up TLS / SSL connections by a mechanism called “TLS False Start.”  The performance improvements were impressive; False Start dropped connection times by 30% or just under 200 ms.  The details of TLS False start are described in this tech memo, but the basics are that the client starts sending application data immediately after the Change Cipher Spec and Finished messages, without waiting from the server.  This essentially removes one round trip across the network.  Actually, it’s quite clever since once the client has sent the Change Cipher Spec message, it has shifted over to the bulk encryption algorithm and finished the key exchange and doesn’t necessarily need to wait for the server to confirm.

However, the reasons for its demise are a bit comical and unfortunately False Start’s tragedy has much to do with a good protocol and restrictive implementations.   My favorite problem was that a major vendor of SSL Terminators (servers acting as the SSL / TLS endpoint, probably with hardware acceleration) has some sort of minor bug preventing the use of TLS False start.  The vendor refused to fix it.

One, fairly major, SSL terminator vendor refused to update to fix their False Start intolerance despite problems that their customers were having. I don’t believe that this was done in bad faith, but rather a case of something much more mundane along the lines of “the SSL guy left and nobody touches that code any more”. However, it did mean that there was no good answer for their customers who were experiencing problems.

I can see how this can happen and why the company wouldn’t want to fix it.  By the way, I’ll be returning to work in August… (no I don’t work for this vendor). 🙂

One of the frustrating aspect of protocol design is that there is a duality consisting of what the protocol says and the populous implementation.  Actually, its more of an oligarchy, where the most popular implementation sets the standard.

Well, you can still install HTTPS Everywhere in Chrome so that’s a good thing.  I highly recommend it.  Not only is supported by the EFF, a great organization, it’ll always attempt to use the https version of a website, making your web traffic more secure.

HTTPS Everywhere from the EFF

[UPDATE] For those with a Wireshark inclination, here are two captures of TLS False Start in action.

TLS False start in action on the client and server
False start on the client side only (chrome)