1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358
use alloc::vec::Vec;
use core::fmt::Debug;
use pki_types::{CertificateDer, ServerName, UnixTime};
use crate::enums::SignatureScheme;
use crate::error::{Error, InvalidMessage};
use crate::msgs::base::PayloadU16;
use crate::msgs::codec::{Codec, Reader};
use crate::msgs::handshake::DistinguishedName;
// Marker types. These are used to bind the fact some verification
// (certificate chain or handshake signature) has taken place into
// protocol states. We use this to have the compiler check that there
// are no 'goto fail'-style elisions of important checks before we
// reach the traffic stage.
//
// These types are public, but cannot be directly constructed. This
// means their origins can be precisely determined by looking
// for their `assertion` constructors.
/// Zero-sized marker type representing verification of a signature.
#[derive(Debug)]
pub struct HandshakeSignatureValid(());
impl HandshakeSignatureValid {
/// Make a `HandshakeSignatureValid`
pub fn assertion() -> Self {
Self(())
}
}
#[derive(Debug)]
pub(crate) struct FinishedMessageVerified(());
impl FinishedMessageVerified {
pub(crate) fn assertion() -> Self {
Self(())
}
}
/// Zero-sized marker type representing verification of a server cert chain.
#[allow(unreachable_pub)]
#[derive(Debug)]
pub struct ServerCertVerified(());
#[allow(unreachable_pub)]
impl ServerCertVerified {
/// Make a `ServerCertVerified`
pub fn assertion() -> Self {
Self(())
}
}
/// Zero-sized marker type representing verification of a client cert chain.
#[derive(Debug)]
pub struct ClientCertVerified(());
impl ClientCertVerified {
/// Make a `ClientCertVerified`
pub fn assertion() -> Self {
Self(())
}
}
/// Something that can verify a server certificate chain, and verify
/// signatures made by certificates.
#[allow(unreachable_pub)]
pub trait ServerCertVerifier: Debug + Send + Sync {
/// Verify the end-entity certificate `end_entity` is valid for the
/// hostname `dns_name` and chains to at least one trust anchor.
///
/// `intermediates` contains all certificates other than `end_entity` that
/// were sent as part of the server's [Certificate] message. It is in the
/// same order that the server sent them and may be empty.
///
/// Note that none of the certificates have been parsed yet, so it is the responsibility of
/// the implementor to handle invalid data. It is recommended that the implementor returns
/// [`Error::InvalidCertificate(CertificateError::BadEncoding)`] when these cases are encountered.
///
/// [Certificate]: https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2
fn verify_server_cert(
&self,
end_entity: &CertificateDer<'_>,
intermediates: &[CertificateDer<'_>],
server_name: &ServerName<'_>,
ocsp_response: &[u8],
now: UnixTime,
) -> Result<ServerCertVerified, Error>;
/// Verify a signature allegedly by the given server certificate.
///
/// `message` is not hashed, and needs hashing during the verification.
/// The signature and algorithm are within `dss`. `cert` contains the
/// public key to use.
///
/// `cert` has already been validated by [`ServerCertVerifier::verify_server_cert`].
///
/// If and only if the signature is valid, return `Ok(HandshakeSignatureValid)`.
/// Otherwise, return an error -- rustls will send an alert and abort the
/// connection.
///
/// This method is only called for TLS1.2 handshakes. Note that, in TLS1.2,
/// SignatureSchemes such as `SignatureScheme::ECDSA_NISTP256_SHA256` are not
/// in fact bound to the specific curve implied in their name.
fn verify_tls12_signature(
&self,
message: &[u8],
cert: &CertificateDer<'_>,
dss: &DigitallySignedStruct,
) -> Result<HandshakeSignatureValid, Error>;
/// Verify a signature allegedly by the given server certificate.
///
/// This method is only called for TLS1.3 handshakes.
///
/// This method is very similar to `verify_tls12_signature`: but note the
/// tighter ECDSA SignatureScheme semantics -- e.g. `SignatureScheme::ECDSA_NISTP256_SHA256`
/// must only validate signatures using public keys on the right curve --
/// rustls does not enforce this requirement for you.
///
/// `cert` has already been validated by [`ServerCertVerifier::verify_server_cert`].
///
/// If and only if the signature is valid, return `Ok(HandshakeSignatureValid)`.
/// Otherwise, return an error -- rustls will send an alert and abort the
/// connection.
fn verify_tls13_signature(
&self,
message: &[u8],
cert: &CertificateDer<'_>,
dss: &DigitallySignedStruct,
) -> Result<HandshakeSignatureValid, Error>;
/// Return the list of SignatureSchemes that this verifier will handle,
/// in `verify_tls12_signature` and `verify_tls13_signature` calls.
///
/// This should be in priority order, with the most preferred first.
fn supported_verify_schemes(&self) -> Vec<SignatureScheme>;
}
/// Something that can verify a client certificate chain
#[allow(unreachable_pub)]
pub trait ClientCertVerifier: Debug + Send + Sync {
/// Returns `true` to enable the server to request a client certificate and
/// `false` to skip requesting a client certificate. Defaults to `true`.
fn offer_client_auth(&self) -> bool {
true
}
/// Return `true` to require a client certificate and `false` to make
/// client authentication optional.
/// Defaults to `self.offer_client_auth()`.
fn client_auth_mandatory(&self) -> bool {
self.offer_client_auth()
}
/// Returns the [`DistinguishedName`] [subjects] that the server will hint to clients to
/// identify acceptable authentication trust anchors.
///
/// These hint values help the client pick a client certificate it believes the server will
/// accept. The hints must be DER-encoded X.500 distinguished names, per [RFC 5280 A.1]. They
/// are sent in the [`certificate_authorities`] extension of a [`CertificateRequest`] message
/// when [ClientCertVerifier::offer_client_auth] is true. When an empty list is sent the client
/// should always provide a client certificate if it has one.
///
/// Generally this list should contain the [`DistinguishedName`] of each root trust
/// anchor in the root cert store that the server is configured to use for authenticating
/// presented client certificates.
///
/// In some circumstances this list may be customized to include [`DistinguishedName`] entries
/// that do not correspond to a trust anchor in the server's root cert store. For example,
/// the server may be configured to trust a root CA that cross-signed an issuer certificate
/// that the client considers a trust anchor. From the server's perspective the cross-signed
/// certificate is an intermediate, and not present in the server's root cert store. The client
/// may have the cross-signed certificate configured as a trust anchor, and be unaware of the
/// root CA that cross-signed it. If the server's hints list only contained the subjects of the
/// server's root store the client would consider a client certificate issued by the cross-signed
/// issuer unacceptable, since its subject was not hinted. To avoid this circumstance the server
/// should customize the hints list to include the subject of the cross-signed issuer in addition
/// to the subjects from the root cert store.
///
/// [subjects]: https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.6
/// [RFC 5280 A.1]: https://www.rfc-editor.org/rfc/rfc5280#appendix-A.1
/// [`CertificateRequest`]: https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2
/// [`certificate_authorities`]: https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4
fn root_hint_subjects(&self) -> &[DistinguishedName];
/// Verify the end-entity certificate `end_entity` is valid, acceptable,
/// and chains to at least one of the trust anchors trusted by
/// this verifier.
///
/// `intermediates` contains the intermediate certificates the
/// client sent along with the end-entity certificate; it is in the same
/// order that the peer sent them and may be empty.
///
/// Note that none of the certificates have been parsed yet, so it is the responsibility of
/// the implementor to handle invalid data. It is recommended that the implementor returns
/// an [InvalidCertificate] error with the [BadEncoding] variant when these cases are encountered.
///
/// [InvalidCertificate]: Error#variant.InvalidCertificate
/// [BadEncoding]: crate::CertificateError#variant.BadEncoding
fn verify_client_cert(
&self,
end_entity: &CertificateDer<'_>,
intermediates: &[CertificateDer<'_>],
now: UnixTime,
) -> Result<ClientCertVerified, Error>;
/// Verify a signature allegedly by the given client certificate.
///
/// `message` is not hashed, and needs hashing during the verification.
/// The signature and algorithm are within `dss`. `cert` contains the
/// public key to use.
///
/// `cert` has already been validated by [`ClientCertVerifier::verify_client_cert`].
///
/// If and only if the signature is valid, return `Ok(HandshakeSignatureValid)`.
/// Otherwise, return an error -- rustls will send an alert and abort the
/// connection.
///
/// This method is only called for TLS1.2 handshakes. Note that, in TLS1.2,
/// SignatureSchemes such as `SignatureScheme::ECDSA_NISTP256_SHA256` are not
/// in fact bound to the specific curve implied in their name.
fn verify_tls12_signature(
&self,
message: &[u8],
cert: &CertificateDer<'_>,
dss: &DigitallySignedStruct,
) -> Result<HandshakeSignatureValid, Error>;
/// Verify a signature allegedly by the given client certificate.
///
/// This method is only called for TLS1.3 handshakes.
///
/// This method is very similar to `verify_tls12_signature`, but note the
/// tighter ECDSA SignatureScheme semantics in TLS 1.3. For example,
/// `SignatureScheme::ECDSA_NISTP256_SHA256`
/// must only validate signatures using public keys on the right curve --
/// rustls does not enforce this requirement for you.
fn verify_tls13_signature(
&self,
message: &[u8],
cert: &CertificateDer<'_>,
dss: &DigitallySignedStruct,
) -> Result<HandshakeSignatureValid, Error>;
/// Return the list of SignatureSchemes that this verifier will handle,
/// in `verify_tls12_signature` and `verify_tls13_signature` calls.
///
/// This should be in priority order, with the most preferred first.
fn supported_verify_schemes(&self) -> Vec<SignatureScheme>;
}
/// Turns off client authentication. In contrast to using
/// `WebPkiClientVerifier::builder(roots).allow_unauthenticated().build()`, the `NoClientAuth`
/// `ClientCertVerifier` will not offer client authentication at all, vs offering but not
/// requiring it.
#[derive(Debug)]
pub struct NoClientAuth;
impl ClientCertVerifier for NoClientAuth {
fn offer_client_auth(&self) -> bool {
false
}
fn root_hint_subjects(&self) -> &[DistinguishedName] {
unimplemented!();
}
fn verify_client_cert(
&self,
_end_entity: &CertificateDer<'_>,
_intermediates: &[CertificateDer<'_>],
_now: UnixTime,
) -> Result<ClientCertVerified, Error> {
unimplemented!();
}
fn verify_tls12_signature(
&self,
_message: &[u8],
_cert: &CertificateDer<'_>,
_dss: &DigitallySignedStruct,
) -> Result<HandshakeSignatureValid, Error> {
unimplemented!();
}
fn verify_tls13_signature(
&self,
_message: &[u8],
_cert: &CertificateDer<'_>,
_dss: &DigitallySignedStruct,
) -> Result<HandshakeSignatureValid, Error> {
unimplemented!();
}
fn supported_verify_schemes(&self) -> Vec<SignatureScheme> {
unimplemented!();
}
}
/// This type combines a [`SignatureScheme`] and a signature payload produced with that scheme.
#[derive(Debug, Clone)]
pub struct DigitallySignedStruct {
/// The [`SignatureScheme`] used to produce the signature.
pub scheme: SignatureScheme,
sig: PayloadU16,
}
impl DigitallySignedStruct {
pub(crate) fn new(scheme: SignatureScheme, sig: Vec<u8>) -> Self {
Self {
scheme,
sig: PayloadU16::new(sig),
}
}
/// Get the signature.
pub fn signature(&self) -> &[u8] {
&self.sig.0
}
}
impl Codec for DigitallySignedStruct {
fn encode(&self, bytes: &mut Vec<u8>) {
self.scheme.encode(bytes);
self.sig.encode(bytes);
}
fn read(r: &mut Reader) -> Result<Self, InvalidMessage> {
let scheme = SignatureScheme::read(r)?;
let sig = PayloadU16::read(r)?;
Ok(Self { scheme, sig })
}
}
#[test]
fn assertions_are_debug() {
use std::format;
assert_eq!(
format!("{:?}", ClientCertVerified::assertion()),
"ClientCertVerified(())"
);
assert_eq!(
format!("{:?}", HandshakeSignatureValid::assertion()),
"HandshakeSignatureValid(())"
);
assert_eq!(
format!("{:?}", FinishedMessageVerified::assertion()),
"FinishedMessageVerified(())"
);
assert_eq!(
format!("{:?}", ServerCertVerified::assertion()),
"ServerCertVerified(())"
);
}