Support non-external ECC certificates #7323
Comments
dnsmichi
added
area/distributed
dnsmichi
changed the title
dnsmichi
added
the
needs-sponsoring
|
I ran into this when testing the Windows C# setup wizard with Icinga 2 running ECC certificates. I did not debug further, but once this draft becomes reality we need to ensure that our Windows Agent is fully functional with it as well.
|
|
Blocked by old el7 and Windows agents with OpenSSL 1.0.2 requiring #7369. |
|
@pdolinic I'd like to hear you opinion on this. Do we want this? And why (not)? |
|
Would it be nice to have? Yes. |
|
Since I was asked for my opinion,
I agree with both of you, but would support this in the end.
|
|
OK, you'd support it.. would you also enable this by default? |
|
There are two parts to that discussion:
Also there are multiple parts to this issue:
|
|
@Al2Klimov I am not a Dev but default ECC could have unwanted consequences for lots of older devices https://support.globalsign.com/ssl/ssl-certificates-life-cycle/ecc-compatibility and this is only the first thing that came to my mind, there will be more than this. Optional could also be a challenge, because it also depends on the weakest endpoints which means you might have to revert to default/RSA anyways. Could this cause problem for Masters and Satellites as well? Implementing a new Crypto-Stack is probably something that is very big, has to be planned and thought out well with all the edge-cases involved. Not something to rush through.
I don't think I can contribute more to this discussion with my half-knowledge (or maybe better half of half knowledge :D), this is pretty much the end of what I know. |
Al2Klimov
removed
the
needs feedback
Shall we wait for https://www.rfc-editor.org/rfc/rfc8410 then? |
|
I don't see how hardware support plays any role here. We're not talking about any checks that have to interact with spooky management interfaces of old hardware or something like that. We're talking about the use of certificates within Icinga itself. This means cluster connections (something we mostly control ourselves) and the HTTPS API (which has external users). So if at all, this is a question of software compatibility. And support for ECC definitely isn't something new. Your link states that OpenSSL supports it since 0.9.8 which was released in 2005. Probably not long until I can say that's older than some of your coworkers.
Nothing that would prevent starting with the first of the three steps I outlined in #7323 (comment). In case Icinga 2.13 can't handle certificates signed with ECDSA, we couldn't switch so an ECDSA in 2.15 if we wanted to. |
E.g. me. Seriously, all of my TLS and DNSSEC KSK certs are RSA x4096. Anyway, what do you think about
According to ChatGPT you can have multiple verification roots of different key types (of course), multiple server certs, but not multiple client certs, so we'd have to try ECC and fall back to RSA. |
For the recordApropos:
OP:
Yes and no. Quote from mentioned ticket:
I emphasise: at least one. E.g. DHE-RSA-AES256-GCM-SHA384. It indeed didn't work until v2.14 thanks to Btw. ECDHE-RSA-AES256-GCM-SHA384 seems to already work for me w/o the PR. (Not to mention their both 128-conterparts.) But this PR is unnecessary if your OpenSSL (not on RHEL 7 😅) and Icinga (since 2.13) provide TLS 1.3: In short, nobody actually needs ECC, the customer can sleep quietly and I can deref. the RT ticket. |
For the record IIExternal ECC PKIs already work: Now, if I fire up the Icingas, they recognise each other. With config acceptance enabled in the API feature they even sync config to each other. |
Al2Klimov
changed the title
Story
The default certificate signature algorithm uses RSA. Support for ECC has been asked for.
https://www.thesslstore.com/blog/explaining-ssl-handshake/#rsa-vs-diffie-hellmanecc-a-quick-history
This involves the following changes:
Older certificates with RSA must still work.
ref/IP/12111Tasks
Cipher Suites
The TLS handshake signing also enforces preferring specific cipher suites then.
ECDHE-ECDSA-AES256-GCM-SHA384for new masters with new CA, certificates, new satellites/agentsECDHE-RSA-AES256-GCM-SHA384preferred for old 2.10 client RSA key pairs, signed by newer masters with ECC.The new default preferred cipher with RSA key pairs in 2.11 will be
ECDHE-RSA-AES256-GCM-SHA384unless the clients don't support it.PoC Patch
Extracted from #5555.
Master (new CA, certs, ECC)
Working Clients
Debian Buster has ECC available by default. After signing the new certificates, a connect works with the new hardened cipher list.
v2.10.5
Non-Working Clients
RHEL7 based platforms do not load the ECC cipher suite by default. This results in
no shared ciphererrors when hardening the cipher lists.v2.10.5 offers the following cipher list, once the CSR is signed with elliptic curve signature algorithm:
In order to fix this, a new icinga2 binary release is required with backporting #7247 to all our supported client platforms.
PoC Tests
Certificates
Signing Request from 2.10 Client
Fails with the single cipher suite, that's expected.
The text was updated successfully, but these errors were encountered: