This is designed for inserting security between a protocol that wishes to use TCP and the TCP provider itself. In our standard way we just view it as a providerProtocol for that potential userProtocol which in turn uses TCP as an agentProtocol.

Because the TLSProvider needs to be inserted between a TCPUser and the TCPProvider (which now becomes an agent for TLS, this cannot be done (without some tricks) for a TCPUser which does not expect it to happen: it must know to call the TLSProvider instead of the TCPProvider, and of course the TLSProvider will know to call the TCP protocol as its agent.

Typically the way TCP is called is through some kind of socket library on a machine, so the potential TCPuser which wants to instead be a TLSuser just calls a special version of this library, or calls special sockets from that library. In either case it goes ahead and reads and writes as before, only now those are directed toward the correct protocol.

Our next lecture will show this in detail for Java.

There is a very specific handshake for such a connection, and it is all conducted by the TLSProvider in just the same way from the point of view of the user as it would have happened for the TCPProvider. The following diagram gives an overview:

Once the connection has been made as just detailed both peers are in what TLS calls the Exchange state. The user writes data, it is encrypted by the TLSProvider using the secret key agreed upon when the connection was made, and that Provider then sends it to the TCPProvider. For data in the other direction the TLSProvider at that peer has been written to by its user, that data has been encrypted with the same secret key, and given to the peer TCPAgent, and is in turn accepted by the local TLSProvider from the local TCPAgent, decrypted, and output by the TLSProvider to the original user.