[PHP-DEV] Re: [RFC idea] DTLS support in ext/openssl (Openssl\Dtls)

Hi,

On Wed, Jul 1, 2026 at 5:34 PM Gianfrancesco Aurecchia <
[email protected]> wrote:

> Hi Jakub,
>
> Quick follow-up:
>
> Small change of plan from my last message: instead of validating for DTLS
> 1.3 first, I used some free time these days to get a working 1.2 draft up.
> DTLS turned out to be a bit trickier than I'd imagined, but something
> sensible came out of it, and I'd really value your read on the direction
> before I invest in 1.3 (which needs OpenSSL 4.1, still unreleased). If
> you'd rather I sort out 1.3 first as I said, just tell me.
>
>
So the reason why I mentioned to check DTLS 1.3 is because DTLSv1_listen is
not currently supported there so it would be probably better to go
through SSL_accept (with SSL_OP_COOKIE_EXCHANGE)). So the same should be
used for DTLS 1.2 if possible.


> I already have something you can build and test (branch below). In the
> meantime let me walk you through the choices, and whenever you think it's
> the right moment I'll prepare the draft PR.
>
> Approach
>
> A single 'dtls://' wrapper (plus 'dtlsv1.2://'), as you suggested, no
> dedicated class. It lives in a self-contained 'xp_dtls.c': I don't touch
> 'xp_ssl.c'. I reuse the naming and conventions of 'xp_ssl.c' as much as
> possible (the 'GET_VER_OPT' macros, the 'sockop_*' handlers, the passphrase
> callback, the same struct with 'php_netstream_data_t' as the first member),
> so the file feels familiar to anyone who already knows 'xp_ssl' and the
> review is quicker. But isolated: everyone's TLS path stays at zero risk and
> the diff is small and reviewable.
>
> Another reason I didn't put it inside 'xp_ssl.c': that one belongs to the
> TCP context (byte stream), while DTLS lives over UDP (datagrams). It's a
> different transport context, so a dedicated file is its natural home.
>
>
I can see the reasoning for separating but there seems to be lots of
duplications so it might be good to have some xp_common.c with some shared
helpers and restructure it a bit. But this can be probably added later.
Makes sense to start with this and then we can see what could be shared.


> Architectural choices
>
> In short:
>
> - Stream-only, no new PHP functions: just constants, context options and
> metadata; everything goes through existing functions.
> - Server: one peer per accepted socket, to avoid 'SO_REUSEPORT' (I'll
> leave the multi-peer case to the offloading work, as you mentioned).
> - Floor at DTLS 1.2 (1.0 is deprecated, RFC 8996). I'll add DTLS 1.3
> before the PR (I still have to get my hands on it), but I'd rather have
> your feedback on the 1.2 setup first, so I don't invest in 1.3 on a base
> you might want different.
> - Session resumption: I plan to align with the RFC (
> https://wiki.php.net/rfc/tls_session_resumption_api) extending it to
> DTLS. Here too I'll dive in after your first feedback, like for 1.3, so I
> don't build on it before knowing whether the direction works for you.
>

It's not necessary but might be better to include it or at least research
to get an idea about the whole design.


>
- 'local_cert'/'local_pk' as PEM file paths, consistent with 'tls://'.
>
> The only point worth expanding on is the core change: to make
> 'enable_crypto' work over a 'udp://' (the way 'ext/openssl' overrides
> 'tcp://' for TLS) you need the 'STREAM_CRYPTO_METHOD_DTLS_*' constants in
> 'main/streams/php_stream_transport.h'. They're purely additive (no existing
> logic touched) and it's the only point outside 'ext/openssl'. I've already
> implemented it, but I'm not 100% sure it's the right approach: I'd lean
> toward deferring it and keeping the first round to the 'dtls://' scheme
> only (zero core), leaving the 'enable_crypto' over 'udp://' layer for
> later. But if you take a look and it convinces you, all the better to keep
> it in.
>
> The branch is here:
> https://github.com/GianfriAur/php-src/tree/feature/openssl-dtls-stream
> (branch 'feature/openssl-dtls-stream').
>
>
Please create a draft PR for this so we can discuss it there. It's much
easier than here.


> Where I'd like your input
>
> 1. The additive core touch for 'enable_crypto' over 'udp://': I've
> implemented it but I'm not 100% sure it's fine. I'd lean toward deferring
> it (first round 'dtls://' scheme only), but if you take a look and it
> convinces you, all the better to keep it in. What do you think?
>

I guess it would be good to support so it's consistent but it's not
necessary if it would be a pain to do.


> 2. Does the 1.2 approach look right to you? (I'll add DTLS 1.3 and OpenSSL
> 4.1 before the PR, I just wanted your OK on the direction before investing
> in it.)
>

I haven't had time for a deep look but from what I see, the main issue
might be usage DTLSv1_listen as I mentioned. I will try to check it out
more next week and will comment on the PR.


> 3. On certs/keys: do I stay on PEM paths like 'tls://', or is it worth
> going for objects right away?
>
>
Keep it consistent with tls to not over complicate it.


> No rush given the summer, and honestly I won't be as lucky with free time
> myself in the coming days either: I'll take my cue from your feedback
> before formalizing anything. Thanks again for offering to take a look.
>
>
I should be able to check in my short DTLS slot which I have every week
(except holiday) around Friday.

Kind regards,

Jakub