SecureTransport - implement renegotiations

After a handshake was completed, TLS socket is in 'connectionEncrypted' state.
So on a read notification, in 'transmit', we call 'SSLRead' to read supposedly
encrypted application data or TLS internal messages. In case SSLRead finds either
ClientHello or HelloRequest from a server, it attempts in a rather sneaky manner
to renegotiate. And  as it happens here and there with SecureTransport, SSLRead
fails and the work is only half-done, since we have kSSLSessionOptionBreakOnServerAuth
and kSSLSessionOptionBreakOnCertRequested options set to 'true'. We end up with
completely unexpected errors like errSSLClientCertRequested or errSSLPeerAuthCompleted
(yes, this is so normal and totally expected for 'SSLRead' function to verify
certificates and WRITE messages, no need to document this at all!).

If SecureTransport is sneaky, so can be us:

- in a read callback SecureTransport is probing the type of record
  and we can notice a sudden session state change - it goes from
  kSSLConnected (which is set upon handshake completion) to
  kSSLHandshake (which means a (re)handshake is ongoing);
- if this is the case - we lie to SecureTransport about the amount
  of data available (0 bytes), set 'renegotiating' to 'true', return
  errSSLWouldBlock;
- in 'transmit', if SSLRead returns errSSLWouldBlock and 'renegotiating'
  was set, we call 'startHandshake' until isHandshakeComplete() == true
  or some error encountered.

[ChangeLog][QtNetwork][QSslSocket] Implement renegotiation for SecureTransport backend

Task-number: QTBUG-69420
Change-Id: Iaab1336aa3abf3f6ac94b358f3142d2738a18ee9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>

0 files changed, 0 insertions, 0 deletions