[This message was posted by Kalyan Moholkar of FinIQ India <kalyan_c...@yahoo.com> 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/66cdc96b - PLEASE DO NOT REPLY BY MAIL.]
Hi Ryan, Thanks for the help. With respect to multiple instances of stunnel I am able to connect to two different server. I am curious if it is possible to make two connection from same conf file. Is there any way like multiple logical interfaces which will use single conf file and will connect to two different servers..? I read stunnel website that stunnel 4.x version supports multiple connect but unable to find the proper way for how to do it. Regards, Kalyan > > Does anybody knows how to use stunnel with FIX 4.2 for multiple connections > > from clinet side(initiator)...? > > > > As Stunnel has only one configuration file is there any way out...? > > Any connect method changes...? > > The GTC Information Security Subcommittee had discussed creating a white > paper or HOWTO document on usage of stunnel, but this never happened. After > the SC published the Information Security White Paper (which included some > technical tips regarding use of stunnel), it stopped meeting. If there is > interest, and subject matter experts on stunnel who would be willing to > contribute to such a paper, it can be restarted. > > It's been a while since I've looked at stunnel, and there may be a better way > to do this, but from what I remember: > > You can run multiple instances of stunnel, pointing each instance to a > different config file. This would require that each stunnel listen on a > different TCP port number. In other words, each client connects to a > different port, and each stunnel has a config file that lists that client's > specific certificate(s) as the only trusted client cert(s). > > It is probably a good idea if your FIX engine also listens on different > ports, and binds each port to a client identity. The reason is that stunnel > cannot validate FIX fields. Imagine the following config: > > * Broker A connects to your stunnel port 5001, which is configured to accept > Broker A's cert only > * Broker B connects to your stunnel port 5002, which is configured to accept > Broker B's cert only > > If both stunnel instances forward to the same port on your FIX engine, then > spoofing is possible. E.g. Broker A can connect to stunnel port 5001 using > Broker A's cert but send FIX messages with Broker B's CompID. If both stunnel > instances point to the same FIX engine, then the FIX engine doesn't have any > way of recognizing that something is wrong. But if the first stunnel connects > to your FIX engine on port 6001, and your second stunnel connects to your FIX > engine on port 6002, and your FIX engine is configured to accept only Broker > A traffic on 6001 and Broker B traffic on 6002, then this should prevent > spoofing. In the example above, Broker A using Broker A's cert and Broker B's > CompID would get through stunnel, and would be connected to the FIX engine on > port 6001, but the FIX engine would not allow the connection because the > wrong CompID is present. > > There was an effort many years ago to create a smarter client proxy, which > could listen on one port, could accept different clients with different > certs, and could validate that the CompID each sent was appropriate based on > the cert. It was called Poppy. However it hasn't been actively developed in > over a decade, and it appears to have been removed from the FPL website. The > advantage of stunnel is that it is widely scrutinized and actively maintained. [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+10093...@fixprotocol.org] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-proto...@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
