0

The SSL/TLS protocol has four sub-protocols and message types:

  • Application
  • Handshake
  • Change cipher spec
  • Alerts

What does SSL_read() return (for a blocking socket) if the record received was NOT an Application message? And if it does return non-zero, how is the caller supposed to know what to do with it?

I don't see what the caller/client can do with the 3 non-Application messages, they seem more like internal state for SSL.

If it returns 0 bytes, this will be confusing for a blocking socket.

If it returns > 0 bytes, the caller would this an Application message has been received? (there is no flag returned to the caller to indicate the record type).

I am looking at the source code but it's not clear.

intrigued_66
  • 16,082
  • 51
  • 118
  • 189

1 Answers1

1

SSL_read will only return data retrieved from application records. Any other messages received will only change the internal state of the SSL session, like proceeding with the SSL handshake (if not previously finished), saving session tickets for later use or closing the connection (on shutdown alert).

If this internal change of the SSL session results in the session getting closed or invalid (like when getting an alert), then SSL_read will return with an error and the reason can be retrieved using SSL_get_error.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • Thanks for answering. Should `SSL_read()` only be called once the handshake is established? Prior to that, `::recv()` should be used? – intrigued_66 Feb 08 '23 at 10:27
  • @intrigued_66: You should only call recv directly on the TCP socket if you either don't deal with TLS (like plain traffic before TLS handshake) or if you want to handle TLS yourself (like using [BIO](https://stackoverflow.com/questions/51672133/what-are-openssl-bios-how-do-they-work-how-are-bios-used-in-openssl)). As for only calling SSL_read after the handshake see [the documentation](https://www.openssl.org/docs/manmaster/man3/SSL_read.html): *"If necessary, a read function will negotiate a TLS/SSL session, if not already explicitly performed by SSL_connect(3) or SSL_accept(3)."* – Steffen Ullrich Feb 08 '23 at 12:05