Struct ClientConnection

pub struct ClientConnection { /* private fields */ }

Available on crate feature std only.

This represents a single TLS client connection.

Implementations

impl ClientConnection

pub fn new( config: Arc<ClientConfig>, name: ServerName<'static>, ) -> Result<Self, Error>

Make a new ClientConnection. config controls how we behave in the TLS protocol, name is the name of the server we want to talk to.

pub fn early_data(&mut self) -> Option<WriteEarlyData<'_>>

Returns an io::Write implementer you can write bytes to to send TLS1.3 early data (a.k.a. “0-RTT data”) to the server.

This returns None in many circumstances when the capability to send early data is not available, including but not limited to:

• The server hasn’t been talked to previously.
• The server does not support resumption.
• The server does not support early data.
• The resumption data for the server has expired.

The server specifies a maximum amount of early data. You can learn this limit through the returned object, and writes through it will process only this many bytes.

The server can choose not to accept any sent early data – in this case the data is lost but the connection continues. You can tell this happened using is_early_data_accepted.

pub fn is_early_data_accepted(&self) -> bool

Returns True if the server signalled it will process early data.

If you sent early data and this returns false at the end of the handshake then the server will not process the data. This is not an error, but you may wish to resend the data.

pub fn dangerous_extract_secrets(self) -> Result<ExtractedSecrets, Error>

Extract secrets, so they can be used when configuring kTLS, for example. Should be used with care as it exposes secret key material.

pub fn ech_status(&self) -> EchStatus

Return the connection’s Encrypted Client Hello (ECH) status.

pub fn fips(&self) -> bool

Return true if the connection was made with a ClientConfig that is FIPS compatible.

This is different from crate::crypto::CryptoProvider::fips(): it is concerned only with cryptography, whereas this also covers TLS-level configuration that NIST recommends, as well as ECH HPKE suites if applicable.

Methods from Deref<Target = ConnectionCommon<ClientConnectionData>>

pub fn process_new_packets(&mut self) -> Result<IoState, Error>

Processes any new packets read by a previous call to Connection::read_tls.

Errors from this function relate to TLS protocol errors, and are fatal to the connection. Future calls after an error will do no new work and will return the same error. After an error is received from process_new_packets, you should not call read_tls any more (it will fill up buffers to no purpose). However, you may call the other methods on the connection, including write, send_close_notify, and write_tls. Most likely you will want to call write_tls to send any alerts queued by the error and then close the underlying connection.

Success from this function comes with some sundry state data about the connection.

pub fn export_keying_material<T: AsMut<[u8]>>( &self, output: T, label: &[u8], context: Option<&[u8]>, ) -> Result<T, Error>

Derives key material from the agreed connection secrets.

This function fills in output with output.len() bytes of key material derived from the master session secret using label and context for diversification. Ownership of the buffer is taken by the function and returned via the Ok result to ensure no key material leaks if the function fails.

See RFC5705 for more details on what this does and is for.

For TLS1.3 connections, this function does not use the “early” exporter at any point.

This function fails if called prior to the handshake completing; check with CommonState::is_handshaking first.

This function fails if output.len() is zero.

pub fn set_buffer_limit(&mut self, limit: Option<usize>)

Sets a limit on the internal buffers used to buffer unsent plaintext (prior to completing the TLS handshake) and unsent TLS records. This limit acts only on application data written through Connection::writer.

By default the limit is 64KB. The limit can be set at any time, even if the current buffer use is higher.

None means no limit applies, and will mean that written data is buffered without bound – it is up to the application to appropriately schedule its plaintext and TLS writes to bound memory usage.

For illustration: Some(1) means a limit of one byte applies: Connection::writer will accept only one byte, encrypt it and add a TLS header. Once this is sent via Connection::write_tls, another byte may be sent.

Internal write-direction buffering

rustls has two buffers whose size are bounded by this setting:

Buffering of unsent plaintext data prior to handshake completion

Calls to Connection::writer before or during the handshake are buffered (up to the limit specified here). Once the handshake completes this data is encrypted and the resulting TLS records are added to the outgoing buffer.

Buffering of outgoing TLS records

This buffer is used to store TLS records that rustls needs to send to the peer. It is used in these two circumstances:

• by Connection::process_new_packets when a handshake or alert TLS record needs to be sent.
• by Connection::writer post-handshake: the plaintext is encrypted and the resulting TLS record is buffered.

This buffer is emptied by Connection::write_tls.

pub fn refresh_traffic_keys(&mut self) -> Result<(), Error>

Sends a TLS1.3 key_update message to refresh a connection’s keys.

This call refreshes our encryption keys. Once the peer receives the message, it refreshes its encryption and decryption keys and sends a response. Once we receive that response, we refresh our decryption keys to match. At the end of this process, keys in both directions have been refreshed.

Note that this process does not happen synchronously: this call just arranges that the key_update message will be included in the next write_tls output.

This fails with Error::HandshakeNotComplete if called before the initial handshake is complete, or if a version prior to TLS1.3 is negotiated.

Usage advice

Note that other implementations (including rustls) may enforce limits on the number of key_update messages allowed on a given connection to prevent denial of service. Therefore, this should be called sparingly.

rustls implicitly and automatically refreshes traffic keys when needed according to the selected cipher suite’s cryptographic constraints. There is therefore no need to call this manually to avoid cryptographic keys “wearing out”.

The main reason to call this manually is to roll keys when it is known a connection will be idle for a long period.

pub fn reader(&mut self) -> Reader<'_>

Returns an object that allows reading plaintext.

pub fn writer(&mut self) -> Writer<'_>

Returns an object that allows writing plaintext.

pub fn complete_io<T>(&mut self, io: &mut T) -> Result<(usize, usize), Error>

where Self: Sized, T: Read + Write,

This function uses io to complete any outstanding IO for this connection.

This is a convenience function which solely uses other parts of the public API.

What this means depends on the connection state:

• If the connection is_handshaking, then IO is performed until the handshake is complete.
• Otherwise, if wants_write is true, write_tls is invoked until it is all written.
• Otherwise, if wants_read is true, read_tls is invoked once.

The return value is the number of bytes read from and written to io, respectively.

This function will block if io blocks.

Errors from TLS record handling (i.e., from process_new_packets) are wrapped in an io::ErrorKind::InvalidData-kind error.

pub fn read_tls(&mut self, rd: &mut dyn Read) -> Result<usize, Error>

Read TLS content from rd into the internal buffer.

Due to the internal buffering, rd can supply TLS messages in arbitrary-sized chunks (like a socket or pipe might).

You should call process_new_packets() each time a call to this function succeeds in order to empty the incoming TLS data buffer.

This function returns Ok(0) when the underlying rd does so. This typically happens when a socket is cleanly closed, or a file is at EOF. Errors may result from the IO done through rd; additionally, errors of ErrorKind::Other are emitted to signal backpressure:

• In order to empty the incoming TLS data buffer, you should call process_new_packets() each time a call to this function succeeds.
• In order to empty the incoming plaintext data buffer, you should empty it through the reader() after the call to process_new_packets().

This function also returns Ok(0) once a close_notify alert has been successfully received. No additional data is ever read in this state.

pub fn write_tls(&mut self, wr: &mut dyn Write) -> Result<usize, Error>

Writes TLS messages to wr.

On success, this function returns Ok(n) where n is a number of bytes written to wr (after encoding and encryption).

After this function returns, the connection buffer may not yet be fully flushed. The CommonState::wants_write function can be used to check if the output buffer is empty.

Methods from Deref<Target = CommonState>

pub fn wants_write(&self) -> bool

Returns true if the caller should call Connection::write_tls as soon as possible.

pub fn is_handshaking(&self) -> bool

Returns true if the connection is currently performing the TLS handshake.

During this time plaintext written to the connection is buffered in memory. After Connection::process_new_packets() has been called, this might start to return false while the final handshake packets still need to be extracted from the connection’s buffers.

pub fn peer_certificates(&self) -> Option<&[CertificateDer<'static>]>

Retrieves the certificate chain or the raw public key used by the peer to authenticate.

The order of the certificate chain is as it appears in the TLS protocol: the first certificate relates to the peer, the second certifies the first, the third certifies the second, and so on.

When using raw public keys, the first and only element is the raw public key.

This is made available for both full and resumed handshakes.

For clients, this is the certificate chain or the raw public key of the server.

For servers, this is the certificate chain or the raw public key of the client, if client authentication was completed.

The return value is None until this value is available.

Note: the return type of the ‘certificate’, when using raw public keys is CertificateDer<'static> even though this should technically be a SubjectPublicKeyInfoDer<'static>. This choice simplifies the API and ensures backwards compatibility.

pub fn alpn_protocol(&self) -> Option<&[u8]>

Retrieves the protocol agreed with the peer via ALPN.

A return value of None after handshake completion means no protocol was agreed (because no protocols were offered or accepted by the peer).

pub fn negotiated_cipher_suite(&self) -> Option<SupportedCipherSuite>

Retrieves the ciphersuite agreed with the peer.

This returns None until the ciphersuite is agreed.

pub fn negotiated_key_exchange_group( &self, ) -> Option<&'static dyn SupportedKxGroup>

Retrieves the key exchange group agreed with the peer.

This function may return None depending on the state of the connection, the type of handshake, and the protocol version.

If CommonState::is_handshaking() is true this function will return None. Similarly, if the CommonState::handshake_kind() is HandshakeKind::Resumed and the CommonState::protocol_version() is TLS 1.2, then no key exchange will have occurred and this function will return None.

pub fn protocol_version(&self) -> Option<ProtocolVersion>

Retrieves the protocol version agreed with the peer.

This returns None until the version is agreed.

pub fn handshake_kind(&self) -> Option<HandshakeKind>

Which kind of handshake was performed.

This tells you whether the handshake was a resumption or not.

This will return None before it is known which sort of handshake occurred.

pub fn send_close_notify(&mut self)

Queues a close_notify warning alert to be sent in the next Connection::write_tls call. This informs the peer that the connection is being closed.

Does nothing if any close_notify or fatal alert was already sent.

pub fn wants_read(&self) -> bool

Returns true if the caller should call Connection::read_tls as soon as possible.

If there is pending plaintext data to read with Connection::reader, this returns false. If your application respects this mechanism, only one full TLS message will be buffered by rustls.

Trait Implementations

impl Debug for ClientConnection

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Deref for ClientConnection

type Target = ConnectionCommon<ClientConnectionData>

The resulting type after dereferencing.

fn deref(&self) -> &Self::Target

Dereferences the value.

impl DerefMut for ClientConnection

fn deref_mut(&mut self) -> &mut Self::Target

Mutably dereferences the value.

impl From<ClientConnection> for Connection

fn from(conn: ClientConnection) -> Self

Converts to this type from the input type.

Layout

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.

Size: 1024 bytes