I wrote a VB6 program which uses winhttp.dll to send and receive messages to/from a remote server. It has been working fine from various operating systems: Windows 2000, WinXP, Win7, Win8.
Recently the server provider informed me that they will "phase out support of SHA-1 security certificates" and i need to "check that the thumbprint is aligned to SHA-2 new SSL cert.".
What is happening now is that when my program runs on WinXP,7,8 - it's still OK. But when running on Windows 2000, when I call the winhttp Send() method, I get an exception "Error Occurred in the Secure Channel Support".
I am failey clueless on certificates etc and I don't really know what to do.
My Vb6 code looks as follows:
' Connect to server
Set m_ServerObj = New WinHttpRequest
m_ServerObj.Open "GET", m_ServerURL_SC
' Send request to server
m_ServerObj.Option(WinHttpRequestOption_SslErrorIgnoreFlags) = &H3300
'Unknown certification authority (CA) or untrusted root 0x0100
'Wrong usage 0x0200
'Invalid common name (CN) 0x1000
'Invalid date or certificate expired 0x2000
m_ServerObj.Send xml
The error occurres when Send is called
ERROR_WINHTTP_SECURE_CHANNEL_ERROR: This is a generic error thrown whenever Schannel.dll encounters a SSL version / feature / cipher / key-length / etc. it doesn't understand or support, or when the server (in the case of a client) will not negotiate for anything the client supports. WinHttp relies on it (which is part of the OS) to provide support for SSL / TLS secure channels.
Now, in your case, a few reasons could explain this error, but since connecting to the server in question still works under Windows XP when it fails on Windows 2000, I don't think this failure is related (yet) to those SHA-2 signatures. [more details at the end]
1) SSL 3.0 or TLS 1.0 disabled
First thing I would check: open "Internet Options" from the Control Panel, switch to the "Advanced" tab, and in the options make sure SSL 3.0 & TLS 1.0 are checked. If you had to tick any of the two, a reboot will be needed. Then check again. (afterwards, if it still fails, you're free to disable SSL 3.0 if you wish i.e. because of POODLE)
2) Disabled / Missing CSP or no CSP provides support for the required cipher(s)
Schannel.dll makes use of the available cipher suites as provided by the different Cryptographic Service Providers (CSP) installed on the machine. If none of the CSPs provide support for the cipher(s) required by the server, then the HTTPS connection will fail.
I don't know in details the difference between the exact list of ciphers available on Windows 2000 versus those on Windows XP. Well, I know AES support was introduced with Windows XP & Windows Server 2003, and SHA-2 support (hashing using the CryptoAPI, not those SHA-2 certificates for TLS) was introduced as part of Windows XP SP3. As for Windows 2000, the MSDN page Cipher Suites in Schannel doesn't say anything about Windows 2000, but the list of CSPs included with Windows 2000 can be found in the page Microsoft CryptoAPI and Cryptographic Service Providers. More research would probably give you more details on what is supported on Windows 2000 and what's not.
If the error is indeed related to the installed/available CSPs, then the discrepancy between Windows 2000 and Windows XP would mean one of three things: a) a cipher or cipher suite, available on both Windows 2000 and Windows XP, has been disabled for Schannel on that/those Windows 2000 machines; read How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll to find out which registry keys are used to disable cipher/cipher suites, so you can check if it's the case. b) a cipher or cipher suite, available on both Windows 2000 and Windows XP, is missing/not registered on that/those Windows 2000 machines; there is no easy way to check this, but if you get that connection error on every Windows 2000 machine you try, then c) would make more sense. c) a cipher suite, bringing support for at least one of the ciphers (e.g. AES) required by the server, was only introduced in Windows XP and is not available for Windows 2000; you're then out of luck, if you stick with WinHttp anyway.
By now you should have a few cues on what could cause the error (my bet: AES is the minimum being required)
About those SHA-2 certificates
Support for SHA-2 signatures (superseding SHA-1) was introduced with TLS 1.2. If you didn't know yet, the only Windows OSes supporting TLS 1.2 (and thus certificates with SHA-2 signatures) are Windows 7, Windows Server 2008 R2, Windows 8+ and Windows Server 2012. This of course should not affect most applications (e.g. Chrome uses BoringSSL, a fork of OpenSSL) unless they depend on Schannel.dll, like WinHttp or most other Windows components.
SHA-1 certificates are expected to be gone by January 1st, 2017. By then, more and more servers will have ported their certificates to the SHA-2 variety, so expect more HTTPS connection failures for WinHttp under Windows XP & Windows Vista. It makes sense, after all; support for Windows XP finally came to an end on April 8, 2014 (Microsoft had already dropped support for Windows Vista) and the last Windows OS not supporting TLS 1.1 & 1.2, Windows Server 2008, reached end of mainstream support this January.
So, what should you do?: Either stop supporting Windows 2000 & XP, or find a replacement for WinHttp that uses a SSL/TLS library, e.g. OpenSSL, being regularly updated. Maybe libcurl?
Final note: Unless you use a self-signed certificate or a certificate without a valid chain of trust for the server, you really should leave WinHttpRequestOption_SslErrorIgnoreFlags to &H0& (otherwise, what's the point of using SSL/TLS?)
Related
We have an web app in Java for GlasFish server, we set cipher to TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but IE11 wont open a page at all, saying we need to enalbe TLS 1.0, 1.1 and 1.2
These were enabled in Advanced settings but still no luck. Installed Chrome and it opened a page with no problem.
Trying to open the same page using IE11 from Windows 8.1 gave no problem, too.
Tried to disable Enhanced Security for IE on ser
Any hints, please?
Cipher support differs between browsers and operating systems and new ciphers also sometimes get added with patches. To get an overview which ciphers are probably supported by a specific system have a look at SSLLabs.
In any case it is recommended that you are using a set of secure ciphers to support the variety of systems and that you don't restrict yourself to a single cipher, especially an advanced and TLS 1.2 only cipher like the one you have chosen.
A little while ago we received an email from the Azure Team regarding an upcoming TLS/SSL cipher suit update, kicking in after July 18th with the following instruction:
You can check whether the clients that access your web apps will still function correctly by testing them against https://testsslclient.trafficmanager.net/. Your client is compatible if you receive a 200 HTTP status—the page will display a “SSL client test complete!” message.
After testing our standard clients it looks like IE7 and IE8 fail the test on XP SP3 (Chrome still works).
Does anybody else have results of what clients are expected to fail? (It would have been nice if the Azure Team would have provided a list of expected incompatibilities).
Also: the test page uses an SHA2 certificate. We are still using SHA1 on some sites, due to be updated eventually. Does anybody know if the update will have any impact on SHA1 certificates?
Related link
Yes, XPSP3 IE 7/8 will fail because they don't support any of the ciphers that will be on the updated list. I don't think we have a list of clients that will / will not work, because the list is quite large ... you have to worry about embedded devices like PoS terminals etc, and not just browsers.
SHA-1 certificates will still be supported in Azure WebApps, although some browsers like Chrome will complain about obsolete cryptography etc.
We have repeated our tests today and IE7 and IE8 on XPSP3 now pass the client test at https://testsslclient.trafficmanager.net.
We assume the implementation of the TLS/SSL cipher suit has been updated to allow for this now...
I'm trying to add SNI to my client-side program (C/C++) that uses Microsoft SDK's Schannel API for TLS.
I've searched everywhere but could not find any documentation on how Schannel supports SNI extension.
I looked up the documentation for AcquireCredentialsHandle(), InitializeSecurityContext() but no success.
So, could anyone please help me with some example code?
The SNI is specified as part of the ClientHello, which is generated by InitializeSecurityContext(). Specficially, Schannel uses the 3rd parameter of that function for certificate validation, as well, as SNI; but not all versions of Windows support TLS extensions (which includes SNI).
TLS Extensions were first introduced in Internet Explorer 7 beta 3 on Windows Vista. Plus, even if your operating system supports it, TLS will likely be turned off, by default.
There is a working example on CodeProject that shows SNI from the client and server side.
My company makes a measurement device that connects to the PC via USB and used to use the Windows in-box USB HID driver. I'm using a different driver now to control the device and I am in the process of signing these drivers for many Windows versions. The reason being we want our customers to be able to install our measurement software (which would pre-install these new drivers), plug in our measurement device, and have Windows trust and use our new driver in favor of the in-box USB HID driver. It would also have the added benefit of using this new driver each time the device is connected no matter what USB port is used or if the user connects a unit that has a different serial number in the descriptor.
I've read through and performed the steps outlined in the KMCS_Walkthrough written by Microsoft to perform Test Signing of this driver by creating a catalog file for Windows 7 x64 from the inf file and signing the catalog file with a self-signed certificate. Things seemed to work smoothly on a Windows 7 x64 machine when rebooted into Test Mode. What surprised me was that I was able to create an XP_x86 catalog file, sign it with my test certificate, import my test certificate into the Trusted Root store and get the driver behavior I wanted on a Windows XP machine. The default driver signing policy was set to the default (Warn - Prompt me each time to choose an action).
I'm surprised because all of the MSDN documentation I have been reading about signing drivers for public release for XP seems to have a strict stance on the drivers being WHQL certified in order for the drivers to be fully trusted as opposed to obtaining a code-signing certificate from a third party and using that to sign the driver. Is this not true? How could my self-signed drivers out-rank the in-box USB HID driver in Windows XP?
I think your experience is normal.
At my company, we have distributed USB drivers to Windows XP users and we never had to sign them to get them installed. We later starting signing them ourselves, but that did not really affect the Windows XP user experience.
Our drivers were usually INF-only or they used WinUSB, so that might be different from you if you are compiling binary drivers.
Without a WHQL signature, Windows XP users can still install your driver package as long at they click through this warning:
After the driver package is installed, in my experience there is nothing that prevents the kernel modules it contains from being loaded into the kernel. However, our users always had to go through the "Found New Hardware Wizard" whenever plugging a new device into their computer for the first time.
Perhaps your driver outranks the HID driver because you picked a more specific identifier string (i.e. one with a vendor ID and product ID in it).
For more information I recommend reading my article: Practical Windows Code and Driver Signing.
After A LOT more trial, error, and research, I've finally come to a conclusion.
The key in my initial question was that I was using a self-signed certificate. I generated the self-signed certificate in Windows using makcert and following the example in the KMCS_Walkthrough:
makecert -r -pe -ss PrivateStore -n CN=CompanyName MyCertificate.cer
The parameter which specifies what Enhanced Key Usages (EKUs) the certificate should be valid for (-eku) is not included. What I didn't know was that with this parameter missing, this creates a self-signed certificate with ALL EKUs. Most notably the EKU called "Windows System Component Verification (1.3.6.1.4.1.311.10.3.6)". This EKU is included in certificates for WHQL signing.
So, in fact, Windows XP was behaving appropriately. My driver was indeed WHQL signed, it was just a self-signed WHQL certificate that was used.
I need to implement a server running on Windows CE 5.0 that shall communicate on a secure connection. To implement a secure connection SSL looks like a good choice.
The Windows CE 5.0 Winsock implementation allows to implement all the SLL stuff using the Winsock Secure Sockets. But the problem is that the referred site states:
SSL does not support the following Winsock functionality ... "Calls to the accept function".
How can I implement a SSL secured server when accept will not work? What other options do I have to implement a secure connection to a Windows CE 5.0 device?
Edit: My current application implementation is in C++. So I would prefer an approach that use the Windows API or a C++ library.
We ported the Mentalis Secure Socket Library to the Compact Framework for when we needed SSL. It was fairly painless, though not without its bugs.
MatrixSSL supports Windows CE:
MatrixSSL™ is an embedded SSL and TLS implementation designed for
small footprint applications and devices. Available is a fully
supported, commercial version as well as an open source version that
is available for download. MatrixSSL allows secure management of
remote devices. Several secure embedded Web servers also use MatrixSSL
for their encryption layer.
MatrixSSL has been ported to operating systems including
FreeRTOS, Bare Metal, eCos, VxWorks, uClinux, eCos, FreeRTOS, ThreadX,
WindowsCE, PocketPC, Palm, pSOS, SMX, BREW, MacOS X, Linux and
Windows.