[This message was posted by Ryan Pierce of CME Group <ryan.pie...@cmegroup.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/c1be5521 - PLEASE DO NOT REPLY BY MAIL.]
> Simon is giving you the best advice here. If you can do this with network > hardware, you're a lot less vulnerable than if you rely on some comical > security mechanism a vendor has implemented in their own software product. Russell, Since I'm the only person other than Simon who has responded here, I'm assuming you are responding to my post. SSLv3 and TLS are anything but comical security mechanisms. They are the de-facto standards for transport layer security, supporting AES-128 and AES-256, which I would consider state of the art. They receive considerable scrutiny by the cryptographic community. Vendors generally don't build their own SSL/TLS implementations. They either use OpenSSL (which likewise receives considerable scrutiny), or use a library from another provider. The stunnel proxy application uses OpenSSL, and stunnel likewise receives considerable scrutiny. Granted, it is possible to implement a perfectly good SSL/TLS library poorly, either in a FIX engine or in an stunnel configuration, and introduce security issues. However, IPSec usage has its own issues and disadvantages as well. For starters, if IPSec is implemented at the router level, then there is no visibility into its operation at an application level. I have to trust that the network staff has it turned on, that my FIX traffic is only routing over the particular link where it is turned on, and that these facts won't ever change. Routing often uses dynamic protocols to detect failed links and reroute data around them. When new links come up, routing tables can shift to send data over new routes. The same path that data takes to get from Point A to Point B may not necessarily be the same path it takes on the return trip, and each of these may change from today to tomorrow. All of this makes sense when one considers that the Internet protocol suite was designed in the 1970s, where the goal was to create a defense network that could survive a nuclear attack. But this becomes a problem if a dynamic routing change causes a highly confidential FIX session, or even one side of it, to stop routing over the encrypted link, and to use an unencrypted link instead. Firms can sometimes inadvertently consume each others' dynamic route updates, causing various weirdness, and intruders can launch routing based attacks. In all of these cases, the FIX Engines themselves would know nothing of it. Nothing would appear in any application level log. Unless both parties were continually running traceroute, nobody would know. It's been many years since I was hands-on with networking, but I've seen some pretty weird routing issues, enough to know that I can't blindly trust it. Also, there's an implicit assumption. Firm X has encrypted VPN Y to Firm Z, so Z assumes anything coming over VPN Y originated with X. That isn't necessarily true. VPN Y would need to be secured so that only authorized users at Firm X could access it. How does Z know if the connection coming over Y originated with X, or with someone sitting outside X's office using X's WiFi? Compare this to a FIX engine with integrated SSL/TLS. All the configuration happens at the application level. The engine is configured to require a certain X.509 certificate, and to use a certain certificate itself when connecting. Log files likely can confirm all of this, with timestamps showing which party connected with which certificate. In other words, instead of worrying about the security of every router, routing protocol, and VPN along the path, my primary concern is whether the keyfile on my FIX engine is safe. Properly configured, IPSec can be very secure, but it requires substantial diligence in setting up firewalls, routing protocol configuration, etc. I disagree that it is inherently superior to SSL/TLS, and I strongly disagree that SSL/TLS should be considered comical. [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-protocol@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.
