Exactly. SSL is, basically, implemented as a (shared) library. Applications use from that library whatever they want to use. If they want to use insecure protocols they do it and if they are programmed correctly the don't do it. But from the POV of the library it is simply not its decision.

You can, of course, use some firewall software with stateful inspection and acting as a "transient SSL proxy", in which you could create rules to effectively forbid certain crypto-protocols.

This would be similar (and have similar consequences) to removing, say, "telnet" (the binary) from your system. If there would be a script using this "telnet" it would simply stop working. The applications using the protocols you forbid as outlined above would not be able to make any connection any more (and perhaps stop working, at least in this regard), but they wouldn't start working differently - for the same reason the script would not start to use "ssh" once "telnet" is not available any more.

One more word about these requests, because i got the same nonsense requested three times now: it is typically the request of someone not knowledgeable enough to be in either systems administration or programming, which is whe s/he ended up as "security advisor" and trying hard to make sure everybody else is getting done as little as the advisor himself.

These are the guys who want you to have 27-digits long passwords, containing no known words and at least 8 characters you can't enter from the keyboard, changing them every three days but do not write them down! I bet that in every office with such policies i can find at least one post-it note with the PW under some keyboard. And the number of post-its i will find will increase with the length and overall absurdity of these rules, so they won't increase but in fact decrease security.

I hope this helps.

bakunin