Compiling OpenSSL, curl, and zlib on Windows

Getting these libraries compiled on Windows was surprisingly easy. Cross-platform support has come a long way. OpenSSL required the most setup. Both ActiveState Perl and NASM were necessary for the build process. Also, this assumes there is a temporary compile folder and then an install folder. The temporary compile folder in these examples has the version number afterward. The install folder is just the product name.

zlib

 mkdir \projects\zlib 
 mkdir \projects\zlib\bin
 mkdir \projects\zlib\include
 mkdir \projects\zlib\lib 
 cd \projects\zlib-1.2.8\  
 nmake /f .\win32\Makefile.msc  
 copy zlib.h ..\zlib\include
 copy zconf.h ..\zlib\include
 copy *.lib ..\zlib\lib  
 copy *.dll ..\zlib\bin  

curl

 cd \projects\curl-7.40.0\  
 nmake /f Makefile.vc mode=dll MACHINE=x86  
 move .\builds\libcurl-vc-x86-release-dll-ipv6-sspi-winssl ..\..\libcurl  

OpenSSL (static)

 cd \projects\openssl-1.0.2  
 perl Configure VC-WIN32 --prefix=c:/projects/openssl  
 .\ms\do_nasm  
 nmake -f .\ms\nt.mak  
 nmake -f .\ms\nt.mak test  
 nmake -f .\ms\nt.mak install  

OpenSSL (dll)

 cd \projects\openssl-1.0.2
 perl Configure VC-WIN32 --prefix=c:/projects/openssl  
 .\ms\do_nasm  
 nmake -f .\ms\ntdll.mak  
 nmake -f .\ms\ntdll.mak test  
 nmake -f .\ms\ntdll.mak install  

I may expand on this post. There are a few other libraries that I'd like to use and keeping instructions in one place seems like a good idea.

Problems using the Command Line Install on SQL Server 2014 Express

The installation sets for SQL Server Express are actually wrapper executable, which basically means they are large zip files which contain the setup files. So, the first thing that happens after running it is that all the files are extracted to a temporary directory and then the Setup.exe is executed using the command line parameters passed to the wrapper.

Unfortunately, there are a few bugs in the wrapper executable for SQL Server 2014 RTM. These seem to be exclusive to SQL Server 2014 RTM, and according to Microsoft will be fixed in service pack 1. In previous versions of the SQL Server Express installation sets, the extract folder is randomly generated and the files are automatically extracted.

Because of this, you can run the wrapper in one of two ways.

1. Using the same command line parameters as I used in SQL Server 2008 Express and 2012 Express, I am prompted for an extract folder. Once extracted, the Setup.exe is correctly executing using command line parameters passed to the executable. This has the down side of making completely automated installs impossible. 
2. Using command line parameters exclusive to the wrapper, I can specify an extract folder. This has the down side of ignoring any other command line parameters. So, I'm going to have to extract the files and then run Setup.exe separately.

Command line parameters supported by the wrapper

• /Q - Quiet mode. This is the same as Quiet mode for Setup.exe
• /U - Progress Bar mode. This displays a progress bar as the files are extracted.
• /X:<PATH> - The Extract Folder where the files are extracted. This last parameter has a few caveats. 

Extract Folder Parameter

• The parameter must be the last parameter. Anything after that is considered part of the path.
• The parameter must be followed by a colon and then followed by the path.
• There must be no space between the X and the colon or the colon and the path.

What this means is that anyone wanting to automate the installation of SQL Server will need to first extract the files. Then, run Setup.exe separately.  Afterward, any temporary folder and files will need to be cleaned up.

While this isn't a huge burden for developers, it definitely qualifies as annoying. It did involve a couple of extra days worth of testing to make sure I covered all the bases.

SSL/TLS Protocols Supported by Windows

I know I'm a bit slow out of the gate here. This post is coming much later than it should have. Anyway, I wanted to find a list of TLS/SSL protocols supported by Windows. Unfortunately, that statement is rather dubious.

It should be two separate questions. What protocols are supported by IIS; and what protocols are supported by Internet Explorer. The answer to the first is very simple.

IIS on Windows XP/2003/Vista/2008 support

• SSL2
• SSL3 
• TLS1

IIS on Windows 7/2008R2/8/2012/8.1/2012R2 support

• SSL2
• SSL3
• TLS1
• TLS1.1
• TLS1.2

If you are using IIS on an older version of Windows than 2003, please don't. Considering the number of vulnerabilities in IIS on Windows 2000 over the years and the fact that the OS is no longer supported in any way by Microsoft, you shouldn't even be it.

The answer to the second question is a little less simple because each version of Internet Explorer is built to run on multiple versions of Windows. So, it's more along a combination of the version of Windows plus the version of Internet Explorer.

A full comprehensive table is listed on Wikipedia of all browsers with helpful references to vulnerabilities and how those browsers are affected by them. The best situation for Internet Explorer users is using Internet Explorer 11 on Windows 8.1. Users of Internet Explorer 8 (or greater) on Windows 7 (or greater) can get just as secure a setup as those on IE11/Win8.1 by making a few option changes.

References

•  Support for SSL/TLS protocols on Windows
• How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll
• POODLE Vulnerability: Padding Oracle on Downgraded Legacy Encryption
• Wikipedia - Transport Layer Security