I'm trying to implement SPDY (with Node.js) for use on a high latency connection.
Now SPDY uses TLS encryption and this would increase the packet length - something I'm trying to avoid.
Is there such thing as a SPDY implementation without the TLS encryption?
Many thanks in advance,
SPDY's framing layer does not need to run over TLS, but for deployment reasons, it almost always does. It's hard to reliably deploy without running encrypted over port 443, because of intermediaries. Note the SPDY whitepaper says: "To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken."
That said, the C++ Flip server in the Chromium repository does support running without SSL, and the Chromium browser can be configured to support this.
PS: There's also an existing node.js implementation, see http://www.chromium.org/spdy.
If you want to test your SPDY server locally and without TLS, you can force chrome to use SPDY even without the NPN upgrade. To do so, pass --use-spdy=no-ssl to Chrome when you load it up.
You can confirm that the flag is registered by opening chrome://net-internals/#spdy and checking in there.
If you are implementing a SPDY server using node-spdy, then you can use the plain: true, ssl: false options to achieve what you want.
Its possible to make requests to plain: true spdy-server using spdycat
cli utility, specifying protocol version explicitly (-3 or -2 and
--no-tls). To use it from browser, you will need to start chrome with --use-spdy=no-ssl flag.
But please keep in mind, that SPDY is supposed to on TLS(SSL) server
or behind TLS(SSL) terminator, and otherwise not-suitable for serving
web-content.
https://github.com/indutny/node-spdy/issues/103
I would suggest QUIC protocol which is in development and base on UDP instead of TCP/TLS but still has the benefit like SPDY and Chrome has supported it
Related
I have a question about SSL. As I know, when we use browser to request from https server, it will make an SSL handshake first then all data will be encryption in the connection. But if I make a request without browser (like request module in nodejs, postman...), will it be an SSL handshake and data encryption on the connection?
Anyone know please explain to me, thank you.
First, stop saying SSL. Its successor is TLS, and it will have 20 years next January.
TLS is a protocol sitting on top of TCP typically (other variants can also use UDP), and provides on top of TCP features some new features about endpoints authentication and transport confidentiality and integrity.
In a way, you can understand it as being sandwiched between TCP and the higher level application protocol, like HTTP.
Saying otherwise you can use many others protocols on top of TLS: you have all email related ones (SMTP, IMAP, POP, etc.), you can have FTP on top of it (while probably not a good idea nowadays), XMPP for realtime communications, etc.
In short, any protocol using TCP could use TLS with some adaptation.
So HTTP is one case among others. HTTP is between an HTTP client and an HTTP server, or webserver for short.
A browser is an HTTP client. One among many ones. When you use curl or wget you are also an HTTP client. So if any HTTP client access an http:// link it will first do the TLS handshake, after the TCP connection and before starting to do anything really related to the HTTP protocol.
You have specialized libraries dealing with TLS so that not all program need to recode everything about this again, since it is also complicated.
My gut feeling is that a SPDY-capable browser will treat it as though it were a SPDY response. However, the most I can find is a reassurance that an H2 response will degrade gracefully to HTTP1.1. I'm considering serving assets in an H2 oriented manner (multiple requests, no domain sharding, etc.), but I do need to support some non-H2 browsers (e.g. Android 4.1's browser). Will I be OK if all the clients are at least SPDY compliant?
Bonus question: are there any complications involved with mixing protocols? We're on a web framework that doesn't support H2, but I'm considering serving most of our assets from a CDN. Assume TLS.
Browsers that are SPDY or HTTP/2 enabled use a TLS extension (either the older NPN or the new ALPN) to negotiate the protocol they speak over TLS.
The client sends the list of protocols that it is capable to speak in order of preference (e.g. h2,spdy/3.1,http/1.1), and the server picks one protocol among those in that list that it also supports (and that match security required constraints).
For example, if you have an older browser that does not support h2, it will send spdy/3.1,http/1.1, and the server will never pick h2 (even if it supports it).
If the server does not support SPDY, the only option left is http/1.1, and this is what constitutes the "graceful degradation" to HTTP/1.1.
There is never the possibility that if the client requested to speak SPDY (and not HTTP/2), the server replies with HTTP/2, unless gross implementation errors on the server.
SPDY is being phased out in favor of HTTP/2. For example, recent Chrome versions don't support SPDY anymore.
There are no complications when you you make requests to different domains, and the servers speak different protocols: this is handled transparently by the browsers.
If your server can speak SPDY and HTTP/1.1, and the CDN can speak HTTP/2 and HTTP/1.1, then you have to use a browser that supports all 3 protocols to leverage the SPDY and HTTP/2 benefits.
The browser can negotiate SPDY with your server, and negotiate HTTP/2 with the CDN, and the page composed of resources from both origins.
However, browsers will soon drop (or have already dropped) SPDY, so with recent browsers you may end up speaking HTTP/1.1 with your server and HTTP/2 with the CDN, thereby losing the SPDY|HTTP/2 benefits for resources on your server.
We run a nodejs https server and we noticed in one of the online SSL checker tools that we use old ciphers (And generally bad TLS options).
We don't really know much about this thing so we were wondering if there is any recommended ciphers list or specific nodejs TLS options we should pass in order to make sure we are most secured.
Thanks
P.S.
This is the online checker we use: https://www.ssllabs.com/ssltest/index.html
We would really like to get an A there
For future reference, i ended up using nginx for SSL termination, and used this guide for securing my ssl connections: https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
I have a doubt about using module mod_spdy in my webite:
If I install the module mod_spdy in my Apache Server, What will it happen with the http requests come from desktop and mobile browser which not support the SPDY protocol? (see the browser which not support the SPDY protocol in http://caniuse.com/spdy )
I don’t know if in this case Apache will serve the information using the http protocol or the web browser will have problem to render the information. In the last case, is there any solution to solve the problem with the browser that not support SPDY? For instance, use a web server responding with a different protocol (http or SPDY) depending on which user agent is requesting: browsers support SPDY or browsers only support HTTP.
Thanks in advance,
First of all Apache mod_SPDY supports encrypted connection(HTTPS) only, therefore you have to create a VirtualHost for the 443 port and add your SSL certificate. Mod_SPDY will automatically fallback to HTTPS 1.1 if the browser does not support SPDY. A good use for it is to enable server PUSH. Have fun with SPDY!
Due to a couple of issues with my host, I'm unable to use a SSL-certificate on my server (I'm not ready to change provider just yet), and can't therefore use HTTPS. This server will communicate with a couple of client-computers and will transfer data that's somewhat secret.
Would it be reasonable to simply use AES encryption (encryption on client before sending, decryption on server before processing) instead of HTTPS?
This depends on your deployment environment.
Replacing SSL/TLS (and HTTPS) with your own encryption protocol for use by a web browser is always a bad idea, since it relies on JavaScript code delivered insecurely (for details, see this question on Security.SE, for example).
If the client isn't a web browser, you have more options available. In particular, you can implement message-level security instead of transport-level security (which is what HTTPS uses).
There are a number of attempts to standardise message-level security with HTTP. For example:
HTTPsec had a public specification (still available on WebArchive), but a commercial implementation. I'm not sure whether this has been widely reviewed.
WS-Security, oriented towards the world of SOAP.
Perhaps more simply, if you want to re-use existing tools, you could use S/MIME or PGP (in the same way as you would for e-mails) to encrypt the HTTP message entities. Unlike HTTPS, this won't protect the URL or the HTTP headers, but this might be enough if you don't put any sensitive data there.
The further down you go with "raw encryption" yourself (using AES directly, for example), the more likely you'll have to implement other aspects of security manually (typically, verifying the remote party's identity and dealing with the problem of pre-sharing the keys).
If you have a small list of clients that don't change often, you could implement your own SSL-Tunnel using SSH. On the clients do a;
ssh -D 4444 nulluser#example.com -N
where nulluser has no shell or file access on example.com.
Then add a foxyproxy whitelist setting - so that for example.com the client browsers use the localhost:4040 proxy.
It's a hack, it's totally unscalable, but it would work as I say for a small, static number of clients, and it has the advantage of not reinventing any wheels while being totally secure.