Qualys reports vulnerabilities related to encryption on a number of web-servers, both Windows/IIS and *nix/Apache. These vulnerabilties are found in many commercial products, like F-Secure Secure Messaging Gateways, Microsoft IIS, embedded webservers (like in WatchGuard Fireware). Two examples of the reported vulnerabilities:

SSL Server Has SSLv2 Enabled Vulnerability (QID: 38139) SSL Server Supports Weak Encryption Vulnerability (QID: 38140)

There are several fixes that you might implement on your server, like <a href=" http://support.microsoft.com/default.aspx?scid=kb;en-us;187498">disabling SSLv2 in IIS</a> or changing httpd.conf for Apache.

Typically, for Apache/mod_ssl, httpd.conf or ssl.conf should have the following lines:

SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

For Apache/apache_ssl, httpd.conf or ssl.conf should have the following line:
SSLNoV2

Well, then we only have the problem of commercial products ... where you cannot just change it by yourself. Time to fix? Upon being asked for a statement, the product manager (MDW: dette var WatchGuard's Steve Fallin) of one vendor wrote back:

"SSL clients negotiate the highest level of encryption possible when they connect, regardless of what the lowest supported setting on the server is. This report highlights what the server CAN support, not what a given session is using. We've left the lower strength algorithms in the product to support deployment in countries where higher levels of encryption are politically problematic. (...) we have no current plans to change the minimum supported levels of crypto."

While this answer explains the position of the company, it may actually be misleading: even though the client does negotiate the strongest cipher, there is the possibility to circumvent this: a man-in-the-middle (MIM) listens to the conversation (which is unencrypted at this point), and just filters out the strong algorithms. He just passes on the ciphers that are weak - the ones he can crack and thereby decipher the session. In other words: no fix in the forseeable future.

The way to go would therefore by to configure the clients (at least the ones under your control, right?) no to be able to use weak ciphers ... for Windows, see <a href="http://support.microsoft.com/kb/245030/en-us">this KB-article on how to restrict the use of certain algos in schannel.dll</a>