Imported from previous forum
Hi all,
We are just commencing a small project which would see FIX transactions sent over the WWW. Most of the end-points are IRESS user agents. Obviously, due to the plain text nature of FIX this is not desirable or acceptable. Is there any end-point product out there that natively supports IPSec? Any ideas?
Hey Mark,
Yes, you are correct. Sending plain-text over the internet is not wise 
Unfortunately not a lot of buy/sell side network elements natively support the concept of IPSec due to the use of private LANs and WANs. As for the product you mentioned, I suggest to check out (and enquire regarding) their product road map. Alas, I know the answer is no from personal experience. 
However, there are easy methods to use IPSec to protect FIX (over the internet). I suggest installing a router with IPSec on both sides (buy/sell) just before your FIX network elements. This way, both the end network elements can speak plain-text FIX, and the routers will encrypt and decrypt the FIX as it is transmitted over the internet. Using 128/256 bit encryption and AES, this will be impossible to break, and it is safe to sniff with WireShark.
+--------+ +--------+ | | FIX +--------------+ IPSec over the 'net +--------------+ FIX | | | FIX UA +------+ IPSec router +----------------------+ IPSec router +-------+ FIX UA | | | | (encode) | | (decode) | | | +--------+ +--------------+ +--------------+ +--------+
However, there are easy methods to use IPSec to protect FIX (over the internet). I suggest installing a router with IPSec on both sides (buy/sell) just before your FIX network elements. This way, both the end network elements can speak plain-text FIX, and the routers will encrypt and decrypt the FIX as it is transmitted over the internet. Using 128/256 bit encryption and AES, this will be impossible to break, and it is safe to sniff with WireShark.
Hi Mark,
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.
Of course - keep in mind that it’s a lot easier to hack people than it is to hack networks. Internal security is often a hell of a lot more important than network security is…
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.
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!
At the end of the day, most of this is academic. Nobody really cares about sniffing your FIX traffic - there are much easier ways for bad guys to make money illegally. Just ask Bernie Madoff what he thinks about SSL and IPSec…
Hi Russell,
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.
That’s it exactly. Sorry about the assumption that your concern was SSL/TLS.
Whether vendors not in the security business should “implement their own security” is a question that depends on what you mean by the term implement. To resort to analogy: I want to lock my front door.
-
I certainly don’t trust just anyone to create a brand new lock design.
-
I also don’t trust just anyone to take a blueprint for an existing lock design and try to construct a lock.
-
But I am willing to trust a skilled carpenter, and even myself, to take a lock that an expert has designed, where the design has undergone industry scrutiny, which was manufactured by a company that is well known in the business of manufacturing locks and has excellent quality control, and follow the instructions on the package to install it on my front door.
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.
Again, what do you mean by implement?
My #1 case above is like creating a proprietary algorithm or protocol. This sounds very risky.
My #2 case above is like writing an SSL/TLS library from scratch. This also sounds very risky.
My #3 case above is like plugging OpenSSL into an existing FIX engine. This is not as risky.
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.
I maintain that dedicated hardware from Cisco, or a library like OpenSSL, are both comparable. They don’t just plain work. They both have to be installed and implemented. Error in implementation is possible. But just because something is done in hardware doesn’t make it intrinsically better.
Also, I maintain that installing such a hardware solution likely is far more complicated than installing a software solution. Fast-forwarding ahead:
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.
I agree that trusting hardware or software to do encryption is fairly comparable; it doesn’t matter where the bits are flipped.
But the hardware solution doesn’t exist in a vacuum. There’s almost certainly a network switch between the FIX engine and the hardware VPN box. Likely routers, firewalls, and a whole bunch of other computers connected. Add in the possibility of multiple data centers on one or both sides, and redundant links, and the result is extremely complex, and, with dynamic routing, its state can change from one moment to the next. It isn’t just a matter of making sure something is switched on.
I would argue that installing the OpenSSL library into an existing FIX engine is going to be simpler by comparison, and have less possibility for error.
Hi Ryan,
I think we’re both on the same page - I’m also happy to agree with any number of your points on this. I didn’t mean to denigrate anything you had said in an earlier post - my point is that you are taking a big risk when you rely on a firm that doesn’t specialize in security to provide you with a solution for a security problem.
Granted, this hinges on how critical this is for someone - if you just need to check the ‘secure’ box to make the lawyers happy and you don’t really care, then anybody’s product is going to fit the bill. However, if you’re really concerned about the potential for a compromise of some sort, that’s where the situation changes:
Most people don’t have the resources to perform in-house audits to determine the level of security provided by product X, Y, or Z. You have to take a vendor’s word on it, so the key thing here is that if you tell me your product supports SSL, but I can’t audit it and you can’t provide me with an exhaustive audit from a trusted third-party, then I’m really forced to choose between the known quantity of a product from a reputable security firm and a product from a guy who assures me everything is ok, but can’t really demonstrate it apart from waving his hands…
As computer geeks, you know, and I know, that it’s pretty easy to integrate support for OpenSSL into a product, and so on. But if we’re not giving the source code to our customer - and they can’t afford to audit our systems anyway, how do they know what’s going on?
If, on the other hand, you go to Cisco or one of the other big firms, you get a lot of assurance - you know that security is their core competency. You also know that the the government considers large hardware vendors, like Cisco, to be a part of our national security infrastructure, and as such, they get lots of help, consulting and advice (from outfits that have really short names) related to ensuring that their systems are as secure as they can be. This doesn’t make them infallible, but I’m a lot more comfortable knowing that a system has survived an NCSC audit, etc. than just hearing a general purpose programmer tell me that his software is secure.
Of course, like I said - a lot of this depends on the level of risk that you’re concerned about. If you are just worried that a script kiddie may intercept some traffic and post customer information on the internet that might embarass you - then any solution is probably going to be good enough to deal with that adversary. On the other hand, if you’re concerned that a skilled, dedicated adversary may try to sneak in and compromise your encryption technology (for whatever reason) it’s going to be more difficult for him to monkey with hardware than it is to convince your software to start sending things in plain text…
Of course, I’m a bit paranoid, but only from experiences in a different sector of the security world - where these sorts of things happen quite frequently. The reality is that most financial firms will never face these sorts of threats, as the bad guys want money more than they want information, and there are easier ways for them to get the money
Wow, great discussion! You’ve added some great points! But remember: information == money in this age. 
Hi Ryan,
I think we’re both on the same page - I’m also happy to agree with any number of your points on this. I didn’t mean to denigrate anything you had said in an earlier post - my point is that you are taking a big risk when you rely on a firm that doesn’t specialize in security to provide you with a solution for a security problem.
Granted, this hinges on how critical this is for someone - if you just need to check the ‘secure’ box to make the lawyers happy and you don’t really care, then anybody’s product is going to fit the bill. However, if you’re really concerned about the potential for a compromise of some sort, that’s where the situation changes:
Most people don’t have the resources to perform in-house audits to determine the level of security provided by product X, Y, or Z. You have to take a vendor’s word on it, so the key thing here is that if you tell me your product supports SSL, but I can’t audit it and you can’t provide me with an exhaustive audit from a trusted third-party, then I’m really forced to choose between the known quantity of a product from a reputable security firm and a product from a guy who assures me everything is ok, but can’t really demonstrate it apart from waving his hands…
As computer geeks, you know, and I know, that it’s pretty easy to integrate support for OpenSSL into a product, and so on. But if we’re not giving the source code to our customer - and they can’t afford to audit our systems anyway, how do they know what’s going on?
If, on the other hand, you go to Cisco or one of the other big firms, you get a lot of assurance - you know that security is their core competency. You also know that the the government considers large hardware vendors, like Cisco, to be a part of our national security infrastructure, and as such, they get lots of help, consulting and advice (from outfits that have really short names) related to ensuring that their systems are as secure as they can be. This doesn’t make them infallible, but I’m a lot more comfortable knowing that a system has survived an NCSC audit, etc. than just hearing a general purpose programmer tell me that his software is secure.
Of course, like I said - a lot of this depends on the level of risk that you’re concerned about. If you are just worried that a script kiddie may intercept some traffic and post customer information on the internet that might embarass you - then any solution is probably going to be good enough to deal with that adversary. On the other hand, if you’re concerned that a skilled, dedicated adversary may try to sneak in and compromise your encryption technology (for whatever reason) it’s going to be more difficult for him to monkey with hardware than it is to convince your software to start sending things in plain text…
Of course, I’m a bit paranoid, but only from experiences in a different sector of the security world - where these sorts of things happen quite frequently. The reality is that most financial firms will never face these sorts of threats, as the bad guys want money more than they want information, and there are easier ways for them to get the money
Hi Russell,
I think we’re both on the same page - I’m also happy to agree with any number of your points on this. I didn’t mean to denigrate anything you had said in an earlier post - my point is that you are taking a big risk when you rely on a firm that doesn’t specialize in security to provide you with a solution for a security problem.
Ditto to most of the above. I’m likewise not meaning to denigrate anything you say, and I think that this kind of dialogue is particularly valuable in that it is bringing to light quite a lot of issues around FIX and security.
Granted, this hinges on how critical this is for someone - if you just need to check the ‘secure’ box to make the lawyers happy and you don’t really care, then anybody’s product is going to fit the bill.
Again, I agree strongly. Hardware and software encryption both add measurable latency to messaging, and, at least in the pre-trade and trade space, low latency is critical. As was mentioned in the FPL White Paper, many firms will say that a leased line is good enough and not bother with any of this.
Most people don’t have the resources to perform in-house audits to determine the level of security provided by product X, Y, or Z. You have to take a vendor’s word on it, so the key thing here is that if you tell me your product supports SSL, but I can’t audit it and you can’t provide me with an exhaustive audit from a trusted third-party, then I’m really forced to choose between the known quantity of a product from a reputable security firm and a product from a guy who assures me everything is ok, but can’t really demonstrate it apart from waving his hands…
Ability to audit security is an excellent point.
I’m willing to assume for this discussion that the encrypting router is audited and fully 100% secure. But a chain is only as secure as its weakest link. What happens between the FIX engine and the router?
This can be difficult to audit. As I’ve said, networks often use dynamic routing protocols to provide resiliency. I’ll admit that the bulk of my networking experience came from over a decade ago. But in that time I’ve seen my fair share of weird things, where well meaning network admins wanted data to take one path, and it really took another. Or multiple paths. Or asymmetric paths going there and coming back. Or network topology changed, and data suddenly found a new path. In these cases, the application sometimes still worked.
How do you go about auditing this? It takes a lot of technical knowledge. And, even if you use traceroute and a packet sniffer on each end of the connection, and make sure the path is right today, who says it will be right tomorrow when network topology and routing tables change? And what if the encrypted link goes down? Will any dynamic rerouting happen, sending the data over a non-secure link?
Contrast this with TLS and OpenSSL. FIX is an open standard. There is no guarantee that each side will use the same software. So my counterparty and I configure our FIX engines to accept a TLS session, limited to a particular certificate for ourselves and each other, and allow only certain secure cyphersuites. The act of successfully connecting is a form of audit. Either we both have it wrong, or we’re both probably using TLS properly. We can also try replacing both our own certificate, and our counterparty’s certificate, with the wrong one, and validate that the connection is refused. Interoperability with other TLS-enabled FIX engines is a very good sign.
Yes, none of this is perfect. There still are risks. In a perfect world, should security flaws be found with OpenSSL, my FIX engine provider would send me an urgent software update. Then again, even routers have security vulnerabilities, and network admins need to upgrade firmware from the vendors when they are discovered.
Thanks for this interesting discussion.
Ryan
Thank you to all of the great reply’s. Can you recommend a suitable network equipment for Simon’s idea at a solution level? Cisco, Juniper, etc… We will have design control of the solution and user agents.
Yes, the vendors you have mentioned provide the security services you are looking at. However, if hardware is not available, you can always make your own IPSec router. Just use a cheap Unix/Linux box with IPSec with 2 Ethernet interfaces. 1 interface for the User Agent, the other interface going out to the scary WWW.
Thank you to all of the great reply’s. Can you recommend a suitable network equipment for Simon’s idea at a solution level? Cisco, Juniper, etc… We will have design control of the solution and user agents.
The FPL White Paper on this topic:
http://www.fixprotocol.org/documents/3569/FIX%20Security%20White%20Paper-1.8-FINAL.pdf
discusses both IPSec and SSL/TLS. You might want to look into the latter, as well. I have heard a good deal of buzz around SSL/TLS in FIX circles. I see a number of commercial engine vendors offering support, and at least one open source engine integrating it as well.
But the best part is that native engine support for it isn’t even required; “stunnel” is an open-source proxy that can transparently sit in the middle of a FIX session and provide SSL/TLS encryption and authentication using X.509 certificates, either for FIX session intiators or acceptors.
I do want to caution that stunnel configuration must be done properly. The White Paper referenced above talks about some of the issues.