Firstly, I should say that I agree with Peter and Tollef's objectives.
I'm not an expert on TLS but I was under the impression that this
behaviour - requiring that TLS authentication be done by a nontrivial
certificate chain - was specified by the standards (presumably X.509
rather than TLS). I could be wrong.
Tollef Fog Heen writes ("Re: curl and certificate verification in jessie"):
> No, it doesn't necessarily. As dkg points out, I can no longer say
> «this service should have this particular cert». This makes us
> vulnerable to compromises of the CA that provides the cert for a given
> service and a lowering of the overall security in this particular setup.
There is a straightforward workaround for this.
Each time you generate an EE key which you intend to use this way,
also create an ad-hoc single-shot CA. Generate one EE certificate
using the CA, on the EE public key, and then throw the CA private key
away (or keep it alongside the EE private key). In clients, configure
the ad-hoc CA public key instead of the EE public key.
This has identical security and key management properties to trying to
configure the EE public key directly in clients. (Aside from the
security risks of the extra complication.) In a conversation about
the ftp-master data api service I provided some scripts which are
intended to do all this.
This is of course all very tedious and it would be nice to fix the TLS
libraries. But if (as I suspect) the desired configuration is
(absurdly) forbidden by the standards, we might have to use this
workaround.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21632.32933.499745.697...@chiark.greenend.org.uk
