I did exactly, what you did in your post, bur I haven't got a solution yet.
Post by Michael Bauers
I have been trying to figure out how I can write umanaged C/C++ code to
implement some sort of secure socket communication.
I have spent quite a lot of time reading through MSDN documentation, without
getting anywhere. I need code which runs on Windows Server 2003 and later
I was able to get some SSPI sample code to work. MSDN's sample code would
not even compile. I spent a fair amount of time figuring out how to make it
compile and run correctly. The code was rather lengthy with lot's of
required handshaking calls. It was not ideal.
Ideally I would write code where data sent across the socket was
automatically encrypted and decrypted.
I looked into Open SSL, but I am not allowed to use it.
I was also frustrated by not being able to locate specific information on
SSL(TLS). According to the MSDN documentation, Secure Channel allows for TLS
(http://msdn2.microsoft.com/en-us/library/aa380516.aspx.) But I could not
locate any coherent documentation on how to implement TLS using Secure
Someone helped me last week with this, and while their help was appreciated,
it has not led me to a coherent solution I can field.
I am looking for a non third party way (secure channel?) of implementing a
secure socket. Ideally the data is automatically encrypted. I need to be
able to code it in umanaged C/C++ and it needs to run on Windows 2003 server
and later. I am looking for concrete documentation I can use to code a
solution. I am willing to buy any book which covers this topic.
Any help is most appreciated.
Post by Alun Jones
Sorry, but that's really what it takes.
You have to find a way to deal with crypto problems as opposed to networking
problems. That's one big reason why you won't find many class libraries
designed to make secure sockets look "just like" regular sockets. There are
a number of functions that you will need to do that have no socket
equivalent (for instance, closing the SSL session without closing the TCP
The documentation isn't the best. Probably better is to read the webclient
and webserver samples in the SDK - these give you everything you need in
order to implement SSL / TLS support.
I would definitely suggest reading Eric Rescorla's book on SSL / TLS, so
that you don't screw up the security.
Then, the process is just as described in
http://msdn2.microsoft.com/en-us/library/aa374781.aspx (Creating the
SChannel Security Context), and in
http://msdn2.microsoft.com/en-us/library/aa380138.aspx (Shutting down an
It's all described at
http://msdn2.microsoft.com/en-us/library/aa374782.aspx, in a whole lot more
detail than it was when I started writing SChannel code :)
Post by Chris Becke
hmmm. In theory a SSL implementation needs to support features like that. In
practice however, there doesnt seem to be that much expense in binding the
ssl session with the tcp session. If either one closes, close the other, and
re-open from scratch.
What I personally find *really* tragic is how easy SSL is to do on Windows
CE. A call to setsockopt before calling connect is all it takes. Ans a call
to WSAIoctl so you can validate the server cert.
I really dont understand why ssl on regular Win32 needs to be harder than
Post by Michael Bauers
I found an example of using Schannel for SSL in the platform SDK. But I
can't get past calling 'AcquireCredentialsHandle' in the server module. I
needed to get a certificate and install it. That part seems to work ok in
that I am able to open the certificate store and get the certificate.
I always get back SEC_E_NO_CREDENTIALS(0x8009030E)
Status = g_pSSPI->AcquireCredentialsHandle(
NULL, // Name of principal
UNISP_NAME_A, // Name of package
SECPKG_CRED_INBOUND, // Flags indicating use
NULL, // Pointer to logon ID
&SchannelCred, // Package specific data
NULL, // Pointer to GetKey() func
NULL, // Value to pass to GetKey()
phCreds, // (out) Cred Handle
&tsExpiry); // (out) Lifetime (optional)