GNOME Bugzilla – Bug 617383
Please support HKP over TLS (HKPS) and LDAP over TLS (LDAPS) using gnupg-curl
Last modified: 2018-08-03 19:18:44 UTC
HKPS and LDAPS are alternatives to HKP and LDAP which provide transport encryption when talking to key servers. HKPS is implemented in GnuPG since 1.4.10 by means of gnupg-curl. Seahorse does not support these protocols, yet. It would be nice for seahorse to support them, too, since it would allow for increased privacy (on the datas' way to and from the keyserver).
Note that doing this currently requires providing a list of trusted root CAs via the gpg keyserver options, like this: keyserver-options ca-cert-file=/home/wherever/cas.crt For debian and debian-derived systems, a good default choice for seahorse here would be /etc/ssl/certs/ca-certificates.crt
(In reply to comment #0) > since it would allow for > increased privacy (on the datas' way to and from the keyserver). You know public keys are public, right? All data sent to key servers is public.
Yes, this is true. However, TLS provides at least two different enhancements: 0) defeats traffic analysis -- anyone on the network path between you and the keyserver can no longer learn whose keys you are fetching or what query you are running. 1) defeats Man-in-the-Middle (MITM) attacks -- let's assume you have a trusted keyserver who you can rely on to forward you information about revocations, new certifications, etc. If you access that keyserver over a clear, unauthenticated channel, an active attacker can masquerade as the server, and filter out the pieces of data you might be interested in. There was a significant discussion about this on the GnuPG development list: http://thread.gmane.org/gmane.comp.encryption.gpg.devel/15028 Support in Seahorse would be welcome.
Daniel nicely summed up the same reasons I see for why it makes sense to support HKPS. I know several people who, while some of them do trust a given key server to not record their usage patterns, dislike the fact that you basically disclose your web of trust to any entity able to monitor your traffic whenever you refresh your keys from a key server using an unencrypted connection. I think these people will, for this reason, not use seahorse at all but use plain GPG or Enigmail which both support HKPS and LDAPS for a while now. Many seahorse users who are not that worried may still consider it a nice feature if they become aware of the underlying (possible) issues - which most are probably not at this time.
*** Bug 629981 has been marked as a duplicate of this bug. ***
From Bug 629981: bertagaz [reporter] 2010-09-18 11:37:15 CEST I wasn't able to add a hkps enabled keyserver in seahorse, which is usefull in term of privacy. There are some of them already available and the sks developers are talking about setting up a dedicated dns pool for hpks keyservers. Having seahorse able to push and pull from such a keyserver, and correctly verifying their x509 certificates, would help a lot to keep some privacy about what key(s) people are pushing or pulling.
It's four years later, and a lot has happened in the meantime which should suggest that this feature would be great to have.
Sounds good to me. Now someone needs to want it enough to contribute the feature.
*** Bug 736756 has been marked as a duplicate of this bug. ***
I'm not an expert but seems to me anyone of the most common public servers accept not encrypted conections so, in practice, all Seahorse's keyserver features are useless now, AFAIK :-/
Please forgot https://bugzilla.gnome.org/show_bug.cgi?id=617383#c10 I didn't realised I've doing my tests in a network with restricted out ports. Sorry for the noise :-(
Any change this will be implemented? HKPS key servers are becoming more and more popular.
It is insane that this has yet to be implemented. A secure connection to keyservers over TLS is imperative and should not be hard to implement using OpenSSL. This makes seahorse almost useless
> It is insane that this has yet to be implemented. A secure connection to keyservers over TLS is imperative and should not be hard to implement using OpenSSL. This makes seahorse almost useless I agree. But this is an open source project. Absence of a feature means not enough people care about it to contribute that feature. Do you need pointers on where to contribute the necessary code? A code change here would probably do the trick: pgp/seahorse-hkp-source.c line 93 in function get_http_server_uri().
Why not implement this through the GPGME_KEYLIST_MODE_EXTERN option: https://www.gnupg.org/documentation/manuals/gpgme/Key-Listing-Mode.html#Key-Listing-Mode instead of writing custom code to access key servers?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/seahorse/issues/47.