Skip to content


Subversion checkout URL

You can clone with
Download ZIP


NPN support #7

igrigorik opened this Issue · 7 comments

3 participants


OpenSSL 1.0.1+ ships with Next Protocol Negotiation (NPN) support, which is required for SPDY protocol negotiation.

node-spdy supports this already, but it would be great to have this support baked right into node-ssltunnel and then deliver the frames over a regular TCP stream.


Hi Ilya,

I am not sure I fully understand your suggestion.

ssltunnel pipes TCP data over TLS. TLS is used internally for encrypting the data and authenticating both sides: the client and the server roles. Are you suggesting to use SPDY instead of TLS for communication between the client and the server roles? If so, what is the scenario where it would help? If not, please elaborate more on your suggestion.



My bad, should have provided a better explanation of what I had in mind! Correct me if I'm wrong, but I can use node-ssltunnel (server option) to terminate the SSL connection and forward the unencrypted stream back to the backend?

Aka: client -- (TLS) --> node-ssltunnel -- (unencrypted) --> server

NPN is an extension to TLS, not a replacement. When an NPN aware client tries to connect to the server, it sends extra metadata in the handshake indicating that if the server supports an "alternate protocol" (ex, spdy/v3), then it should confirm it and the data exchange after the handshake will be done with SPDY framing. If the server does not recognize the NPN negotiation request then the client will simply fall back to regular HTTP.

So, the behavior I would want to see with this proxy is: the client (let's say Google Chrome) opens a new connection and performs the TLS handshake with NPN advertisement. Since node-ssltunnel is the terminating node for the SSL tunnel it should optionally (as configured by the server admin) confirm the alternate protocol. Once that's in place, the SPDY frames will flow over an unencrypted channel to the backend server (which is perfectly fine). But without this NPN support.. SPDY will not work since the client will always have to fallback to regular HTTP framing.

Some more info:


Thanks for the clarifications :)

The issue is clear now. Do you have a specific scenario / project where do you need to terminate TLS before reaching the server, or this is a general suggestion? I'm just trying to understand whether there is a specific need that should be addressed in the very near future or not.

BTW, AFAIU, node-spdy requires node 0.7 and up. Do you know when joyent plans to release it?


Most languages today require to be completely recompiled against a newer version of OpenSSL + most likely require API modifications in the core SSL libraries to add NPN. I've opened a few tickets for those already.. and it'll take some time to get those as default.

In the meantime, having "a simple proxy" in front (like node-ssltunnel) would solve 95% of this problem. Client would be terminated at the proxy with NPN upgrade, and SPDY frames flow over a regular TCP pipe to whatever backend: python, ruby, heck PHP even. ;-)

So, as such, count it as a feature request.. that I'd love to see very much, since it would make experimenting with SPDY several orders of magnitude simpler.

Node 0.7+: not sure.. @eee-c: any thoughts?

P.S. I guess we could modify node-spdy to do this for us as well.. :-)


Node-spdy v0.1.4 supports node 0.6 (the 0.1 series is still maintained). And yup, it's pretty easy to write a reverse proxy with node-spdy: :)

FWIW node 0.7+ bundles NPN-enabled openssl in the source, so this gets even easier with the next stable node release.


Nice. Is there an ETA for 0.7+?

Gist looks nice! Should nonetheless support NPN in node-ssltunnel.. :-)


Thanks guys, sounds cool and useful indeed. I'll try to squeeze it in during June.

@dimastopel dimastopel was assigned
@igrigorik igrigorik closed this
@dimastopel dimastopel was unassigned by nadavbar
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.