Re: Sending FIX messages across internet
Ryan Pierce / Townsend Analytics Ltd.
19 May 2005 1:28PM ET
> Is it possible to send FIX message through SSH tunnel across internet?
> Is there alternate way to send FIX message across internet?
The FIX Information Security Subcommittee has been discussing options surrounding this.
The general thought is that SSLv3 and TLS (version 1.0 is released, I think 1.1 is in progress) is the current best-of-breed to provide application-level encryption and authentication for FIX sessions. While SSH is similar, I personally feel that SSL/TLS is superior for a number of reasons.
SSL/TLS can be implemented from a wide variety of commercial and free libraries inside a FIX engine. The Poppy proxy, as mentioned elsewhere in this thread, does this, and it does CompID checking. However, if I were implementing this in an external proxy, I'd strongly consider the open source product "stunnel", which is fairly widely used and receives a lot of scrutiny. It is not FIX specific and does not do CompID checking, but if a firm uses a different TCP port per FIX connection, it can bind certificates to specific ports.
The question of whether one can trade FIX over the Internet is an interesting one. The underlying assumption is that the Internet is inherently less secure, and more subject to tampering and eavesdropping, than a leased line, frame relay, or ATM connection between counterparties.
SSL and TLS can be configured to use extremely strong crypto and authentication, so in these configurations I personally wouldn't worry about evesdroppers on the Internet breaking SSL/TLS, decrypting FIX traffic, spoofing FIX messages, etc.
That's not to say that FIX trading over the Internet is not without risks, such as:
* Compromise of the host systems. If a FIX engine is on a machine connected to the Internet, compromising the machine's operating system could be an easier attack than breaking SSL/TLS crypto.
* Traffic analysis. Even if someone can't decrypt the data, they still can log when it is sent. I.e. "At 10:30 Institution A sent data to Broker B. Broker B responded with a bunch of data at 10:32. At 10:35, Institution A then sent data to Broker C." It's not as valuable as plaintext, but it's still information given away.
* Reliability. The Internet doesn't have the reliability and bandwidth guarantees that a leased line, frame relay, ATM circuit, etc. have. With these, you pay for a specific amount of guaranteed bandwidth between counterparties. With the Internet, factors beyond anyone's control can influence available bandwidth. Then again, the Internet has a lot of bandwidth, and it is possible to have more bandwidth between counterparties via the Internet than via a more private connection which caps bandwidth at a contracted amount.
* Possibility of Denial of Service attack. If a system is exposed to the Internet, it could be subject to DoS attacks.
Use of the Internet is a tradeoff. I think SSL/TLS eliminate a lot of the concerns of sending unencrypted FIX traffic over the Internet, but it, or any crypto solution, cannot eliminate all of them. Still, the Internet has several advantages in its favor: price, lack of complexity in maintining numerous private connections, and time to turn up connections with new counterparties.
I've heard talk of VPN's mentioned in this thread. These have advantages and disadvantages.
A VPN is completely transparent to the application, so once the networking departments of two counterparties configure it (or a financial VPN provider installs it), everything between the counterparties is encrypted, and the people handling FIX support don't have to think about certificates, configuring SSL/TLS-enabled FIX engines or stunnel proxies.
This transparency is also, in my view, a potential weakness of VPNs. The application layer thinks everything is cleartext, and it has no proof whether crypto really is happening, so the application is putting total trust for security in the underlying network. If someone flips off encryption on the VPN routers, the people handling FIX support may not know. It's also possible that a routing mixup could cause traffic between counterparties to take another path that doesn't involve the VPN box, and as a result the traffic isn't protected in transit. With SSL/TLS enabled at an application or proxy level, there's no question whether a session is encrypted and authenticated.
