Hi all,
I'd like to gauge interest in adding DTLS support to ext/openssl before
writing a formal RFC.
Problem
PHP can speak TLS, but only as a stream wrapper where OpenSSL owns the
socket end to end. There are two gaps:
- No DTLS (RFC 6347, the UDP counterpart of TLS) at all.
- No way to run (D)TLS over a transport the application controls.
Several modern protocols are built on DTLS where the application must own
the packet flow: WebRTC data channels and DTLS-SRTP (RFC 5764), CoAP over
DTLS, SIP media keying, and any case where DTLS records are multiplexed
with other traffic on one UDP port. Today these are only reachable from
PHP through FFI to libssl or an external process. DTLS has been an open
request since 2018 (bug #76629) with no implementation so far.
Proposal (sketch)
A small, transport-agnostic DTLS endpoint class whose packet I/O goes
through memory BIOs, so the application moves datagrams in/out itself:
namespace Openssl;
final class Dtls {
public const int HANDSHAKE_ERROR = -1;
public const int HANDSHAKE_CONTINUE = 0;
public const int HANDSHAKE_FINISHED = 1;
public function __construct(bool $isServer = false,
?string $certificate = null, ?string $privateKey = null) {}
public function getFingerprint(?string $digestAlgo = null): string
{}
public function getPeerFingerprint(?string $digestAlgo = null):
?string {}
public function isHandshakeFinished(): bool {}
public function handshake(): int {} // HANDSHAKE_* constants
public function feed(string $datagram): int {}
public function pull(): ?string {}
public function write(string $data): int {}
public function read(): string|false {}
public function exportKeys(string $label, int $length):
string|false {}
}
The application drives the handshake by pumping datagrams between peers
(feed/pull), verifies the peer out of band via getPeerFingerprint(), then
exchanges data with write()/read(). exportKeys() exposes
SSL_export_keying_material (RFC 5705), which is what DTLS-SRTP needs.
Status
I've already written a working proof-of-concept against master, with
.phpt tests; the full ext/openssl suite is green. I'm sharing it only to
make the discussion concrete -- I'm very open to changing the shape (this
is the point of asking first), and I'll only open a PR/RFC properly if
there's interest. I can post the branch/PR link on request.
Questions
- Is DTLS something we want in core ext/openssl, or is this better left
to userland/FFI? - Is the object + memory-BIO design the right direction? Should the
constructor also accept OpenSSLCertificate/OpenSSLAsymmetricKey
objects in addition to PEM? - How should we treat the server-side HelloVerifyRequest cookie
exchange (DoS amplification mitigation) -- required for v1, or
acceptable as future scope with a documented caveat? - (Cc ext/openssl maintainers -- your view would be especially valuable.)
Thanks for any feedback.
Gianfrancesco Aurecchia