Struct rustls::quic::ServerConnection
source · pub struct ServerConnection { /* private fields */ }
Expand description
A QUIC server connection.
Implementations§
source§impl ServerConnection
impl ServerConnection
sourcepub fn new(
config: Arc<ServerConfig>,
quic_version: Version,
params: Vec<u8>
) -> Result<Self, Error>
pub fn new( config: Arc<ServerConfig>, quic_version: Version, params: Vec<u8> ) -> Result<Self, Error>
Make a new QUIC ServerConnection.
This differs from ServerConnection::new()
in that it takes an extra params
argument,
which contains the TLS-encoded transport parameters to send.
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 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.
Methods from Deref<Target = ConnectionCommon<ServerConnectionData>>§
sourcepub fn quic_transport_parameters(&self) -> Option<&[u8]>
pub fn quic_transport_parameters(&self) -> Option<&[u8]>
Return the TLS-encoded transport parameters for the session’s peer.
While the transport parameters are technically available prior to the completion of the handshake, they cannot be fully trusted until the handshake completes, and reliance on them should be minimized. However, any tampering with the parameters will cause the handshake to fail.
sourcepub fn zero_rtt_keys(&self) -> Option<DirectionalKeys>
pub fn zero_rtt_keys(&self) -> Option<DirectionalKeys>
Compute the keys for encrypting/decrypting 0-RTT packets, if available
sourcepub fn read_hs(&mut self, plaintext: &[u8]) -> Result<(), Error>
pub fn read_hs(&mut self, plaintext: &[u8]) -> Result<(), Error>
Consume unencrypted TLS handshake data.
Handshake data obtained from separate encryption levels should be supplied in separate calls.
sourcepub fn write_hs(&mut self, buf: &mut Vec<u8>) -> Option<KeyChange>
pub fn write_hs(&mut self, buf: &mut Vec<u8>) -> Option<KeyChange>
Emit unencrypted TLS handshake data.
When this returns Some(_)
, the new keys must be used for future handshake data.
sourcepub fn alert(&self) -> Option<AlertDescription>
pub fn alert(&self) -> Option<AlertDescription>
Emit the TLS description code of a fatal alert, if one has arisen.
Check after read_hs
returns Err(_)
.
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<'_>]>
pub fn peer_certificates(&self) -> Option<&[CertificateDer<'_>]>
Retrieves the certificate chain 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.
This is made available for both full and resumed handshakes.
For clients, this is the certificate chain of the server.
For servers, this is the certificate chain of the client, if client authentication was completed.
The return value is None until this value is available.
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 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 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 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.
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.