SSLV2 removal

I understand that ADDING the 'enabled' value and setting it to '0' will disable SSLv2.  

My question is: if that key with that value does NOT EXIST on the server which has SSLv2 DISABLED already, what other setting takes care of this?

perhaps the actual protocol level has also been removed from the SCNANNEL key under the same path?

Cheers.

Sorry - could you explain that in simpler terms?

What do you mean?

Removing the protocol from the registry doesn't do it - then it goes to the 'default' behavior for schannel.  Having a modified schannel.dll could do that, however - I would suggest looking at the version information of this file in system32.  That being said, I don't think that this kind of change has been made in any patch.

I presume you are looking at
 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols\SSL 2.0\Client]
and
 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols\SSL 2.0\Server]

One way that the scan might be fooled is if all lower encryption methods were removed already - so no 40 or 56 bit algorithms, only 128+.  This is not a 'proper' test, but if a test was being run to see if they could introduce forcing a lower protocol than what the server/client handshake would normally produce (i.e. forcing 40bit instead of 128bit), then the test could interpret the lack of 40bit vulnerability as being non-v2.0.  This only tests against the most well known vulnerability of SSL2.0 - the man-in-the-middle scenario.  For more info on the difference:
http://stason.org/TULARC/security/ssl-talk/4-11-What-is-the-difference-between-SSL-2-0-and-3-0.html

You can also run a simple test from OpenSSL:
openssl s_client -connect TARGET_IP:PORT_NUMBER -ssl2

Is there any other main difference between serverA and serverB?  For example, is the vulnerable one running 2003 and the secured one running 2008?  I would need to refresh my memory, but I think that the default was changed to restricted in 08 and it was enabled in 03 - not sure about 03R2.

These are both running IIS, I presume given the zone list?

Actually, one server is an duplicate image of the other.

Before putting the second on the network, I applied the image of the first and then changed the name.  The first does not come up with this hit, the second one does.

Both are W2K3 R2 Std SP 2.

How was the server imaged?  Sysprep or direct copy?  Sysprep may have reset certain registry settings, so you may need to reapply them after restoring the image.  I'm not positive how much gets changed in the registry by renaming a box, but you should be using sysprep anyways to avoice duplicate SIDs on the network.

Did you doublecheck the registry settings mentioned on the second box to make sure that stuck through your imaging/renaming procedure?


Also, I'm not sure why this came up for autoclean - it has not been 21 days since last post (5/20/09) from the asker - maybe an EE cleanup check bug that only checks for date since last expert post?

How did you image the server?  Sysprep or a straight copy?  Sysprep is usually best to avoid duplicate SIDs.

Did you verify the changes you made on one stuck to the restored image after the renaming?  I'm not exactly sure what all get modified in the registry when you rename the computer account.


Also, I'm not sure why this got triggered for cleanup - last post was 5/20/09 which was less than 21 days ago - maybe a cleanup scan bug that only checks against the date of the last expert posting, not the asker?

Don't know what Sysprep is.  I used Acronis True Image and installed the image on the server when it was off the network then changed the computer name.

But, let me clarify something before looking at the image difference:   I have 4 web servers -  3 of them came up with this SSLV2 hit.

One of the 3 with the hit is a copy of the one without the hit.  The other two I built from scratch.  So I don't think it is a image/copy difference.