It looks like nothing got done about this :-(.
Is there any (GPL-compatible) TLS HTTP client library or tool in
jessie which allows me to specify explicitly the expected End Entity
certificate ?
At the moment I'm using curl and wget. I was using --cacert=blah
--capath=/dev/null and it did DTRT
On Thu, 4 Dec 2014, Ian Jackson wrote:
Each time you generate an EE key which you intend to use this way,
[…]
This assumes you can control the server key/cert you want to trust.
Daniel Kahn Gillmor writes (Re: curl and certificate verification in
jessie):
So, the idea is that when you
Tollef Fog Heen writes (Re: curl and certificate verification in jessie):
]] Daniel Kahn Gillmor
Unfortunately, this is quite a subtle API change, and it's not clear how
to do it safely or sanely.
For curl, it sounds like a simple curl_set_option(CURL_SSL_EE_CERT,…)
call or similar would
* Ian Jackson ijack...@chiark.greenend.org.uk, 2014-12-05, 14:28:
But what about all the other callers of curl ? I'm thinking
particularly of LWP::UserAgent et al.
LWP::UserAgent doesn't use curl; it uses OpenSSL via IO::Socket:SSL.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to
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
]] 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
Tollef Fog Heen writes (Re: curl and certificate verification in jessie):
Ian Jackson:
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
On 12/04/2014 10:41 AM, Ian Jackson wrote:
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.
FWIW,
Daniel Kahn Gillmor writes (Re: curl and certificate verification in jessie):
So, the idea is that when you accept an EE cert, you need to do it
with an explicit associate to a specific peer's name, not just the cert
itself. newer versions of GnuTLS provide this facility, but it's
On 12/04/2014 01:48 PM, Ian Jackson wrote:
Daniel Kahn Gillmor writes (Re: curl and certificate verification in
jessie):
So, the idea is that when you accept an EE cert, you need to do it
with an explicit associate to a specific peer's name, not just the cert
itself. newer versions
Daniel Kahn Gillmor writes (Re: curl and certificate verification in jessie):
It seems to narrowly solve the case in question, but possibly at the
risk of making the semantics of the API even more confusing than it
already is.
If they didn't want the API to be full of confusing
backward
Ian Jackson writes (Re: curl and certificate verification in jessie):
Daniel Kahn Gillmor writes (Re: curl and certificate verification in
jessie):
It seems to narrowly solve the case in question, but possibly at the
risk of making the semantics of the API even more confusing than
]] Daniel Kahn Gillmor
On 12/04/2014 10:41 AM, Ian Jackson wrote:
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
On lun, dic 01, 2014 at 11:18:19 +0100, Tollef Fog Heen wrote:
Is this intentional, or is that a bug in either gnutls, curl, or the
software
using these libraries?
AFAICT this is due to the gnutls26 - gnutls28 switch. Using libgnutls-dev
to
build curl instead of libgnutls28-dev
On 12/01/2014 01:50 PM, Alessandro Ghedini wrote:
On lun, dic 01, 2014 at 11:18:19 +0100, Tollef Fog Heen wrote:
Is this intentional, or is that a bug in either gnutls, curl, or the
software
using these libraries?
AFAICT this is due to the gnutls26 - gnutls28 switch. Using libgnutls-dev
On Mon, 1 Dec 2014, Alessandro Ghedini wrote:
On lun, dic 01, 2014 at 11:18:19 +0100, Tollef Fog Heen wrote:
Is this intentional, or is that a bug in either gnutls, curl, or the software
using these libraries?
AFAICT this is due to the gnutls26 - gnutls28 switch. Using libgnutls-dev to
]] Alessandro Ghedini
On lun, dic 01, 2014 at 11:18:19 +0100, Tollef Fog Heen wrote:
Is this intentional, or is that a bug in either gnutls, curl, or the
software
using these libraries?
AFAICT this is due to the gnutls26 - gnutls28 switch. Using
libgnutls-dev to
build
Hi,
I recently started to move parts of debian.org's infrastructure to jessie. I
noticed a regression with software using curl to do https with certificate
verification.
On wheezy, this works:
| weasel@mipsel-manda-01:~$ cat /etc/apt/apt.conf.d/puppet-https-buildd
|
[ not sure what's the point of CCing debian-devel, but I kept it. I removed Ian
from the chain though, since he hasn't been much involved with curl lately ]
On sab, nov 29, 2014 at 01:10:20 +0100, Peter Palfrader wrote:
Hi,
I recently started to move parts of debian.org's infrastructure to
19 matches
Mail list logo
