Support various internet security features better

[mmehr2]

Pubnub has code to support several security features that more and more customers are requiring. This Issue is to make note of the need to support this in code.

• Proxy connections - some setup configuration required here (INI file?), then the code (provided in the lib)

• Using TLS for connections - the basics of keys and the like are provided, as is the ability to use local key storage facility (in Windows? need to make sure)

[mmehr2]

A new version of the Pubnub SDK library is required, plus the addition of a version of OpenSSL. They recommend a particular brand, so I will look into adding this to the 3rd Party code. We would like to build static libraries, so no extra pieces are required at runtime, and then we have to add in the proper include and lib paths and libraries. Hopefully all configuration would be done by the Pubnub code, but we do have to add our own configuration of the Pubnub code to that.

All of this should be able to be added to startup code in MSW, so it just happens. I'll study this a bit more to see if there are any gotchas generating extra development work, or even runtime behavior.

[mmehr2]

Work Tasks: We need to support TLS messaging and proxy connection, same as Pubnub. If they add future support for other security things, we add those too.

Phase 1: Secure messaging using Windows Key store.

• [ ] - Add configuration options (settings) for SSL on/off and other flags.
• [x] - Recompile the code libraries to use openssl
• [x] - Download and compile openssl v1.1.0g for Win32
• [x] - Include the proper paths to these libraries in the R build configurations (/openssl replaces */windows). Add in the necessary LIB files for OpenSSL (there are only 2 out of 5 or 6).

Phase 2: Proxy support and tweaks.

• [ ] - Add code to negotiate the proxy calls on a private thread and add state to the comm initialization sequence. Use SDK calls (new: see *NOTE***) to copy proxy settings into Receiver and Sender contexts.
• [ ] - Configuration settings for manual proxy setup (protocol, URL, port, username, password)
• [ ] - Add code to use other storage methods for security keys for TLS/SSL.
• [ ] - Configuration Settings for security fallback strategy (Ph.1 is OFF,OFF)

*NOTE***: Ph.2 Requires new version (after 2.3.2) of Pubnub C SDK to do copying of settings. Before this, the call that negotiates settings must be made twice, with the actual contexts in use by the comm class (private objects) - this is a bad design, and also takes twice as long.

[mmehr2]

Completed work tasks:

• Recompile the code libraries to include openssl
• Download and compile openssl v1.1.0g for Win32
• Include the proper paths to these libraries in the R build configurations (/openssl replaces */windows). Add in the necessary LIB files for OpenSSL (there are 5 or 6).

The problem is, once this was done, there were two unresolved externals. One shows that the OpenSSL-Win32 libraries from Shining Light Productions have been built with a newer version of the compiler (VS2012+ have the /GS option that generate stack check calls to a routine that the VS2010 runtime library does not include). It may be possible to find the missing code in newer library source code and back-port it (ouch!). Or we could explore using the OpenSSL DLLs instead, which would complicate the install a bit. Or do our own compilation of OpenSSL, but I'm sure that's a big headache, given that businesses like Shining Light and others do so well.

The other error is for a function (_dtoui3) that is part of the SSE2 architecture requirement. It might go away if we change the architecture of our target and rebuild (test this), but this would add a hardware requirement for end users of MSW that might or might not be okay for ECS' customers. Might need to explore this with Eric.

[mmehr2]

Another option is to remove the security requirement. We need to talk about that still, at least if it's negotiable with the customer. If not, we need more time to explore these options, due to the legacy code problem and the other tradeoffs mentioned above.

Recompiling the OpenSSL source code may take a while, and not even be an option. We could try approaching the Shining Light developer about it, but he does require a $225 minimum donation for commercial use of their library. I can't tell if other library builds out there are compatible with VS2010 static usage. We need time to figure all this out.

[mmehr2]

Most recent reply from Vlad at Pubnub indicates that it should work to use the DLLs for the SSL libraries. That should alleviate the problem with the legacy builds as well. He says that hardly anyone tries to use these as statics any more.

He also gave some helpful tips on using the secure connections better.

[mmehr2]

It seems from usage statistics on Pubnub that if the SSL libraries are made available to the code, and the cert.storage area of Windows is configured and working properly already, it "just works" and all message traffic seems to be using SSL now. I guess the defaults are on, even when you don't enable the APIs to control them. Free feature! It would be good to have registry-level control options in place, though.