Re: [Swan-dev] Libreswan signing key (907E790F25C1E8E561CD73B585FF4B43B30FC6F9)
I actually worked on that for an hour two days ago and failed to get rid of all the sha1’s. So we postponed this and will generate a new key Sent using a virtual keyboard on a phone > On May 25, 2022, at 18:49, Daniel Kahn Gillmor wrote: > > Hi folks-- > > I just noticed that the self-sigs over the libreswan signing key and its > subkey binding signature are all made using SHA1. > > As SHA1 is further deprecated, this makes the certificate difficult to > use, since the self-sig is what asserts signing capabilities from the > primary key -- if the self-sig is considerd invalid because of, say, an > implementation declining to accept SHA-1 digests, then the primary key > isn't considered signing-capable, which means that signatures made by it > won't be considered valid. > > the digest used in the subkey-binding signature is relevant if you want > to be able to receive encrypted mail (e.g. security bug reports). > > To fix this, just re-issue the self-sigs and subkey binding signatures > with a stronger digest (at least SHA2-256). > > If you're using a modern version of GnuPG that has access to the secret > key, the arcane command to do that is probably something like: > > gpg --cert-digest-algo sha256 --quick-set-expire > 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 0 > gpg --cert-digest-algo sha256 --quick-set-expire > 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 0 '*' > > and then re-export and re-publish the OpenPGP certificate wherever it's > published (at least in LIBRESWAN-GPG-KEY.txt in the git repo). > > The first line updates the expiration date and re-issues the self-sig > for the primary key, the second handles the subkey binding signature. > > Note that leaving the expiration date unset (the "0" above) might itself > be problematic if you ever lose control over the key and you don't have > any revocation certificate handy, but that's a separate question. i'd > recommend setting an expiration date of "2y" (instead of "0" above), and > then just repeat this process every time you have a release. Since > releases come out in a less-than-2-year cadence, this should be fine. > > But i'd be happy for now with just a primary key with a non-SHA1 > self-sig. > > Thanks for maintaining libreswan! > > --dkg > > PS here's the diagnosis: > > The "sig:.*:2:" lines are SHA1 signatures here: > > 0 dkg@alice:~$ gpg --with-colons --check-sigs > 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 > tru::1:1652480124:1691085522:3:1:5 > pub:-:4096:1:85FF4B43B30FC6F9:1357089367:::-:::scESC::23::0: > fpr:907E790F25C1E8E561CD73B585FF4B43B30FC6F9: > uid:-1357089367::ED0B44951C7DD5295C3DDEF9C67942731B01068E::Libreswan > (Signing Key) ::0: > sig:!::1:85FF4B43B30FC6F9:1357089367Libreswan (Signing Key) > :13x:2: > sig:?::1:E71806A6B5CC27E1:1357192633:10x:8: > sig:!::1:C30040228501D2EC:1357583027:10x:2: > sig:!::1:467564B7505DA62B:1420472842:10x:2: > sig:!::1:62D3582FE0FD94D2:1418273023:10x:8: > sig:?::1:CCD2ED94D21739E9:1490035473:155310747310l::0EE5BE979282D80B9F7540F1CCD2ED94D21739E9:::10: > sub:-:4096:1:43CD400C70C28757:1357089367::e::23: > fpr:1CF137415217927923F01BB943CD400C70C28757: > sig:!::1:85FF4B43B30FC6F9:1357089367Libreswan (Signing Key) > :18x:2: > 0 dkg@alice:~$ > ___ > Swan-dev mailing list > Swan-dev@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev signature.asc Description: Binary data ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-dev] Libreswan signing key (907E790F25C1E8E561CD73B585FF4B43B30FC6F9)
Hi folks-- I just noticed that the self-sigs over the libreswan signing key and its subkey binding signature are all made using SHA1. As SHA1 is further deprecated, this makes the certificate difficult to use, since the self-sig is what asserts signing capabilities from the primary key -- if the self-sig is considerd invalid because of, say, an implementation declining to accept SHA-1 digests, then the primary key isn't considered signing-capable, which means that signatures made by it won't be considered valid. the digest used in the subkey-binding signature is relevant if you want to be able to receive encrypted mail (e.g. security bug reports). To fix this, just re-issue the self-sigs and subkey binding signatures with a stronger digest (at least SHA2-256). If you're using a modern version of GnuPG that has access to the secret key, the arcane command to do that is probably something like: gpg --cert-digest-algo sha256 --quick-set-expire 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 0 gpg --cert-digest-algo sha256 --quick-set-expire 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 0 '*' and then re-export and re-publish the OpenPGP certificate wherever it's published (at least in LIBRESWAN-GPG-KEY.txt in the git repo). The first line updates the expiration date and re-issues the self-sig for the primary key, the second handles the subkey binding signature. Note that leaving the expiration date unset (the "0" above) might itself be problematic if you ever lose control over the key and you don't have any revocation certificate handy, but that's a separate question. i'd recommend setting an expiration date of "2y" (instead of "0" above), and then just repeat this process every time you have a release. Since releases come out in a less-than-2-year cadence, this should be fine. But i'd be happy for now with just a primary key with a non-SHA1 self-sig. Thanks for maintaining libreswan! --dkg PS here's the diagnosis: The "sig:.*:2:" lines are SHA1 signatures here: 0 dkg@alice:~$ gpg --with-colons --check-sigs 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 tru::1:1652480124:1691085522:3:1:5 pub:-:4096:1:85FF4B43B30FC6F9:1357089367:::-:::scESC::23::0: fpr:907E790F25C1E8E561CD73B585FF4B43B30FC6F9: uid:-1357089367::ED0B44951C7DD5295C3DDEF9C67942731B01068E::Libreswan (Signing Key) ::0: sig:!::1:85FF4B43B30FC6F9:1357089367Libreswan (Signing Key) :13x:2: sig:?::1:E71806A6B5CC27E1:1357192633:10x:8: sig:!::1:C30040228501D2EC:1357583027:10x:2: sig:!::1:467564B7505DA62B:1420472842:10x:2: sig:!::1:62D3582FE0FD94D2:1418273023:10x:8: sig:?::1:CCD2ED94D21739E9:1490035473:155310747310l::0EE5BE979282D80B9F7540F1CCD2ED94D21739E9:::10: sub:-:4096:1:43CD400C70C28757:1357089367::e::23: fpr:1CF137415217927923F01BB943CD400C70C28757: sig:!::1:85FF4B43B30FC6F9:1357089367Libreswan (Signing Key) :18x:2: 0 dkg@alice:~$ signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-dev] [Swan-announce] libreswan-4.7 released, bufix release and EAPTLS support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The Libreswan Project has released libreswan 4.7 This release adds support for EAPTLS, FreeBSD/NetBSD fixes, and fixes an interop issue with Android 12. This latest version of libreswan can be downloaded from: https://download.libreswan.org/libreswan-4.7.tar.gz https://download.libreswan.org/libreswan-4.7.tar.gz.asc The full changelog is available at: https://download.libreswan.org/CHANGES Please report bugs either via one of the mailinglists or at our github bug tracker: https://lists.libreswan.org/ https://github.com/libreswan/libreswan/issues Binary packages for RHEL/CentOS can be found at: https://download.libreswan.org/binaries/ Binary packages for Fedora and Debian should be available in their respective repositories a few days after this release. See also https://libreswan.org/ v4.7 (May 24, 2022) * IKEv2: EAPTLS support [Timo Teräs / Andrew] * IKEv2: EAPONLY support [Andrew] * IKEv2: fix interop when IPCOMP+transport-mode [Andrew] * IKEv2: fix race between new IKE SA and liveness [Andrew] * IKEv2: fix interop with Android 12 + certificates [Andrew] * IKEv1: reject IKEv2 only authby=secret+rsasig [Andrew] * config: end keywords with no left/right prefix are applied to both ends * kernel: fix double delete of kernel policy when tearing down SA [Andrew] * kernel: fix deleting policy when an XFRMi FD ID; github/618 [Andrew] * kernel: general cleanups [Andrew] * _stackmanager / pluto: support Ubuntu 18.04 LTS kernels [Paul] * FreeBSD: libreswan builds out-of-the-box [Andrew] * BSD: Add IPv6 support (tested on NetBSD) * building: fix build on fedora rawhide [Paul] * internals: initiate IKEv2 CREATE_CHILD_SA exchange using IKE SA [Andrew] * internals: _updown.bsdkame renamed to _updown.bsd -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEEkH55DyXB6OVhzXO1hf9LQ7MPxvkFAmKNZU4THHRlYW1AbGli cmVzd2FuLm9yZwAKCRCF/0tDsw/G+R9+D/wJ5Uu+B52FRaNFg7eLVt5BaUUV41RZ Sn/SajvO2bp4/4z/uMvBdS9GM/kZQOQGy3wAb0vXKrPsFC8duOt11zcAZBZAIdtn 5H8xbsua1moYVkNV6iTUL5sE4KrxNHjU4H2TNbPfS6RkZmxg1baLHkEvtvDpWfYk JPDqLK53xykOug2OlyEfby07OCkqcLy0u8RdncHkcPzleiDZ4GKq5Xpm5OjrCplN 9roPz/rfNXmkCP6CCYAGJ0UFObhNx6evmlTISlp6FRCFqgiDAGh7QAu/FuB6jMVj BwKKR6mOHRifLQ4TqOZHhDCw093tvP2/ILzTUg8eVG1bwY1ZkQwjza0MxmdX0GRD lJJGbh6xWf5KzUt15aHChOJYVwSt6zQZfTZyEny1JgFdrAtkDqlw9AeA2P/jD+86 w/yb8um7AKGgpbqdbilyxLYwE1PHq4ZTB9u/K2p02/3atHP7nny2Brc9EtVcRi+B GH10ozz3XBR+k+vT5w/yBGItbj4uifyYuaq4SbMFtNx7KdqKnZ/61HKShW/6Io9C unwS0wB03iNSc8oVC2ND9jkwFdnLSghXP97SVUA8UuWoUmLYqLOTDGSWimL4h26F NrSabXUwO/6PA/yzpfMUaRkRmnDM/sflRbqcDxjwZDvQMFZjrpdGD+f8OKryL8/Y aifVQk9hA3hWTw== =WRxr -END PGP SIGNATURE- ___ Swan-announce mailing list swan-annou...@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-announce ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] Libreswan basic questions
On May 24, 2022, at 20:34, Balaji Thoguluva wrote: > > > Thanks Paul. > > Further question. > > Suppose I have a socket descriptor already created for a local interface > which can be used to send and receive IKE packets to an external IKE peer. > > Can pluto daemon be configured with the specific socket descriptor (per IPsec > connection configuration) that can be used by pluto to send and receive IKE > packets? That is currently not supported. I believe a few years ago someone wrote a socket activation systemd patch but it was not accepted. Paul ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
