There has been some discussion about it being more practical to use SSL due to advances in hardware. From my understanding, stronger public-key encryption means that both encrypting/decrypting and breaking it (via brute-force or vulnerabilities) take longer.
Is the return (in security) for the performance loss of using SSL increasing, or has today's hardware simply outgrown the strength of encryption used?
There are several effects coming into play. But the most important property is that with increasing keylengths, the attacker's work becomes exponentially expensive, whereas the defenders work only becomes slightly more expensive.
Looking at the different kinds of cryptography in use:
Symmetric cryptography
Originally we used DES and 3DES. DES had a dangerously small key and decent performance. 3DES had a secure keysize, but bad performance (3 times as slow as DES).
So AES was developed which has very good performance and secure key sizes. AES-128 is secure against brute-force for a long time and AES-256 is secure against brute-force using conventional and quantum computers forever.
So unless there are major advances in crypto-analysis, there is no reason to use symmetric cryptography slower than AES-256, no matter how fast the attacker's computers get. AES performance becomes significantly better on the current generation of processors, which offer specialized instructions.
RSA used in the key-exchange
The defender's cost grows with the key-size to the third power. The attacker's cost growth much faster, but doesn't double with each bit. So we need to increase key-sizes somewhat to compensate for the increased computational power of attackers. For example 1024 bit RSA keys are currently being replaced by 2048 bit keys, because cracking them will become possible soon.
Still the defender's advantage grows as computers get faster.
Better asymmetric algorithms
Elliptic curve cryptography is much faster than RSA. Currently it doesn't get used much for authentication in SSL, only for the ephemeral key-exchange using ECDHE suites. But in principle they allow a 128 bit security level with better performance than 1024 bit RSA keys.
In general modern cryptography is at a level where brute-force is no longer a threat for most schemes. The main trade-off is performance vs. how resilient to crypto-analysis the ciphers are. But even there we're only talking about a small constant factor that doesn't scale with computational power.
Unless there are major advances in crypto-analysis or computer science in general, I expect the processor cycle cost of cryptography to remain approximately constant. This means that effectively it'll get faster at the same rate as our processors.
In particular that means that the hand-shake costs effectively becomes much cheaper as computers get faster, whereas encrypting the connection itself will stay at a constant cost, assuming bandwidth (and thus the amount of data) and processor speed increase at the same rate. Luckily symmetric encryption is already very fast, especially on processors supporting specialized AES instructions (more than 1GB/s on a single core). Generating dynamic webpages is typically more expensive than encrypting them afterwards.
It sounds like you are conflating the strength of SSL and the strength of encryption. The two are distinct; SSL is a protocol that uses encryption, but the security of SSL is not strictly dependent on encryption. SSL can be vulnerable even when the underlying encryption is not.
Overall, security and speed for SSL are not a tit-for-tat trade-off. Making SSL faster can have nothing to do with the actual encryption because SSL is a somewhat bulky protocol layer on top of normal communication streams. The "fast" part of SSL is actually the raw encryption, since encryption algorithms are well-studied for speed of implementation and many high-end servers have hardware support for doing the encryption. The slow part of SSL is everything else.
If you read through the link you posted, you'll note that a lot of the speed issues they're addressing have to do with the overhead that the SSL protocol introduces. They're trying to minimize the number of round-trip TCP exchanges, trying to minimize the data that needs to be sent to start a session, trying to cache keys to avoid re-creating them for returning clients, and so forth. In theory, these these might be doable with no impact on security. (But each tweak must be evaluated on a case-by-case basis.)
Speed and security do have something of a natural trade-off. Any tweak to SSL to make it faster needs to be scrutinized to ensure it doesn't add a security vulnerability. But it isn't just a law of returns, where faster equals less secure and slower equals more secure.
