Difference between revisions of "VPP/HostStack/TLS"
Florin.coras (Talk | contribs) (→TLS App) |
Florin.coras (Talk | contribs) |
||
| Line 10: | Line 10: | ||
* Client app requests a TLS connection to a remote session endpoint | * Client app requests a TLS connection to a remote session endpoint | ||
* The TLS app, acting as a transport, is notified of the connections request. A TLS context is allocated and then, acting as an application, the TLS app opens a TCP connection to the remote transport endpoint. | * The TLS app, acting as a transport, is notified of the connections request. A TLS context is allocated and then, acting as an application, the TLS app opens a TCP connection to the remote transport endpoint. | ||
| − | * Once the TCP connection is established and the TLS app is notified, the context is initialized as a TLS client and the handshake protocol is started. | + | * Once the TCP connection is established and the TLS app is notified, the mbedtls context is initialized as a TLS client and the handshake protocol is started. |
| − | * When the handshake is finished, the TLS app | + | * When the handshake is finished, the TLS app uses a configured CA cert to verify the server's certificate and notifies the client application. |
| − | + | ||
| + | At this point, if the connection is successful, the client app can start exchanging data with the remote peer. Data pushed into the TX fifo is read by the TLS app, written into mbedtls and once encrypted, pushed into the TCP connection's TX fifo. The converse is done on reception. | ||
| + | |||
| + | To initialize a listen session, an application must be configured with a server certificate, to be provided to clients, and a private key. | ||
== Example Configuration and Usage == | == Example Configuration and Usage == | ||
Revision as of 07:09, 7 March 2018
TLS App
TLS service is offered by the stack to other client applications via a custom builtin application. The TLS application implements a special transport type that allows it to behave as an application, from the underlying TCP transport perspective, but also as a transport, from the client application perspective. We refer to this shim layer as a TLS context. The app does not directly implement the TLS protocol, i.e., the record layer, handshaking protocols and the cryptographic computations and suites [1], instead it relies on the mbedtls library [2]. A high level view of the architecture can be seen lower:
Because encryption and decryption operations result in the increase and decrease of number of bytes, respectively, a single client session requires four fifos. That is, in each direction encrypted and unencrypted data is buffered in distinct fifos.
To establish a client session, the following steps are typically taken:
- Client app requests a TLS connection to a remote session endpoint
- The TLS app, acting as a transport, is notified of the connections request. A TLS context is allocated and then, acting as an application, the TLS app opens a TCP connection to the remote transport endpoint.
- Once the TCP connection is established and the TLS app is notified, the mbedtls context is initialized as a TLS client and the handshake protocol is started.
- When the handshake is finished, the TLS app uses a configured CA cert to verify the server's certificate and notifies the client application.
At this point, if the connection is successful, the client app can start exchanging data with the remote peer. Data pushed into the TX fifo is read by the TLS app, written into mbedtls and once encrypted, pushed into the TCP connection's TX fifo. The converse is done on reception.
To initialize a listen session, an application must be configured with a server certificate, to be provided to clients, and a private key.
Example Configuration and Usage
References
[1] RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
[2] mbedtls library
