Hacker News Reader

Comment by jrockway | Hacker News Reader

Uh yeah, welcome to http. If you read the warning that pops up when you submit a form over http, it says exactly what the author "discovered". If he disabled it without reading it, that's his fault, not Tumblr's.

But of course, I think everyone should use https. I hear the excuse, "it uses too much CPU time", but this is often from people who have written their web applications in Ruby. Not using https is a very premature optimization, in that case. (Of course, crypto is not that slow on modern computers. I can do about 60Mb/s of AES on one core of my 8-way consumer-grade machine. If you are getting a constant 480Mb/s of login form submissions, you can probably afford one of those load-balancers that does SSL....)

View on HN

"I hear the excuse, "it uses too much CPU time", but this is often from people who have written their web applications in Ruby"

I'm curious about this, are these excuses you've heard based on configurations where a proxy server processes the initial https req and then sends the backend request encrypted, too? This is where Ruby is handling an encrypted request?

Or are you saying there are people who have excused https from their setup because their frontend web server is written in Ruby?

The poster's point isn't really about Ruby. Ruby works just fine with HTTPS, thank you very much. It's not like Ruby handles the HTTPS encryption. I think his point is more "I hear the excuse 'it uses too much CPU time', but this is often from people who [should be looking elsewhere if they have performance problems]".

Ah I see. I was confused.

It didn't occur to me that he or she uses Ruby (in italics) as a catch all for slow application performance, not slow encryption performance.

That said, do people really eschew https because they are that CPU strapped? Bizarre.

Exactly; thanks for clarifying. :)

I agree except for the everyone should use https bit.

It's not a question of CPU time but usability, what if you want subdomains (then a wildcard SSL cert, then the cert expires and everyone is unhappy for a few days, and those annoying warnings about security exceptions that are bound to happen) and all that hassle for what? Just so that someone doesn't steal your oh so important blog password? I dunno, seems overkill, no?

Unfortunately, most people use the same password for their blog that they use for their online bank.

Yeah, they're being dumb, but they're going to blame you when their password gets sniffed and their bank account is drained.

"often from people who have written their web applications in Ruby"

Can you elaborate? What is Ruby's shortcoming in this area?

If performance is so important that you can't encrypt your login form, then you probably shouldn't be using a language that runs 50x slower than C. (Just to be clear; all my web applications are this slow too. But I enable SSL.)

As always, it depends what your app is doing. I've got a realtime event hanling solution where the performance dips close to 50% when you turn SSL on simply because of the handshake times.

So we shouldn't use python, perl, or php either? The last time I checked, all of these languages are at least 30x slower than C.

The expensive bit of SSL is not the symmetric crypto once established, it's the public key crypto when setting up the SSL session.

However, 600 quid buys you a PCI-E accelerator card which offloads those calculations from the CPU, so you don't even have to get a fancy load balancer.

I think most people that use Ruby put something in front of their servers (like nginx or Apache) that can handle SSL and serving of static files...

Reply on news.ycombinator.com