[This message was posted by Muhammad Amir Ul Amin of Kolachi Advanced Technologies <[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/f53364aa - PLEASE DO NOT REPLY BY MAIL.]
Hi Ryan, delighted to see an answer on my question, well bro you are right that its quiet insecure, but thing is that our client want this approach :) so we have to implement it. on your question, to avoid a replay attack I have encrypted it, but now after thinking so much on your question I believe that I should not encrypt a session level message except Logon. Thanks for your time and help, it really helped me. M. Amir Ul Amin > > Can anyone please tell me that where should I put BeginSeqNo (Tag#7) > > and EndSeqNo (Tag#16), in encrypted section or in unencrypted, while > > sending the ResendRequest using a PGP/DES-MD5 algorithm to secure > > the data. > > > > Desperately waiting for a reply. > > These tags are not listed as ones required to be unencrypted, so I don't > believe it matters. > > As session-level messages contain no confidential business content, I > question what value there would be to encrypting a ResendRequest. > > However, I also question why PGP/DES-MD5 is being used in the first > place. It was effectively proven insecure many years ago when the DES > was cracked using relatively inexpensive hardware. It is also, in my > opinion, extremely fragile and difficult to implement. > > Most firms that require encryption will either: > > 1. Do it at the network level, such as IPSec, either within the server's > network stack, or via routers or VPN boxes, so it is completely > invisible to the FIX applications, or > > 2. If initiating a session, have their FIX engine connect unencrypted to > a proxy server which then makes an encrypted connection outbound to > their counterparty. Or if accepting a FIX session, have their > counterparties connect encrypted to a proxy server that, upon > connection, makes an unencrypted connection to their FIX engine. > Usually, SSLv3 or TLS are the protocols of choice. The open source > program "stunnel" can act as the proxy, or > > 3. Embedding an SSLv3 or TLS library in their FIX engine to support > encryption directly. In this case, no application or session level > changes are made to FIX; the data is simply routed through the > library, which manages the TCP socket connection. > > The Information Security Subcommittee has produced an extensive white > paper on this topic here: > > http://fixprotocol.org/documents/3868/FIX%20Security%20White%20Paper- > 1.8.doc [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.
