Does SSL connection provide integrity?

I'm new to cryptography and I'm trying to implement a secure chat application using OpenSSL.

I want to ensure that public messages (which will be shown to all users) cannot be altered during transmission.

Does the use of SSL connection guarantee that?

If not, would using digital signatures to sign every message so as to prove the identity of the sender be a proper solution?

Yes. An SSL connection provides confidentiality and integrity of the transmission: an adversary (someone who is neither of the two communicating parties) cannot find or check what data was transmitted, and cannot modify the transmitted data. The adversary cannot replay data either.

With respect to confidentiality, note that an adversary can observe which machine is connecting to which machine when, and how much data is exchanged. This means that although the adversary cannot know the content of the messages, they may be able to guess who is talking to who. Privacy requires additional precautions.

With respect to integrity, note that it relies on authenticity. Integrity guarantees that when Alice is talking to someone, nobody except Alice and that someone can modify the data that they're exchanging. But if Alice wanted to talk to Bob, it does her no good that she can have unmodified communication with an unidentified party: she needs to know that she's having unmodified communication with Bob. TLS is a client-server protocol and always guarantees the authenticity of the server. It can optionally guarantee the authenticity of the client.

Beware that TLS versions up to 1.2 have some unusual cipher suites with reduced security guarantees. While the default configuration of all major TLS libraries disable those cipher suites by default, you do need to be careful not to accidentally enable them. TLS 1.3 only has full-security cipher suites (noting that client authentication is still optional, since TLS is designed to support unknown clients connecting to known servers).

Finally, keep in mind that TLS can only provide security guarantees about the transmission. It's difficult for two random machines on the Internet to communicate directly, so chat typically transits via a central server. If you only rely on TLS between each client and the server, TLS secures a message while it's in transit between client 1 and the server, and when it's in transit between the server and client 2. But it's up to the server software to guarantee the security of the message in between — for example, that the message is routed to the correct recipient. There are more sophisticated protocols that can guarantee end-to-end security of messages, a popular one being Signal. Applications that use such protocols may still use TLS between hops. This can, for example, help privacy by hiding from eavesdropper the information of who is talking to who, or help against spending resources on routing fake messages that would otherwise only be dropped when they reach their intended recipient).

TLS (the proper name for what you're calling SSL) does provide end-to-end integrity guarantees; that is, the receiver can know that what they got is exactly what the sender sent.

However, it is a point-to-point protocol; any message (recorder) is from a specific sender and to a specific receiver.

One way to look at it is like it's a secure 'pipe'; one side can put something into the pipe, and the other side can take it out - no one else can look at what went into the pipe (other than that something went in), and no one else can modify what's in the pipe (without being detected). However, TLS makes no guarantees about what happens to the data before it went into the pipe, or what happens to it once it leaves the pipe.

You state that you have public messages; how does the message get to the multiple receivers? TLS just gives you point-to-point connections (pipes); how do you turn that into a broadcast system? Does the sender send the message to each receiver using independent TLS connections? Does the initial receiver forward the message to the other receivers? Does the sender place the message into a common area that can be read by the various receivers?

In the first case, TLS would provide end-to-end integrity (assuming that the sender can be trusted to send the exact same message - TLS does nothing to verify that).

In the second case (the message is forwarded), there is nothing preventing the initial receiver from modifying the message it forwards - if he can be trusted not to do that, it's safe. If he can't be trusted, some protection outside of TLS (such as a signature with the sender's public key) would be needed.

In the third case (message placed into a common area), TLS provides no protection - you would need something like a signature.

Yes, TLS can provide end-to-end encryption, integrity and authenticity of messages for transport - it's not called Transport Layer Security without a reason.

You need to establish trust both parties though: if you cannot identify the clients then the adversary can masquerade as one and will probably receive the message as well. Generally with PKIX you need to trust the server anyway (just like browsers do), but if you don't then an adversary can pose as a server and send messages to the clients; this won't harm confidentiality or integrity of the messages itself after session setup, but it is not what you want.

Client authentication is optional for TLS, something that is usually skipped for browser-server connections. For e.g. webshops this is not a problem: you login by using a password (which may not be very secure) but if you pay you authenticate to your bank. However, for a chat application you may wish to also authenticate the client using a client certificate. If such PKI is infeasible you can do it the same way as in the browser: first connect to a server and then authenticate the client using the connection, for which the server is already authenticated.

Also beware that if the end of the connection is not at the server or client that you basically have point-to-point encryption instead; you would need to trust the intermediate parties / unsecured connections as well.

Notes:

• It may be a good idea to look at e.g. the Signal protocol, which is more targeted towards the goal of chat apps;
• I'd strongly recommend TLS 1.3 if you go for TLS;
• Beware that few if any cryptographic protocols are protected against quantum computers, so if you want to keep secrets longer than 10 years you need to look deeper.

I'm new to cryptography too, but recently I'm working on an SSL project. Here are more details in the instruction about an SSL handshake process(TLS 1.2 and TLS 1.3)

What the SSL handshake process does is generate a symmetry-key by using asymmetric encryption.

Before the key exchange step, the client or server(or both) will check the other's identity, which is defined in tls_process_cert_verify(). And the server will send the client a signature of handshake buffer.

After the key exchange step, they get their master secret to generate the master key(the symmetry-key), which is used to protect application data.

So here is the CIA property:
confidentiality: Master key encrypts application data.
Integrity： Hash of handshake buffer
Authenticity: Certification verification and the signature of handshake buffer.

You can trace the function SSL_Handshake() to know all the things that happened during generating the master key.

When the handshake is done. TLS record layer use hmac to protect the session integrity.