The answer to the risk equation is really going to depend on the specifics of the system in question. In reply to your points:

* I’m not assuming that the appliance will be more trustworthy. I’m just pointing out that it is _possible_ that it may be harder to exploit.
This will obviously depend on the specific implementation and is something the security architect will need to evaluate.

* I was actually assuming that the servers would be homogenous enough that if you could exploit one that you could exploit all.

* Possibly. The amount of confidential data in flight may be a small drop in the ocean compared to the data that a full application
compromise could lead to (i.e all data that the application has access to).

* Possibly. I don’t give much credence to trying to detect attacks, but the ability to detect a compromised connection could be invaluable in reducing the damage done.

I’m not trying to defend the usefulness of appliances by the way.

Using an SSL appliance will likely add more risk due to the extra complexity, however it is possible that
it may reduce risk. You are very much correct in stating that it is a chain design and does not add
another layer of defence.

* … because no appliances use OpenSSL like the server does. And appliances that use a home-grown implementation are less likely to have flaws than a publicly-reviewed codebase that is 10x older and used in 1000x more systems.

* … because the appliance sees all the decrypted SSL traffic for all the servers behind it, but it’s more valuable to see the data on a single server

* … because other stuff on the server like the application itself is more valuable than the data that was encrypted with SSL

* … because seeing what’s going on for the few malicious connections is more important than protecting the data of the millions of legitimate connections

I can only reply with a confused “huh???”

Terminating the SSL before the final consumer of the data adds extra vulnerabilities (as listed in your post) and hence risk, however it may reduce
the risk to the overall _system_ because:

* The risk of any SSL implementation flaws being exploited may be lower in the appliance than in the server;

* In the event that an SSL flaw is exploited:
* The damage done (i.e asset value) of having the SSL appliance compromised will likely be lower than the damage in having the server compromised;
* The risk of compromise of associated assets on the server (for example: application code/logic, database, OS) will be lower with an SSL appliance.

* Adding the SSL appliance (i.e proxy) to the design will allow security tools to inspect/alter the traffic (which may end up lowering the risk of application compromise).
(ofcourse this can conceivably be done on the host without the need for an extra SSL layer).

Your example of SSL makes the need for such designs very clear. In fact the modifications made to TLS to more rely on the security of SHA-1 in the key generation function in the face of the mounting discontent for MD5 is further evidence of this.

What would be nice is a way to model or at least formalize these relationships when designing security mechanisms and performing threat modeling.