curl and certificate verification in jessie

[Tollef Fog Heen]

]] Ian Jackson 

> 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.

Given we want those certificates to be usable by people using normal web
browsers too, this will lead to lots of popups about untrusted CAs,
unless we get our certificate provider to sign those CA certs for us.  I
don't think they're willing to do that.

> 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.

This is free software.  We can fix the software to DTRT if we need to.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are