0

I have 2 endpoints that are exchanging data (FIX messages), and the originating endpoint is genrating the fix files are sending them on an ecrypted channel (TLS or Stunnel). In a security audit, it was recommended that the files are signed, and this is a bit confusing as the communication is in TLS mode, when reading on the TLS handshake it mentions that the exchanaged messages are signed.

So in a nutshell, my question is: in general when files are exchaned between 2 parties using an encrypted channel, aren't the files signed by default?

Improve this question
2
  • Encryption in general neither implies integrity nor signing. While TLS provides integrity in addition to encryption it does not provide signing.
    – Steffen Ullrich
    Commented Apr 11, 2023 at 14:28
  • OP, in addition to the questions linked above, crypto.stackexchange.com/questions/5455/… is also instructive.
    – mti2935
    Commented Apr 11, 2023 at 17:06

1 Answer 1

Reset to default
0

No, TLS does not sign files. TLS "does not now" what is being sent, is it a file or just a part of it. Files are defined on the application layer, where as TLS is a transport layer.

For the client, TLS makes sure that the client is communicating with the expected server and not with some other server or with a man in the middle. If the client wants to establish connection to example.com, TLS makes sure it will be connection really to this server and not to some attacker.com. Thus the client is sure that any data received from server come really from the expected server.

For the server, TLS does not provide any information about the client.

Signing files can make sense, if there are corresponding threats. For instance, if you see the risk that the attacker or malicious users can modify or spoof data sent between the TLS termination point and the server application. But signing may be insufficient in such case. Encryption would be required.

Ask your auditors, what threat model they considered when they suggested you file signing.

Improve this answer
15
  • TLS has an option for client authentication, also (often) called "mutual" or "two-way" auth, but it isn't much used on the public web. It is used in some environments where users can be trained and restricted, notably employees of US government. Perhaps relevant here, it is supported by stunnel. Like (more common) server auth, it asymmetrically auths identity but only symmetrically protects the data. PS: s/now/know/
    – dave_thompson_085
    Commented Apr 11, 2023 at 23:54
  • @dave_thompson_085: Also mutual authentication has nothing to do with files. As I said, TLS is a transport layer. It does not distinguish if the data being sent are a file or not a file. The most HTTP requests are not files, but TLS does not know anything about it. Since TLS sees everything just as a stream of bytes, it is impossible to speak about singing of files on the TLS level.
    – mentallurg
    Commented Apr 12, 2023 at 0:41
  • I agree TLS doesn't sign the data, which I said ('only symmetrically protects' = MAC), and I didn't mention files at all, but your flat statement "For the server, TLS does not provide any information about the client" is false. Often it doesn't, but it can, sometimes does, and could here.
    – dave_thompson_085
    Commented Apr 14, 2023 at 3:17
  • @dave_thompson_085: 1) "only symmetrically protects" - It is a very misleading. TLS is not symmetric. Client can initiate connection server cannot. Server is authenticated, client is not (the OP does not say it is mTLS). If you mean symmetric encryption, then precise wording like symmetric encryption would be helpful.
    – mentallurg
    Commented Apr 14, 2023 at 17:09
  • @dave_thompson_085: 2) "* flat statement ... is false*" - No. The OP is about TLS, not mTLS. In TLS, client is not authenticated. Thus server has no information about who/what the client is.
    – mentallurg
    Commented Apr 14, 2023 at 17:14

Not the answer you're looking for? Browse other questions tagged .