Struct rustls::server::ServerConnection
source · pub struct ServerConnection { /* private fields */ }
Expand description
This represents a single TLS server connection.
Send TLS-protected data to the peer using the io::Write
trait implementation.
Read data from the peer using the io::Read
trait implementation.
Implementations§
source§impl ServerConnection
impl ServerConnection
sourcepub fn new(config: Arc<ServerConfig>) -> Result<Self, Error>
pub fn new(config: Arc<ServerConfig>) -> Result<Self, Error>
Make a new ServerConnection. config
controls how
we behave in the TLS protocol.
sourcepub fn server_name(&self) -> Option<&str>
pub fn server_name(&self) -> Option<&str>
Retrieves the server name, if any, used to select the certificate and private key.
This returns None
until some time after the client’s server name indication
(SNI) extension value is processed during the handshake. It will never be
None
when the connection is ready to send or process application data,
unless the client does not support SNI.
This is useful for application protocols that need to enforce that the
server name matches an application layer protocol hostname. For
example, HTTP/1.1 servers commonly expect the Host:
header field of
every request on a connection to match the hostname in the SNI extension
when the client provides the SNI extension.
The server name is also used to match sessions during session resumption.
sourcepub fn received_resumption_data(&self) -> Option<&[u8]>
pub fn received_resumption_data(&self) -> Option<&[u8]>
Application-controlled portion of the resumption ticket supplied by the client, if any.
Recovered from the prior session’s set_resumption_data
. Integrity is guaranteed by rustls.
Returns Some
if and only if a valid resumption ticket has been received from the client.
sourcepub fn set_resumption_data(&mut self, data: &[u8])
pub fn set_resumption_data(&mut self, data: &[u8])
Set the resumption data to embed in future resumption tickets supplied to the client.
Defaults to the empty byte string. Must be less than 2^15 bytes to allow room for other
data. Should be called while is_handshaking
returns true to ensure all transmitted
resumption tickets are affected.
Integrity will be assured by rustls, but the data will be visible to the client. If secrecy from the client is desired, encrypt the data separately.
sourcepub fn reject_early_data(&mut self)
pub fn reject_early_data(&mut self)
Explicitly discard early data, notifying the client
Useful if invariants encoded in received_resumption_data()
cannot be respected.
Must be called while is_handshaking
is true.
sourcepub fn early_data(&mut self) -> Option<ReadEarlyData<'_>>
pub fn early_data(&mut self) -> Option<ReadEarlyData<'_>>
Returns an io::Read
implementer you can read bytes from that are
received from a client as TLS1.3 0RTT/“early” data, during the handshake.
This returns None
in many circumstances, such as :
- Early data is disabled if
ServerConfig::max_early_data_size
is zero (the default). - The session negotiated with the client is not TLS1.3.
- The client just doesn’t support early data.
- The connection doesn’t resume an existing session.
- The client hasn’t sent a full ClientHello yet.
sourcepub fn fips(&self) -> bool
pub fn fips(&self) -> bool
Return true if the connection was made with a ServerConfig
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.
sourcepub fn dangerous_extract_secrets(self) -> Result<ExtractedSecrets, Error>
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.
Methods from Deref<Target = ConnectionCommon<ServerConnectionData>>§
sourcepub fn process_new_packets(&mut self) -> Result<IoState, Error>
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.
sourcepub fn export_keying_material<T: AsMut<[u8]>>(
&self,
output: T,
label: &[u8],
context: Option<&[u8]>,
) -> Result<T, Error>
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.
sourcepub fn set_buffer_limit(&mut self, limit: Option<usize>)
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
.
sourcepub fn refresh_traffic_keys(&mut self) -> Result<(), Error>
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.
sourcepub fn complete_io<T>(&mut self, io: &mut T) -> Result<(usize, usize), Error>
pub fn complete_io<T>(&mut self, io: &mut T) -> Result<(usize, usize), Error>
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.
sourcepub fn read_tls(&mut self, rd: &mut dyn Read) -> Result<usize, 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 toprocess_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.
sourcepub fn write_tls(&mut self, wr: &mut dyn Write) -> Result<usize, Error>
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>§
sourcepub fn wants_write(&self) -> bool
pub fn wants_write(&self) -> bool
Returns true if the caller should call Connection::write_tls
as soon as possible.
sourcepub fn is_handshaking(&self) -> bool
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.
sourcepub fn peer_certificates(&self) -> Option<&[CertificateDer<'static>]>
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.
sourcepub fn alpn_protocol(&self) -> Option<&[u8]>
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).
sourcepub fn negotiated_cipher_suite(&self) -> Option<SupportedCipherSuite>
pub fn negotiated_cipher_suite(&self) -> Option<SupportedCipherSuite>
Retrieves the ciphersuite agreed with the peer.
This returns None until the ciphersuite is agreed.
sourcepub fn negotiated_key_exchange_group(
&self,
) -> Option<&'static dyn SupportedKxGroup>
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
.
sourcepub fn protocol_version(&self) -> Option<ProtocolVersion>
pub fn protocol_version(&self) -> Option<ProtocolVersion>
Retrieves the protocol version agreed with the peer.
This returns None
until the version is agreed.
sourcepub fn handshake_kind(&self) -> Option<HandshakeKind>
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.
sourcepub fn send_close_notify(&mut self)
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.
sourcepub fn wants_read(&self) -> bool
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.