Imported from previous forum
[ original email was from wing tse - wingtse_hk@yahoo.com.hk ]
Is it possible to send FIX message through SSH tunnel across internet? Is there alternate way to send FIX message across internet?
Many thanks,
Wing
Hi Wing
Sending FIX messages over the internet is possible but generally not used for sensitive business traffic. Although PGP-DES-MD5 or SSL software encryption methods can be used to overcome this.
Alternatively a VPN could be used, thus helping to reduce the complexity and cost of managing connections and encrypted sessions.
Further information is available at
http://www.fixprotocol.org/implementation-guide/network.shtml.
Regards
Steve Hall
TransactTools Ltd
Is it possible to send FIX message through SSH tunnel across internet?
Is there alternate way to send FIX message across internet?Many thanks,
Wing
Sending FIX messages over the internet is possible but generally not
used for sensitive business traffic. Although PGP-DES-MD5 or SSL
software encryption methods can be used to overcome this.Alternatively a VPN could be used, thus helping to reduce the complexity
and cost of managing connections and encrypted sessions.
Virtual Private Network just says that you run a virtual network based on a physical one. The physical network can be also the internet.
Is it possible to send FIX message through SSH tunnel across
internet?
Is there alternate way to send FIX message across internet?
Actually, an SSH tunnel is poor mans VPN. A real VPN is much more comfortable if you want to connect several computer. Just for one link with fixed IP addresses and port numbers an SSH tunnel should be fine. The encryption methods used by VPN and SSH are virtually the same: You can use stronger and weaker methods depending on your requirements.
Have a look at http://www.stunnel.org as a simple alternative to SSH port forwarding.
In summary, my answer is: “Yes, you can use SSH to send FIX messages securely over the internet. The level of security depends on the level of security your SSH connection provides.”
Cheers, Jörg
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> 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.
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. […]
THANK YOU, Ryan, for this very thorough coverage of the subject. I did really enjoy reading it.
You should put this text somewhere on the FPL website.
Cheers, Jörg
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. […]
- 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.
I would like to add “Replay attacks” here. A possible intruder could try to replay the encrypted trade, thereby at least disturb the communication.
[…] 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.
Yes, this kind of problem is of the same kind as if somebody switches off the firewall by accident. An extra level of encryption in the application increases the security is such cases.
Cheers, Jörg
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I would like to add “Replay attacks” here. A possible intruder could try
to replay the encrypted trade, thereby at least disturb the
communication.
My understanding is that SSL and TLS have mechanisms in place to prevent replay attacks. Assuming a strong ciphersuite is used, and both parties authenticate each other, I think it would be computationally infeasible to replay a trade and have it accepted by either party.
Now disruption of communications is a general risk when using an untrusted network, or any network. But I’d categorize this more broadly as a denial of service attack. Strong crypto can provide reasonable assurances of authentication and message integrity, but it’s not going to stop someone who breaks into a telco closet with a pair of wire cutters.