[This message was posted by Russell Curry of Assimilate Technology, Inc. <[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/1494aeab - PLEASE DO NOT REPLY BY MAIL.]
Hi Ryan, > > 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. The problem with assumptions is that they're usually wrong - My previous post started with "Hi Mark," not "Hi Ryan," so don't take it personally. > > 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. I'm confused - where did anyone say SSL/TLS are comical? I'll take the risk of making an assumption this time and guess that you are mistaking my comment about "comical security mechanism" to refer to a specific technology - it doesn't. What I am referring to is the fact that when a vendor who is not in the security business tries to implement their own security, they often do it, uh... poorly. > 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. If we're talking specific technologies, I'd tend to agree - all of these systems you've mentioned receive a certain degree of scrutiny by the open-source and commercial security community. But the degree of assurance afforded by a specific technology goes out the window if you rely on a vendor who is not really in the security business to implement it properly. The fact that people do this doesn't invalidate the fact that it's still a bad idea. I'll stick by my assertion that a dedicated piece of hardware from Secure Computing, Cisco, or any other firm that specializes in high-assurance security hardware, is going to be a lot safer out of the box than a software solution that's thrown together by the programming staff of ACME financial systems. > 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. The computer security folks have a term for this, it's called a "trusted system." It doesn't really matter how the mechanism is manifested, it needs to be trusted. In other words, relying on you to fiddle with your software bits is no less dangerous than relying on the network people to fiddle with their hardware bits. Of course if you can't trust your network people to keep your network safe, well, tell me how exactly are you keeping the software safe? If the networking people can't be trusted - it seems only natural to ask why you're so confident in the compiler running on your PC... [SNIP: history of the internet / networks can fail...] Yes, I would have to agree that a system which has been configured not to work, probably won't work. I can tell you how intelligence agencies solve this problem - they put the important stuff on one network, and the not-so-important stuff on a different one. Oh, and then they don't connect any cables between them... But, we're talking about two different things here - one is the overhead of maintaining a trusted system, the other is the level of assurance afforded by it. And so, we're back at square one: a high assurance system from a vendor that specializes in such things, is generally a safer bet that a low assurance system from a vendor who does not specialize in such things... > 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. This is why log files are the first to go when a system is compromised, because people have a bad habit of thinking that the software writing the log file today is the same software that was writing the log file yesterday. > 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. Horses for courses, but I think I'd take the challenge of making sure that a piece of high assurance hardware has the switch set to "ON" over the challenge of making sure that piece of homebrewed software is high-assurance in the first place. They are two distinct challenges, and one is easier to deal with than the other... > 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. I too strongly disagree that SSL/TLS should be considered comical, let's go find the guy who said that, and make fun of him! [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.
