[This message was posted by Ryan Pierce (FPL Technical Director) of FIX Protocol Ltd. <[email protected]> to the "Information Security" discussion forum at http://fixprotocol.org/discuss/3. You can reply to it on-line at http://fixprotocol.org/discuss/read/75361540 - PLEASE DO NOT REPLY BY MAIL.]
> One more question for the SSL implementation are following steps ok?: > 1. Fix Engine download > 2. Stunnel Setup > 3. Overwrite the libray from Stunnel folder with OpenSSL library.. > 4. Integrate this library to FIX code.. > > Am I right..? Any other ways...? Not exactly.... The two alternatives to implement SSL (or TLS) in FIX are: 1. Use a FIX engine that includes SSL support, or 2. Use a proxy, such as stunnel, that will take an unencrypted connection from a FIX engine that doesn't support SSL and encrypt it with SSL, or vice versa. To be clear, stunnel is a proxy server application that uses the OpenSSL library for SSL security. OpenSSL is the low level library that does SSL; stunnel is one of many higher level applications that use the OpenSSL library. In the example above, if you were going to integrate SSL support directly with a FIX engine, you'd likely use the OpenSSL library itself, and you'd have no need for stunnel. Alternately, you can use stunnel if your FIX engine does not support SSL and either you don't want to modify it, or you don't have the source code and can't modify it. stunnel is a standalone application. It is used in two modes: A. If you need to initiate an encrypted FIX connection, you run stunnel and configure it in such a way that it will accept an unencrypted session and originate an encrypted session to your counterparty. In this case, you tell your FIX engine that your counterparty is the IP address and port that stunnel is listening on. You tell your counterparty to expect an encrypted connection from your stunnel server's IP address, not your FIX engine's IP address. stunnel will then make an outbound encrypted session to your counterparty. B. If you need to accept an encrypted FIX connection, you can run stunnel and configure it in such a way that it will accept an encrypted session, validate the certificate to guarantee that it is the proper counterparty, and then originate an unencrypted session to your FIX engine. In this case, you give your counterparty the IP address and port that stunnel is listening on, not the IP and port of your FIX engine. Likewise, your FIX engine will receive a connection from the IP address of your stunnel server, not the actual client. In both of these cases, the FIX engine is not modified and knows nothing about FIX. stunnel is a free open source product, so it is probably the most cost effective solution if your FIX engine doesn't support SSL directly. But it results in a more complex production environment and adds an extra network hop. This can be lessened by running stunnel on the same server as your FIX engine, but extreme care must be taken regarding firewalls and network security. In all cases, it is very important to note that there are a lot of security considerations that must be understood when setting up stunnel, or SSL itself; these are documented in the white paper referenced above. [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
