Thursday, April 16, 2015

KB3038314 disables SSL 3.0 in Internet Explorer 11

With latest updates from Microsoft, there is a cumulative security update for Internet Explorer KB3038314 which will disable the SSL 3.0 in Internet Explorer 11. Default settings for Internet Explorer 11 after installing this update will be with disabled SSL 3.0 (without this update the default setting were with SSL 3.0 enabled). This new "behavior" of Internet Explorer 11 is due to a vulnerability in SSL 3.0 that could allow information disclosure published in Microsoft Security Advisory 3009008 https://technet.microsoft.com/en-us/library/security/3009008 .


With SSL 3.0 disabled, you may experience the following error when accessing websites secured with SSL 3.0:



Turn on TLS 1.0,TLS 1.1 and TLS 1.2 in Advanced settings... The error message doesn't suggest to turn on the SSL 3.0 !

And finally, how to find out if SSL 3.0 is in use when accessing https websites ?
I guess, the easiest way is to view the properties of the accessed https webpage. For example:

 

If you need to access secured websites with SSL 3.0, you can override this setting (not recommended). For more info please visit Microsoft Security Advisory 3009008.
 

Wednesday, April 8, 2015

Source Path Too Long and Volume Shadow Copies

In this case a Windows Server 2008 R2 file server was hosting company's file shares. This Windows File Server was having several disk volumes with file shares and scheduled volume shadow copies. Users with necessary access permissions to file shares were able to restore previous version of files and folders. In this case a user was complaining that he was unable to restore the previous version of file, because Windows Explorer was preventing to do so, with following error message:
The source file names(s) are larger than is supported by the file system. Try moving to a location which has a shorter path name, or try renaming to shorter name(s) before attempting this operation...

The solution provided in the error message "Try moving to a location ..." is not applicable because shadow copies are read only. In order to restore this file from volume shadow copy, I have exposed the volume shadow copy as a directory symbolic link.
Finding the necessary volume shadow copy can be achieved using vssadmin or diskshadow. Because the Windows File Server was having several disk volumes, I wanted to list the shadow copies of the affected volume only. This can be done using vssadmin:
vssadmin list shadows /for=driveletter:
From the output of the command, I've found the needed volume shadow copy (for example: Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1007) . Next, I've created directory symbolic link using mklink :
mklink /D "c:\temp\vss" \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1007\
Now browsing the into c:\temp\vss, I was able to access the "problematic file" from the volume shadow copy and recover the requested version of the file. At the end, I've deleted the created directory symbolic link.