How much SSL traffic is offloaded to dedicated hardware on the server side nowadays? How many different companies are there in that space? How many of them have secret agreements with the NSA (or their respective state intelligence agencies) to retain session keys and dump them out when they receive the right kind of query?
The actual owner of the SSL offload hardware would have a hell of time even detecting that their keys were being handed out that way - picking out a once-a-day SSL connection that the offload hardware talks to directly versus one that it passes through in the clear to the systems behind it is going to be exceptionally difficult.
I think the amount of SSL hardware in the field is closer to zero. Nobody with any clue uses that stuff because it's power hungry, the APIs are awful, the implementations can't be verified, and any such asic will look slow in a year whereas cloud server lifetime is five years. AESNI killed those guys a long time ago. The only users of them are embedded platforms without the host CPU power to do crypto.
It still gets used sometimes in hardware load balancers (I guess that is "embedded platforms"). Some of those turn out to actually be more like software, though.
Really? I thought a lot (most?) of the big boys used load balancers that include SSL termination along with DoS protection and the load balancing itself. BTW
anyone know how AWS load balancing works in this regard?
As far as I can tell, ELBs are just commodity EC2 nodes, which are actually pretty shitty because they're EBS backed; you can build a better ELB yourself using an S3 backed EC2 node.
Some of the OpenStack people were using hardware load balancers (F5; I think maybe HP OpenCloud?) as an option.
EBS is a very unreliable service compared to the rest of the AWS stack; probably the single most unreliable service. (vs. EC2 which overall is fairly reliable, even if individual nodes aren't, and Route53, which has been quite reliable.)
Load balancers are often used as part of an HA system, so building your HA component using the least reliable subsystem is a bad idea. Particularly because there's no need to -- the S3 backed instances work fine for this.
The actual owner of the SSL offload hardware would have a hell of time even detecting that their keys were being handed out that way - picking out a once-a-day SSL connection that the offload hardware talks to directly versus one that it passes through in the clear to the systems behind it is going to be exceptionally difficult.