On 08/20/2018 02:35 PM, Binarus wrote:
However, since I was absolutely sure that nobody at my client's site had
changed their router's configuration, I have done further research. Among
others, I have studied my /etc/strongswan.d/charon.conf again and came across a
setting which looked highly suspicious to me:
signature_authentication_constraints = yes
Entering "signature_authentication_constraints" into Google immediately lead to
this article:
https://www.strongswan.org/blog/2015/03/30/strongswan-5.3.0-released.html
After having read the second section of that article, I turned off the setting
mentioned above (i.e. set it to no), and now it works as before.
So it seems that the issue didn't have anything to do with non-matching
proposals, but with that setting, which seems to have been introduced (or seems
to have been assigned another default value) with version 5.3.0. This explains
why my old configuration with the old version 5.2.1 worked, but the same
configuration with the new version 5.5.1 didn't.
The issue does have something to do with non-matching proposals. It
is just that for signature schemes prior to version 5.3 the signature
constraints were not enforced. In your configuration you have :
leftauth=rsa-4096-sha512
rightauth=rsa-4096-sha512
That means you expect the certificates at both ends to use use at
least 4096 RSA keys and sha512 for signature schemes. You had the
setting all the time but it wasn't being enforced prior to 5.3, but now
it is. Instead of fixing it by turning
signature_authentication_constraints
off, I would generate new certificates with that strength if you want it
that strong, or just lower your constraints in left/rightauth to match
your existing certs. see left/rightauth at [1].
Regards,
Jafar
[1] https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
While my urgent and immediate problem is solved now, I still have a hard time
actually understanding what that article section is talking about. I would be
grateful if somebody could explain the issue for people who are not full-time
professional cryptographers. Specifically, I have not fully understood the
following sentences yet:
"Key types and hash algorithms specified in rightauth are now also checked against
IKEv2 signature schemes. If such constraints are used for certificate chain validation in
existing configurations, in particular with peers that don't support RFC 7427, it may be
necessary to disable this feature with the charon.signature_authentication_constraints
setting, because the signature scheme used in classic IKEv2 public key authentication may
not be strong enough."
I believe I have configured the strongest rightauth and leftauth scheme the
router at the client's site supports, which probably is the strongest scheme
commonly used with RSA (at least, I haven't heard of SHA768 or SHA1024 yet, or
that SHA3 or RSA8192 are currently being supported by more than a few exotic
router / VPN devices). Furthermore, when initially configuring the VPN between
me and my client (about 2 years ago), I have newly created *all* certificates
involved from scratch, using RSA 4096 and SHA-512.
So what exactly does StrongSwan (charon) expect here (i.e. what would it
consider strong enough), and how do I configure it (in case I decide to
re-enable signature_authentication_constraints)? A simple explanation would be
very nice; otherwise, probably we (I assume that I am not the only person who
hasn't fully understood that section) will have to study RFC 7427, which we'd
like to avoid :-).
Thank you very much in advance,
Binarus
--Jafar
On 08/18/2018 10:26 AM, Binarus wrote:
Dear all,
I am getting the error message mentioned above when trying to connect to
a client's site. Of course, I have tried to research if there already
has been a similar problem, and have found exactly one appropriate thread:
https://lists.strongswan.org/pipermail/users/2018-March/012351.html
Unfortunately, my situation is different; in my case, something else
seems to cause the problem. Having said this:
- It happened after the upgrade from Debian jessie (Debian 8) to Debian
stretch (Debian 9), i.e. after the upgrade from StrongSwan 5.2.1 to
StrongSwan 5.5.1)
- I definitely have copied the whole configuration (including
certificates and so on) from the old system to the new one (AFTER having
installed the new StrongSwan version in the new system). I have double
checked multiple times (applying different methods) that nothing is missing.
- With the old system, I definitely could connect to the client's site
without any problem with exact that configuration.
If it matters, the VPN Gateway at the client's side is a Lancom router
(I don't know the exact type, but it is newer one, and I am absolutely
sure that they didn't any changes to it while I was upgrading my system,
and to stress it again, the old system / StrongSwan version could
connect to that device without problems).
This is my /etc/ipsec.conf (sensitive data has been changed, and lines
which are commented out have been left away):
config setup
conn %default
mobike=no
conn myclient
ikelifetime=10800s
keylife=3600s
rekeymargin=9m
keyingtries=1
type=tunnel
keyexchange=ikev2
mobike=no
ike=aes256-sha512-modp4096!
esp=aes256-sha512-modp4096!
left=xxxxxxxxxxxxxxxx.hopto.org
leftauth=rsa-4096-sha512
leftid="/CN=xxxxxxxxxxxxxxxx.hopto.org"
leftsubnet=192.168.20.0/24
leftfirewall=no
leftcert=mycompany-client.crt
right=yyyyyyyyyyyyyyyy.zapto.org
rightauth=rsa-4096-sha512
rightid="/CN=yyyyyyyyyyyyyyyy.zapto.org"
rightsubnet=192.168.0.0/24
auto=add
This is the error message (sensitive data changed in the same way as
with ipsec.conf):
root@charon:/etc# /etc/init.d/ipsec restart
[ ok ] Restarting ipsec (via systemctl): ipsec.service.
root@charon:/etc# ipsec up myclient
initiating IKE_SA myclient[3] to 79.192.42.125
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (714 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (713 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
received 1 cert requests for an unknown ca
sending cert request for "CN=ca.clientsite.local"
authentication of 'CN=xxxxxxxxxxxxxxxx.hopto.org' (myself) with RSA
signature successful
sending end entity cert "CN=xxxxxxxxxxxxxxxx.hopto.org"
establishing CHILD_SA myclient
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr
AUTH SA TSi TSr N(EAP_ONLY) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (2048 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (1984 bytes)
parsed IKE_AUTH response 1 [ IDr CERT AUTH TSi TSr N(INIT_CONTACT) SA ]
received end entity cert "CN=yyyyyyyyyyyyyyyy.zapto.org"
using certificate "CN=yyyyyyyyyyyyyyyy.zapto.org"
using trusted ca certificate "CN=ca.clientsite.local"
checking certificate status of "CN=yyyyyyyyyyyyyyyy.zapto.org"
certificate status is not available
reached self-signed root ca with a path length of 0
authentication of 'CN=yyyyyyyyyyyyyyyy.zapto.org' with RSA signature
successful
IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
selected peer config 'myclient' inacceptable: constraint checking failed
no alternative config found
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (96 bytes)
establishing connection 'myclient' failed
root@charon:/etc#
Does anybody have an idea?
Thank you very much in advance,
Binarus
