

SPDY of the Future Might Blow Your Mind Today - silvio
http://www.belshe.com/2011/11/17/spdy-of-the-future-might-blow-your-mind-today/

======
benburkert
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.

~~~
wmf
You might be able to run HTTP CONNECT over SPDY.

 _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._

I don't think this is correct, although I can't describe how Silk actually
works.

------
xenonite
speeding up that last mile concerned a lot of other people before, especially
on slow mobile connections.

One example is Opera, they are even compressing http data, pictures etc.
before transmitting to the client over a binary socket.

~~~
ajross
You don't make the same argument pivot yourself, but this is something that
crosses my mind every time I read about SPDY too. _All this stuff has been
done before_. It's not a new problem, and none of the old solutions caught on.
What makes SPDY special?

~~~
chc
Google makes SPDY special. If something is unquestionably useful but hasn't
caught on, what you have is fundamentally a marketing problem. Google is the
biggest marketing company on the Internet.

I mean, SPDY has some technical benefits of its own, but the biggest items in
the "Pro" column are that it's an open spec and Google has thrown its weight
behind it, even dogfooding it in their top sites and a major open-source
project. This got people's attention, which previous efforts didn't really
manage so well.

~~~
wmf
More specifically, because Google builds one of the most popular Web sites and
one of the top browsers, they can break chicken-egg problems by JFDI. Things
like SSL improvements, SPDY, SDCH, etc. have probably already paid for
themselves.

------
mooism2
From November, so when it says "early next year" (w.r.t. Firefox implementing
SPDY) it means "early _this_ year".

~~~
troygoode
Specifically, SPDY is available in Firefox 11:

[http://download.cnet.com/8301-2007_4-57351535-12/whats-
comin...](http://download.cnet.com/8301-2007_4-57351535-12/whats-coming-in-
firefox-11/)

------
pilom
Is there a good (fast, secure, stable) Apache or Nginx SPDY module yet?

~~~
wycats
There's mod-spdy for Apache, and that's the future of SPDY adoption.

------
zobzu
SPDY of the future today: opera turbo the article is about proxying SPDY,
actually, like opera turbo does for http. in fact, using opera turbo gives a
similar performance (except opera also compresses stuff, and the proxy is at
opera, not at the isp, which adds some latency)

Note also that newest pre-versions of Firefox have SPDY (need to enable via
about:config)

------
mkjones
If you don't trust your ISP, this doesn't really improve security at all. If
anything, it gives them a choke point which makes it _easier_ to inject
content or slurp your data.

------
p1mrx
The whole point of IP networking was that you could connect to an unlimited
number of destinations in parallel using a single phone line. How is this
still a mind-blowing concept?

------
ricardobeat
What about infra-structure? That SPDY gateway will have to handle a hell lot
of load. Will we really need that extreme optimization in 2 years?

~~~
seanp2k2
I see this as awful for "real-world" because of the privacy concerns. Think
Amazon won't analyze the heck out of that traffic? Uhh.

Also, before, gov't would need to install wiretapping stuff at central
offices. With this, Amazon or whatever SPDY provider could just let them have
"virtual wiretaps" which I'm sure won't be abused.

From an engineering standpoint, this is cool, but I can't see how this would
function without introducing way worse privacy problems. In a world where
we'll most likely need to rely on a decentralized Internet that is impossible
to regulate, this is a step in the wrong direction.

~~~
jcrites
The "SPDY gateway" is in no different a role than the "last mile" ISP. In
fact, your SPDY gateway may for all intents and purpose be your ISP; or your
ISP may offer an SPDY gateway.

------
alexchamberlain
So, we need an open source SPDY gateway then? We all know our mobile ISPs
won't develop it themselves...

------
WhatsHisName
SPDY stands for SPeeDY? What the hell is that?

------
0xABADC0DA
"I spent a fair amount of time running network traces of the Kindle Fire, and
I honestly don’t know quite what they’re doing yet."

That's a problem with binary protocols. How does Spdy help the 'open web' when
you can't even tell what's even going on at the network layer even after
spending lots of time trying?

This blog also like every other advocating Spdy ignores that HTTP tunneling in
practice provides the same benefits. And the last graph is the same as for an
HTTP proxy, nothing to see there.

~~~
wmf
Once everything becomes encrypted you're going to need specialized tools
(Wireshark) for debugging anyway, so does it matter whether the inside is text
or binary?

Also, efficient formats/protocols need to use byte counting, and byte-counted
"text" protocols (BEEP and bencode come to mind) are effectively human-
unreadable anyway.

~~~
nas
Yeah, I've got no problem with binary protocols, especially when they need to
encapsulate arbitrary data (e.g. containing NULLs, etc). Just keep the
protocol design sane and it's trivial to write a pretty printing trace tool.
Requiring machine-to-machine communication to do heavy parsing is a bad idea.

~~~
jcrites
> Requiring machine-to-machine communication to do heavy parsing is a bad
> idea.

Why? Machine-to-machine communication is for machines, after all, isn't it?

What you call "heavy parsing" is heavy parsing for humans. It's actually
_easier_ for machines, because they simply reference (and verify) an offset.

Are you advocating designing a protocol primarily around how easy it is to
interactively troubleshoot? Certainly that has value, but on the modern
Internet, is it really the dominating concern?

~~~
zobzu
To the point:

\- try checking what a webapp does. TRIVIAL. We're talking minutes.

\- try checking what a binary app on your computer does. one with DRMs or
advanced "anti crack" stuff for example. FREAKING HARD. Even if you're a
wizard, it still takes a few hours. For mortals, we're talking weeks. Weeks!

And that my friend, is why what you wrote is wrong.

~~~
resnamen
Definitely not the case with HTTPS, which looks like binary garbage over the
wire but whose payload is quite transparent once decoded by SSL.

