AFAIK there's no way to initiate TLS over a SPDY stream (i guess SPDY could be extended to add TLS handshake control frames, but that's downright crazy) which would mean that the third diagram is misleading. End to end SSL would not be possible with a SPDY proxy. Instead, the client's SSL connection would extend to the SPDY proxy, and the proxy would have it's own SSL (HTTP, HTTPS or SPDY) connection to the remote server. If that's the case, the proxy would have unencrypted access to all traffic.

This is arguably not a problem for clients that explicitly opt in for this sort of proxy setup. But it sounds like this is not the case for the Kindle Fire. Based on this article (i don't have a Kindle Fire to test this theory), i'm guessing the browser has custom CA's for the SPDY proxy so that the SPDY proxy can spoof any domain through the magic of SNI. If all this is true, then it's pretty evil. People who know enough to check for the "secure connection" badge in the browser would be fooled into thinking they have end to end encryption to the website they are viewing. In reality, the proxy, and whoever runs it, silently has complete access to your unecrypted traffic.

There's quite a few assumptions here. And I'm not a SPDY expert so I may be overlooking something. But this doesn't sound like an optimization i'd be comfortable with.