[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/7ca731d0 - PLEASE DO NOT REPLY BY MAIL.]
> well bro you are right that its quiet insecure, but thing is that our > client want this approach :) so we have to implement it. I am very sorry to hear that. So they are using obsolete technology that can easily be broken by anyone with the resources and motivation to intercept a FIX session, which has design flaws that make the session more fragile, uses a combination of cryptographic protocols that together has not undergone rigorous academic review, and is likely going to be costly to implement for all of the firm's trading partners as it requires invasive FIX engine modifications. Again, I strongly suggest recommending use of SSLv3 or TLS to the client. These have had rigorous academic review. The OpenSSL library is put under intense scrutiny, as is the "stunnel" proxy. Implementation with stunnel is fairly trivial and non-invasive. Alternately, bolting OpenSSL onto an engine is far less invasive than doing the same thing for PGP/DES-MD5, so I would imagine it would be lower cost. It does not introduce the instability problems that PGP/DES-MD5 does. And it actually provides a real level of security. > 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. In my opinion, a bigger concern is that resend requests become extremely fragile as soon as PGP/DES-MD5 is employed. The issue is that PGP/DES-MD5 uses DES in Cipher Block Chaining mode. This means decrypting a block requires the ciphertext of the block sent prior to it. If a message goes missing, or some kind of reordering occurs, it will corrupt the next message. Specifically, the first 8 bytes of the encrypted data will be decrypted, but will then be XOR'd with the wrong previous ciphertext block, so the plaintext is corrupted. Unfortunately, there is no easy mechanism to catch this! The FIX checksum will be valid. The MD5 "Signature" will be valid, as well, as it is made from the ciphertext, not the plaintext. It follows that when responding to a Resend Request, one can't do what one does in normal FIX, e.g. keep the body and most of the header the same, update SendingTime and add OrigSendingTime, add a PossDupFlag, recompute the message length and checksum, and send it out. Because CBC mode is used, it becomes necessary to re-encrypt the plaintext as well, this time using a different initialization vector. None of this is an issue with SSLv3 or TLS. Resend request processing is identical; either the proxy application (e.g. stunnel) or the SSLv3/TLS library takes care of things. > Thanks for your time and help, it really helped me. You are welcome! [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.
