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>
8e1e275f8f