Compared to an extra 100-1000 millisecond trip each way to communicate between the browser and the server during the handshake, the CPU time to do the encryption is nothing.
Where in the world are you getting 1000 ms rtt's? Sat link?
Best case you have to do three RTs for a full SSL handshake (without false start anyway), so a RTT of 300ms will bring you pretty close to that 1000ms. We (github.com) certainly have average 1000ms SSL handshakes in Asia -- we're 5 RTs for an SSL handshake presently. It's extremely annoying.
Sure, I manage servers in the US, Japan and Australia so I'm well acquainted with how latency sucks. I was questioning the idea that there was a possibility of "an extra 100-1000 millisecond trip each way" - Taken literally, this would mean up to a 2000ms RTT (1000 ms each way). I get ~230ms RTT between Sydney and NYC, and 320 from Sydney to Hamburg going around the wrong way. for reference, 2000 ms is 74% of the RTT to the moon.
Oh, I would argue that latency often has no correlation to distance.
When you're talking about SSL handshakes, where else is the latency going to come from?
Not everyone lives within a few hundred miles of the web server they're using.
Not to mention the WildBlue etc satellite Internet often used in rural areas.
the ssl handshake latency isn't why sysadmins don't want to implement everything over https. the reason (or at least 5 years ago when sysadmin was my primary role) is because the additional cpu power it takes to encrypt all the data is huge.
That's not really true now. CPUs have gotten faster, the speed of light has remained the same, and actually with users on crappy wireless/cell connections (and, increasingly, international), network latency is even more of an issue now.
I don't think that's really the case anymore. CPUs have just gotten that much faster. I run a node.js server with https on Linode's cheapest VPS that handles hundreds of requests per second. The server load is at ~0.00 most of the day.