https streaming diffie hellman parameters generated for each new connection.

[lucdig]

I use telnet interface with https access and signed certificates.

setup channel output #http{access=https,dst=:5004/stream.ts}
...
control channel play

Every time I play the channel, Diffie Hellman (2048) parameters are generated.
control channel stop -> control channel play: new Diffie Hellman (2048) parameters are generated.

This is what I see in the log with verbosity 3:

[b27020d8] gnutls tls server debug: generating Diffie-Hellman 2048-bits parameters...
[b27020d8] gnutls tls server debug: ciphers parameters loaded
[b27020d8] main tls server debug: using tls server module "gnutls"

Sometimes is very fast, sometimes takes "a lot" of time.
My problem is that a lot of https clients have a timeout of 5 seconds for establishing the tcp connection.
If the vlc htts server takes more than 5 seconds to generate the DH parameters, the client can't see the channel.

So, my question is: is it possible to set the vlc https server to use pre-built DF-2048 parameters? without generating it at each play?

Any idea/comments are much appreciated

[Rémi Denis-Courmont]

No. And besides, VLC creates the parameters when it is started, and then reuses them for all clients. It does not generate them when a client connects.

[lucdig]

No. And besides, VLC creates the parameters when it is started, and then reuses them for all clients. It does not generate them when a client connects.

Thanks for the reply, anyway, it was too fast.
If you have time to follow the detailed steps below, you will see that what I wrote is right.
Your initial "No" is, actually, a "Yes".

So, again, my question is: is it possible to set the vlc https server to use pre-built DF-2048 parameters? without generating it at each play?

1 - Generate a signed certificate. If you don't have one, you can do like this: https://www.nginx.com/blog/using-free-s ... ith-nginx/

2 - prepare a video to be streamed, in my example is "black.mp4"

3 - Open a terminal (T1) and run:
# vlc -vvv -I telnet --telnet-password videolan --telnet-port 8888 --http-cert="/path/to/signed/certificate/fullchain.pem" --http-key="/path/to/private/key/privkey.pem"

4 - Open a second terminal (T2) and run
# telnet localhost 8888
# login with password ("videolan")

VLC media player 3.0.17.4 Vetinari
Password:
Welcome, Master
> new black broadcast enabled
new
> setup black input /path/to/black.mp4
setup
> setup black output #std{access=https,dst=:5005/black.ts}
setup
> setup black option sout-keep
setup
> setup black option no-sout-all
setup
> control black play
control
>

5 - On T1, you will see the lines:
[b27020b0] gnutls tls server debug: using GnuTLS version 3.6.7
[b27020b0] gnutls tls server debug: generating Diffie-Hellman 2048-bits parameters...
[b27020b0] gnutls tls server debug: ciphers parameters loaded
[b27020b0] main tls server debug: using tls server module "gnutls"
[b27017b0] main access out debug: net: listening to * port 5005

6 - On T2, stop the streaming:
> control black stop
control
>

7 - On T1, you will see the liines:
[b27017b0] main access out debug: removing module "http"
[b2726268] main http host debug: HTTP host removed

8 - On T2, play again:
> control black play
control
>

9 - On T1, you will see the lines:
[b2719468] gnutls tls server debug: using GnuTLS version 3.6.7
[b2719468] gnutls tls server debug: generating Diffie-Hellman 2048-bits parameters...
[b2719468] gnutls tls server debug: ciphers parameters loaded
[b2719468] main tls server debug: using tls server module "gnutls"
[b272b0e8] main access out debug: net: listening to * port 5005

[Rémi Denis-Courmont]

When I wrote "No", I actually meant "No".

[lucdig]

You said that "VLC creates the parameters when it is started, and then reuses them for all clients".
If this is true, the parameters should be created at Step 3.

I showed that parameters are generated at each "control black play", Steps 4 and 8.
It's not true that "VLC creates the parameters when it is started".

If created at Step 3, for me there would be no need to pre-build the parameters.

So, my new question is: would it be possible that VLC creates the DH parameters when it is started with valid http-cert and http-key?

[Rémi Denis-Courmont]

Sigh. It is not just "possible". There are no other ways. VLC creates the DH parameters at the same time it opens the certificate and private key and before it starts accepting connections.

If you use legacy VLM broadcasts, that occurs when you start the first stream, which would normally be when you start VLC with a VLM configuration file.

Obviously VLM cannot read into the future and figure out that you will be creating an HTTP stream in 5 seconds.

[lucdig]

I'm still convinced that, with a modification on the code, VLC would be able to create the parameters when it is started, and then reuses them for all clients.
Anyway, if you say that it is not just possible, it must be true.
Thanks anyway

[Rémi Denis-Courmont]

Well yes. You can create a dummy stream that will kick-start HTTPS no matter what. But the reality of the matter is that there would never be an issue if you used VLM the way it was designed to be used.

[lucdig]

Well yes. You can create a dummy stream that will kick-start HTTPS no matter what. But the reality of the matter is that there would never be an issue if you used VLM the way it was designed to be used.

I tested as you suggested, I added 1 dummy HTTPS stream at start with the option --vlm-conf vlm.conf.
DF parameters are generated at start.

Then I added, via the telnet interface, a new_channel, streaming on the same listening port, with a different output URL.
At "control new_channel play", VLC generates again the DF parameters.

I tested again adding, at start, a second dummy HTTPS stream in vlm.conf.
In the debug, I see that DF parameters are generated twice:

[b3902088] gnutls tls server debug: generating Diffie-Hellman 2048-bits parameters...
[b27017a0] gnutls tls server debug: generating Diffie-Hellman 2048-bits parameters...

If I understood correctly, this is not the behaviour that you expect, so maybe it is a bug.