Difference between revisions of "VPP/HostStack/TLS"
Florin.coras (Talk | contribs) |
Florin.coras (Talk | contribs) (→TLS App) |
||
| Line 3: | Line 3: | ||
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: | 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: | ||
| − | [[File:TLS App | + | [[File:TLS App Architecture1.png|450px|center|TLS App Architecture]] |
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. | 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. | ||
| Line 15: | Line 15: | ||
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. | 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. | + | To initialize a listen session, an application must be configured with a server certificate, to be provided to clients, and a private key. |
== Configuration == | == Configuration == | ||
Revision as of 07:19, 7 March 2018
Contents
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.
Configuration
The TLS application registers with the session layer at VPP startup time. The following can be currently configured via the startup configuration file:
- ca-cert-path: The path to the CA certificate. By default /etc/ssl/certs/ca-certificates.crt is used
- use-test-cert-in-ca: Flag that indicates if the embedded TLS server certificate should be added to the the CA chain for testing.
Examples
References
[1] RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
[2] mbedtls library
