[Bug-wget] [FEATURE-REQUEST] Pinning SSL certificates / check SSL fingerprints
Because SSL CA's have failed many times (Comodo, DigiNotar, ...) I wish to have an option to pin a SSL certificate. The fingerprint may be optionally provided through a new option. __ powered by Secure-Mail.biz - anonymous and secure e-mail accounts.
[Bug-wget] [FEATURE-REQUEST] Pinning SSL certificates / check SSL fingerprints
Because SSL CA's have failed many times (Comodo, DigiNotar, ...) I wish to have an option to pin a SSL certificate. The fingerprint may be optionally provided through a new option. __ powered by Secure-Mail.biz - anonymous and secure e-mail accounts.
Re: [Bug-wget] [FEATURE-REQUEST] Pinning SSL certificates / check SSL fingerprints
On 06/07/12 01:01, pro...@secure-mail.biz wrote: > Because SSL CA's have failed many times (Comodo, DigiNotar, ...) I wish to > have an option to pin a SSL certificate. The fingerprint may be optionally > provided through a new option. Have you tried using --ca-certificate option?
Re: [Bug-wget] [FEATURE-REQUEST] Pinning SSL certificates / check SSL fingerprints
On 07/07/2012 12:50 PM, Ángel González wrote: > On 06/07/12 01:01, pro...@secure-mail.biz wrote: >> Because SSL CA's have failed many times (Comodo, DigiNotar, ...) I wish to >> have an option to pin a SSL certificate. The fingerprint may be optionally >> provided through a new option. > Have you tried using --ca-certificate option? I believe the OP wants to pin the certificate of the remote server (that is, the end entity certificate), whereas --ca-certificate pins the certificate of the issuing authority. --dkg signature.asc Description: OpenPGP digital signature
Re: [Bug-wget] [FEATURE-REQUEST] Pinning SSL certificates / check SSL fingerprints
wrote: > On 07/07/2012 12:50 PM, Ángel González wrote: > > On 06/07/12 01:01, pro...@secure-mail.biz wrote: > >> Because SSL CA's have failed many times (Comodo, DigiNotar, ...) > I wish to have an option to pin a SSL certificate. The fingerprint may be > optionally provided through a new option. > > Have you tried using --ca-certificate option? > > I believe the OP wants to pin the certificate of the remote server (that > > is, the end entity certificate), whereas --ca-certificate pins the > certificate of the issuing authority. Yes, that's what I actually wanted to say. Thanks for clarifying. Cheers, proper __ powered by Secure-Mail.biz - anonymous and secure e-mail accounts.
Re: [Bug-wget] [FEATURE-REQUEST] Pinning SSL certificates / check SSL fingerprints
On 07/07/12 21:25, Daniel Kahn Gillmor wrote: > On 07/07/2012 12:50 PM, Ángel González wrote: >> On 06/07/12 01:01, pro...@secure-mail.biz wrote: >>> Because SSL CA's have failed many times (Comodo, DigiNotar, ...) I wish to >>> have an option to pin a SSL certificate. The fingerprint may be optionally >>> provided through a new option. >> Have you tried using --ca-certificate option? > I believe the OP wants to pin the certificate of the remote server (that > is, the end entity certificate), whereas --ca-certificate pins the > certificate of the issuing authority. > > --dkg Yes, but I expected that if the server certificate was in the certificate bundle, it would be trusted, just as root certificates don't need to sign themselves to be trusted. They are trusted for being in the store. And not-present certificates to be failing validation. However, it seems to be checking the system certificates regardless of --ca-certificate pointing to the certificate used by the server or not. Moreover, pointing --ca-directory to an empty folder doesn't seem to make a difference, which looks plainly wrong.
Re: [Bug-wget] [FEATURE-REQUEST] Pinning SSL certificates / check SSL fingerprints
Hi, I have a tiny comment from a downstream packager standpoint: It would be nice if the capath would be configurable during configure time instead of hardcoding it to /etc/ssl/certs as it is now - we e.g. use /etc/opt/csw/ssl/certs and need to perl-pi in the unpacked sources. Not a real problem, but also not the most elegant solution. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896
Re: [Bug-wget] [FEATURE-REQUEST] Pinning SSL certificates / check SSL fingerprints
On 07/07/2012 02:20 PM, Dagobert Michelsen wrote: > I have a tiny comment from a downstream packager standpoint: It would be nice > if the > capath would be configurable during configure time instead of hardcoding it > to /etc/ssl/certs as it is now - we e.g. use /etc/opt/csw/ssl/certs and need > to perl-pi in the unpacked sources. Not a real problem, but also not the most > elegant solution. fwiw, I agree with this, and suspect that a patch wouldn't be hard to come up with (and would be fairly non-controversial). If you're building against GnuTLS, Look around line 88 of gnutls.c, because i don't think GnuTLS embeds a default location for a trusted root certificate store. If you're building against OpenSSL, i think you might want to change your OpenSSL configuration directly (at least on debian, libcrypto seems to hardcode a default path to /usr/lib/ssl/certs, which is a symlink to /etc/ssl/certs). hth, --dkg signature.asc Description: OpenPGP digital signature
Re: [Bug-wget] [FEATURE-REQUEST] Pinning SSL certificates / check SSL fingerprints
On Sat, Jul 07, 2012 at 01:25:49PM -0600, Daniel Kahn Gillmor wrote: > On 07/07/2012 12:50 PM, Ángel González wrote: > > On 06/07/12 01:01, pro...@secure-mail.biz wrote: > >> Because SSL CA's have failed many times (Comodo, DigiNotar, ...) I wish to > >> have an option to pin a SSL certificate. The fingerprint may be optionally > >> provided through a new option. > > Have you tried using --ca-certificate option? > > I believe the OP wants to pin the certificate of the remote server (that > is, the end entity certificate), whereas --ca-certificate pins the > certificate of the issuing authority. > Indeed? I thought the --ca-certificate just makes the certificate trustful, so declaring server certificate using --ca-certificate could be enought. Though there can be problem with HTTP redirects and of course some picky TLS libraries can insist on CA=true X.509 attribute. Also some TLS implementations checks the server hostname against certificate name. So if the TLS library cannot be cheated with --ca-certificate option, overriding root of trust in other way is good idea. I'm just little worried about the digest algorithm. One can claim the MD5 is too weak. There have been real successfull attacks exploiting MD5 collisions of signed object in X.509 certificate. The ability to specify different alogrithm is necessary. Also remember the HTTP redirect scenario where you need to verify two (or more) servers. It's necessary to be able to supply more pinning options. Maybe option pinning certificate to hostname would be the best choice. No hashes. Just supply the peer certificate content like with --ca-certificate. E.g. `--peer-certificate example.com:/tmp/example.cert'. -- Petr pgpsNRlttrc9I.pgp Description: PGP signature
