0

I am working on a node.js app. It presents the art of a friend of mine. Besides some general information and a lot of pictures it also includes a contact form for people who want to contact him about his work. I want to encrypt the contact page to protect the personal data that is send through the form but keep the rest of the page unencrypted to reduce the loading time of the page.
I already managed to create a HTTPS server which encrypts my entire website. But I just want to have an encrypted connection for the contact page. Does anyone know how to implement that?
One solution I though of would be to create two node.js servers. One HTTP server and one HTTPS server and then run the main page on the HTTP server and the contact page on the HTTPS server. The link to the contact page would then include https. Something like: "https://www.domain.com/contact".
But somehow that doesn't feel like the right way so I am hoping that someone has a better solution.

Thank you for your help!

arne.z
  • 3,242
  • 3
  • 24
  • 46
  • 4
    Just use SSL over the entire site. There is just no reason not to. – PeeHaa Nov 24 '14 at 23:29
  • The overhead of serving pages over HTTPS is probably not worth worrying about, and there is a movement to routinely encrypt whole sites anyway, to increase the overall privacy of the Web. – IMSoP Nov 24 '14 at 23:32

1 Answers1

1

The notion that HTTPS is less performant than plain HTTP is a myth that needs to die.

  • On modern systems, the overhead of SSL/TLS is < 1% of CPU. In fact, with optimizations like SPDY, you might find that a TLS-secured connection actually performs better than plain HTTP. I'd be willing to wager that in reality, you'd be unable to notice any negative difference in performance.

  • Another common misconception is that browsers do not cache resources delivered over HTTPS. This is false. All browsers cache HTTPS content by default.

  • Google now ranks all-HTTPS sites higher than plain HTTP.

The one and only thing you lose by going all HTTPS is intermediate caching proxies, but to be honest I wouldn't lose any sleep over this unless you know your site's users are on a network with a relatively slow link and a local caching proxy. Otherwise, this isn't really a concern.

The overhead associated with TLS is negligible. There is no reason to not just serve your entire site over HTTPS.

Once serving all your content over HTTPS, you should still run a HTTP server that issues permanent redirects. The easiest thing to do would be to run a separate Express app:

var http = express();

http.use(function(req, res){
    res.redirect(301, 'https://mydomain.com' + req.url);
});

http.listen(80);

Your HTTPS server should also enable HSTS.

app.use(function(req, res, next) {
    res.set('Strict-Transport-Security', 'max-age=31536000');
    next();
});
Community
  • 1
  • 1
josh3736
  • 139,160
  • 33
  • 216
  • 263
  • Thank you for the detailed answer.But doesn't it take longer to establish a connection over HTTPS because a more complicated handshake is used? That's also part of the loading time and happens every time the page reloads, right? – arne.z Nov 25 '14 at 23:18
  • It is true that the initial TLS handshake adds some overhead (at worst*, 2 extra roundtrips), but this only needs to happen once per session. Between HTTP keep-alives and [SSL session resumption](http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html), the browser does **not** need to do a full handshake on every page reload. Additionally, if you use SPDY, the TCP connection is left open as long as the tab is open. (* - Normal TLS handshake is 2 roundtrips; [False Start](https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00) can reduce the number of trips required.) – josh3736 Nov 25 '14 at 23:38