For reSIProcate 1.10.0, we will support PFS on TLS connections, this requires a DH parameters file to be generated on each installation of the package. There is probably a similar requirement for other packages that have a TLS server and don't generate DH parameters at compile time.
My current solution involves adding the following to %post
if [ ! -e %{_sysconfdir}/repro/dh2048.pem ] ; then /usr/bin/openssl dhparam -outform PEM \ -out %{_sysconfdir}/repro/dh2048.pem 2048 chown root:repro %{_sysconfdir}/repro/dh2048.pem chmod 0640 %{_sysconfdir}/repro/dh2048.pem fi
and then adding this to %files
%config(missingok) %ghost %{_sysconfdir}/repro/dh2048.pem
The dh2048.pem file is created correctly during package installation but it is not removed when the package is removed with "rpm -e"
Is there a better way to do this or does it look OK?
"DP" == Daniel Pocock daniel@pocock.pro writes:
DP> For reSIProcate 1.10.0, we will support PFS on TLS connections, this DP> requires a DH parameters file to be generated on each installation DP> of the package.
I do not know what that program is or does, but if it's a daemon then it is better to do such things as part of the daemon invocation. There is a whole guideline on doing that at https://fedoraproject.org/wiki/Packaging:Initial_Service_Setup
On the other hand, if it's not a daemon it might be easier to create these things the first time the program is started, unless it's expected to be run by users in which case I guess the scriptlet is going to be your best bet.
- J<
On 09/17/2015 01:07 PM, Daniel Pocock wrote:
For reSIProcate 1.10.0, we will support PFS on TLS connections, this requires a DH parameters file to be generated on each installation of the package. There is probably a similar requirement for other packages that have a TLS server and don't generate DH parameters at compile time.
My current solution involves adding the following to %post
if [ ! -e %{_sysconfdir}/repro/dh2048.pem ] ; then /usr/bin/openssl dhparam -outform PEM \ -out %{_sysconfdir}/repro/dh2048.pem 2048 chown root:repro %{_sysconfdir}/repro/dh2048.pem chmod 0640 %{_sysconfdir}/repro/dh2048.pem fiand then adding this to %files
%config(missingok) %ghost %{_sysconfdir}/repro/dh2048.pemThe dh2048.pem file is created correctly during package installation but it is not removed when the package is removed with "rpm -e"
You'll need to %ghost the file to have it removed.
Is there a better way to do this or does it look OK?
Do look at the initital service setup stuff that Jason mentioned.
On 17/09/15 21:18, Jason L Tibbitts III wrote:
"DP" == Daniel Pocock daniel@pocock.pro writes:
DP> For reSIProcate 1.10.0, we will support PFS on TLS connections, this DP> requires a DH parameters file to be generated on each installation DP> of the package.
I do not know what that program is or does, but if it's a daemon then it is better to do such things as part of the daemon invocation. There is a whole guideline on doing that at https://fedoraproject.org/wiki/Packaging:Initial_Service_Setup
On the other hand, if it's not a daemon it might be easier to create these things the first time the program is started, unless it's expected to be run by users in which case I guess the scriptlet is going to be your best bet.
Thanks for the feedback
Creating the DH parameters is slow (it takes several seconds) so it is probably not something that can be done on every startup.
You can see what I mean by executing this command:
$ time openssl dhparam -outform PEM -out /tmp/dh2048.pem 2048
On 09/17/2015 09:07 PM, Daniel Pocock wrote:
For reSIProcate 1.10.0, we will support PFS on TLS connections, this requires a DH parameters file to be generated on each installation of the package.
Why is forward secrecy with ECDHE not good enough? For that, you won't need to generate DH parameters at all.
On 18/09/15 14:14, Florian Weimer wrote:
On 09/17/2015 09:07 PM, Daniel Pocock wrote:
For reSIProcate 1.10.0, we will support PFS on TLS connections, this requires a DH parameters file to be generated on each installation of the package.
Why is forward secrecy with ECDHE not good enough? For that, you won't need to generate DH parameters at all.
Both DH and ECDH are supported
If the DH parameters are not present, it will still work with ECDH alone.
To maximize compatibility in a world of federated SIP though, it is useful to have both.
Regards,
Daniel
On 09/18/2015 03:14 PM, Daniel Pocock wrote:
On 18/09/15 14:14, Florian Weimer wrote:
On 09/17/2015 09:07 PM, Daniel Pocock wrote:
For reSIProcate 1.10.0, we will support PFS on TLS connections, this requires a DH parameters file to be generated on each installation of the package.
Why is forward secrecy with ECDHE not good enough? For that, you won't need to generate DH parameters at all.
Both DH and ECDH are supported
If the DH parameters are not present, it will still work with ECDH alone.
That should be sufficient and is more secure because the ServerKeyExchange signature does not indicate if the hashed & signed data is for DH or ECDH. :-(
To maximize compatibility in a world of federated SIP though, it is useful to have both.
Are you sure? Finite-field DH used to be pretty widely disabled for performance reasons.
On 18/09/15 16:17, Florian Weimer wrote:
On 09/18/2015 03:14 PM, Daniel Pocock wrote:
On 18/09/15 14:14, Florian Weimer wrote:
On 09/17/2015 09:07 PM, Daniel Pocock wrote:
For reSIProcate 1.10.0, we will support PFS on TLS connections, this requires a DH parameters file to be generated on each installation of the package.
Why is forward secrecy with ECDHE not good enough? For that, you won't need to generate DH parameters at all.
Both DH and ECDH are supported
If the DH parameters are not present, it will still work with ECDH alone.
That should be sufficient and is more secure because the ServerKeyExchange signature does not indicate if the hashed & signed data is for DH or ECDH. :-(
To maximize compatibility in a world of federated SIP though, it is useful to have both.
Are you sure? Finite-field DH used to be pretty widely disabled for performance reasons.
Once you've encountered enough proprietary SIP devices, you get to the point where nothing surprises you any more.
reSIProcate is intended to be something of a reference implementation so it is also good to have these different permutations in there. People can remove DH by modifying the cipher list if they explicitly don't want it.
Testing with a few clients, I observed, they preferred ECDH and used it.
packaging@lists.fedoraproject.org
-
Daniel Pocock -
Florian Weimer -
Jason L Tibbitts III -
Orion Poplawski