Using FIX over TLS, is there a need to sign FIX mesages?

Question

We have 2 servers communicating, server A (a server that I own), and server B (server on the internet that I trust). I get some info from server B, which are FIX messages (https://en.wikipedia.org/wiki/Financial_Information_eXchange).

Server B provided me initially with certificates to implement TLS between us. So now we have a TLS communication between server A and server B exchanging FIX messages.

Noting that TLS does not sign the payloads (in my case the embedded FIX message), do I need to sign the FIX messages before they are sent over TLS? When do I need to sign payloads? In my mind, TLS is secure, and no one can read the data as it is encrypted, so why would we need to sign the payloads?

Answer 1

There are two reasons to sign messages:

1. To prevent undetected tampering (provide integrity and authenticity) of messages. TLS takes care of this for you, but only from where it is initiated to where it is terminated; if all your traffic is through a single TLS tunnel that connects the FIX implementations directly - and you're not choosing a very weird cipher suite which omits integrity (no major TLS implementation supports such by default) - then you don't need to worry about this any further. However, many systems don't use a single TLS tunnel for full end-to-end connections, in which case signing can help verify that the message came from who it says and wasn't forged or tampered with before entering (or after leaving) the TLS tunnel.
2. To provide non-repudiation, the property that you always know who sent a message and they can't disavow it after the fact. TLS does NOT provide this; after the initial handshake, all TLS traffic is both encrypted and authenticated using a shared symmetric key known to both parties, so either one can undetectably forge messages when e.g. writing to a log of all traffic sent and received. If the messages are individually signed (and ideally also include some replay protection, such as nonces or timestamps or at least sequence numbers, and I know FIX has the last of those and might have the others) then an attacker can't forge or modify messages from another party and introduce them into a log, nor can an attacker credibly disclaim to have sent a message that another party logged, or claim that it was modified by the logging party.

Non-repudiation is not always important, and indeed sometimes it's undesirable (for example, in "off the record" messaging systems, you don't want somebody to be able to later conclusively prove you sent a message). It also often has a performance impact (making and verifying digital signatures using asymmetric cryptography is, like all strong asymmetric cryptography, much slower than symmetric encryption and MACs). However, if you are going to log all the traffic and want to preserve a record for any sort of reason (such as auditing, or dispute resolution, or failure recovery, or so on), then you should use be using signed messages. At least some of those are plausibly things you would want for FIX.

Another case where signed messages can sometimes help is if the signing happens in a different system than the TLS tunneling. For example, imagine a cluster where you have your FIX software running on one node, which is connected to a gateway node, and the gateway node is initiating and terminating the TLS connection to your FIX counterparty. If an attacker gains limited access to this cluster, then depending on the inter-node communication security, the attacker might be able to forge messages as coming from the FIX node, such that they'd be sent by the gateway. Requiring that the messages be signed (by a key that the FIX node has, but no other node does) reduces this risk; the attacker must compromise the FIX node itself, rather than the cluster in general, to have any hope of a successful attack. This kind of defense-in-depth is plausibly well worth it for a financial institution.

Obvious caveat: if your counterparty isn't actually verifying the signatures, or at least logging messages for the possibility of future verification, signing is just a waste of cycles and bits. Also, signing adds complexity, and any time you're doing that - especially with an inherently complicated and easy-to-screw-up system like cryptography - you introduce risks. For example, suppose your FIX messages are signed using a private key, and the public key is distributed as an X.509 certificate (the format used by TLS, among other protocols). If the certificate expires before it's replaced with one valid until a later date, your counterparty would stop trusting your signatures, likely leading to otherwise-valid messages being rejected and thus a loss of availability.

So, to answer your question "Using FIX over TLS, is there a need to sign FIX mesages?", you must consider your use case. Does your counterparty even support signed messages? Are you (or them) going to be verifying the signatures, or at least saving the signed messages for later verification? Do you need non-repudiation, and/or want the extra security of a message signing key that can be stored separately from the TLS private key? Are you ready for the implementation complexity and ongoing maintenance burden of adding an additional cryptosystem to your FIX deployment? If all of those are true, then yes, signing messages will add meaningful security even over TLS, and you should do it. If any of them are no, then it's plausibly not worth it, and almost certainly not needed.

Answer 2

If you are doing TLS properly (this means using the latest version, and verifying the certificates in the connection are the right ones) nobody can read or edit the data in transit. TLS provides these security features so you don't need to mess with the payload. That's the point.

Reasons to sign the payload anyway might be that one end doesn't know the connection is TLS (e.g. the TLS stops at a reverse proxy which is not the end server) or the same message has to be transmitted through multiple servers (since TLS only protects each connection separately, the server in the middle could edit the payload) or your boss says so because he doesn't know about TLS.

Answer 3

1. In FIX, signature is optional. It depends on specific business context. You decide, if it is needed or not. For instance, if some clients are not trusted, then signature will definitely make sense. When messages are signed, clients will not be able to say that they have not sent particular message, or that the message was modified.

2. If you don't trust the connection between the TLS termination point and the application, signature will make unauthorized message modifications impossible.

Further answers can be found here.

Answer 4

Signing adds a different aspect of security, which cannot be replaced by transport security alone.

As a real world example, a sealed envelope makes sure that no one has seen or replaced the message during its delivery transit. However, that does not prove that the message in the envelope was actually sent from a specific person or institution. For this purpose, the message itself would have to be signed by that person or a representative.