Windows Mobile Secure Socket Implementation Series 4: Changes in Windows Mobile 5.0 platform

Windows Mobile Secure Socket Implementation Series 4: Changes in Windows Mobile 5.0 platform

In previous three posts on Windows Mobile secure socket implementation, I talked about:

• general ideas
• source code to prepare a socket for secure connection, to crack a BLOB into a X.509 Certificate, and the callback to validate a X.509 certificate
• subject and CN in X.509 Certificate, and the approach to support wildcard certificate

In this post I will list the changes of secure socket implementation from Windows Mobile 2003 devices (based on Windows CE 4.2 .NET) to Windows Mobile 5.0 devices (based on Windows CE 5.0 device).

Newly added: remote host name verification

In 5.0 platform, Microsoft adds a new control code SO_SSL_SET_PEERNAME. With such control code, the remote host name is verified by Winsock against the server certificate after a successful SSL handshake. The verification results are then indicated in the certificate validation callback function via the dwFlags parameter. If the specified host name does not match the one indicated in the certificate chain of the SSL Handshake, SSL_CERT_FLAG_ISSUER_UNKNOWN is set in the dwFlags parameter.

It is simple to use the control code:

char* pchHostName = "www.example.com"; // passing somewhere
sockerror = WSAIoctl(in_socket, SO_SSL_SET_PEERNAME,
   pchHostName, strlen(pchHostName)+1, NULL, 0, NULL, NULL, NULL);

Notice you need to use strlen(hostname)+1 as the input buffer length (to include the NULL terminator).

If you go through all my previous three posts, you will immediately find that my code actually is doing the same thing in the certificate validation callback function, but I need SslCrackCertificate to crack the BLOB into a X.509 structure. I think the reason why Microsoft adds this new control code is because SslCrackCertificate and SslFreeCertificate are not publicly documented.

My own test reveals that SO_SSL_SET_PEERNAME does not recognize wildcard certificate. Microsoft code possibly just did a literal match between the desired host name and the CN from the subject, like what I did in my sample code.

Warning: If you need to support wildcard certificate, do not use SO_SSL_SET_PEERNAME.

More subtle changes during SSL handshake phase

My experiences dealing with Windows Mobile users tells me: A lot of users forgot to set up their devices' time after a hard-reset. It is not a big deal for smartphones, as the phone can synchronize the time via air. For Pocket PCs, the time is reset to the factory-default one. For example, in my Sprint PPC6600 device (Windows Mobile 2003 SE), the time is reset to some day in 2004.

Why the time matters to secure socket programming? Remember we need to validate the lifetime of a server certificate. If the certificate is already expired, there is no reason we should trust the server, but we may present a dialog to the user, and let the user to decide whether to connect or not. However, in the case of a hard-reset device, the certificate's starting time actually is later than the device's current time. Take PPC6600 device as an example, the current time returned by GetLocalTime() is year 2004, but the server certificate is valid from year 2005 to year 2006. What gives?

You may simply ignore the "post-dated" certificate and continue to establish a secure connection. Better, as a programmer with good sense, you may present a dialog reminding the user to set up the time correctly. The above logic is natural to implement in Windows Mobile 2003 platform; in which, the server certificate is passed into the validation callback function as "normal" by Winsock, so you have the chance to test the lifetime of the certificate.

However, the behavior changed in 5.0 plaform. If the current time of the device is earlier than the starting time of the certificate, dwFlags now contains SSL_CERT_FLAG_ISSUER_UNKNOWN, . IMHO this is a very misleading flag. Now the programmer has no idea whether the server certificate is really a bad one, or the certificate is good but the device's time is bad.

Wrap-Up

You do not really need to change source code in 5.0 platforms, if you do not plan to use the newly added SO_SSL_SET_PEERNAME feature. And, you should not use it at all, if wildcard certificate needs to be supported.

In 5.0 platforms, you lose the capability to gracefully handle a device which has a bad time setting.

Category: [SSL / Socket / Networking / Connection Manager]

====>SiteMap of this Blog<===