This project contains known security vulnerabilities. Find detailed information at the bottom.

Crate webrtc-dtls

Dependencies

(30 total, 23 outdated, 3 insecure)

CrateRequiredLatestStatus
 aes^0.6.00.9.3out of date
 aes-gcm^0.8.00.11.1out of date
 async-trait^0.1.520.1.92up to date
 bincode^1.3.33.0.0out of date
 block-modes^0.7.00.9.1out of date
 byteorder^1.4.31.5.0up to date
 ccm^0.3.00.6.1out of date
 der-parser^5.010.0.0out of date
 elliptic-curve^0.11.120.14.1out of date
 hmac^0.10.10.13.0out of date
 log^0.4.140.4.34up to date
 oid-registry^0.1.10.8.1out of date
 p256^0.100.14.0out of date
 rand^0.8.00.10.2out of date
 rand_core^0.6.30.10.1out of date
 rcgen^0.8.130.14.10out of date
 ring ⚠️^0.16.190.17.14insecure
 rustls ⚠️^0.19.00.23.45insecure
 serde^1.0.1301.0.229up to date
 serde_derive^1.0.1301.0.229up to date
 sha-1^0.9.10.10.1out of date
 sha2^0.9.10.11.0out of date
 signature^1.2.23.0.0out of date
 subtle^2.4.12.6.1up to date
 thiserror^1.0.302.0.20out of date
 tokio^1.15.01.53.1up to date
 webrtc-util^0.5.30.17.2out of date
 webpki ⚠️^0.21.40.22.4insecure
 x25519-dalek^2.0.0-pre.13.0.0out of date
 x509-parser^0.90.18.1out of date

Dev dependencies

(4 total, 2 outdated)

CrateRequiredLatestStatus
 chrono^0.4.190.4.45up to date
 clap^2.34.04.6.7out of date
 env_logger^0.9.00.11.11out of date
 tokio-test^0.4.20.4.5up to date

Security Vulnerabilities

webpki: webpki: CPU denial of service in certificate path building

RUSTSEC-2023-0052

When this crate is given a pathological certificate chain to validate, it will spend CPU time exponential with the number of candidate certificates at each step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

This was previously reported in https://github.com/briansmith/webpki/issues/69 and re-reported recently by Luke Malinowski.

webpki 0.22.1 included a partial fix and webpki 0.22.2 added further fixes.

rustls: `rustls::ConnectionCommon::complete_io` could fall into an infinite loop based on network input

RUSTSEC-2024-0336

If a close_notify alert is received during a handshake, complete_io does not terminate.

Callers which do not call complete_io are not affected.

rustls-tokio and rustls-ffi do not call complete_io and are not affected.

rustls::Stream and rustls::StreamOwned types use complete_io and are affected.

ring: Some AES functions may panic when overflow checking is enabled.

RUSTSEC-2025-0009

ring::aead::quic::HeaderProtectionKey::new_mask() may panic when overflow checking is enabled. In the QUIC protocol, an attacker can induce this panic by sending a specially-crafted packet. Even unintentionally it is likely to occur in 1 out of every 2**32 packets sent and/or received.

On 64-bit targets operations using ring::aead::{AES_128_GCM, AES_256_GCM} may panic when overflow checking is enabled, when encrypting/decrypting approximately 68,719,476,700 bytes (about 64 gigabytes) of data in a single chunk. Protocols like TLS and SSH are not affected by this because those protocols break large amounts of data into small chunks. Similarly, most applications will not attempt to encrypt/decrypt 64GB of data in one chunk.

Overflow checking is not enabled in release mode by default, but RUSTFLAGS="-C overflow-checks" or overflow-checks = true in the Cargo.toml profile can override this. Overflow checking is usually enabled by default in debug mode.