HTTPS keyservers (with SSL-keys recording), WAS: help

Wed Mar 15 10:14:06 CET 2017

My reply is really to one issue of all, but the discussion is
noteworthy, and also it took place 2 1/2 weeks ago, so I leave the whole
email quoted.

On 170228-00:35+0100, Damien Goutte-Gattat wrote:
> Hi,
> 
> On 02/27/2017 04:07 PM, rsvx at riseup.net wrote:
> > I'll use my master key offline. Following this guidelines:
> > https://incenp.org/notes/2015/using-an-offline-gnupg-master-key.html
> >
> > I also implemented the Appelbaum's config.(Riseup Best Practices) Will
> > it work properly if the Master Key isn't on my machine?
> 
> It should.
> 
> Note, however, that Riseup's Best Practices [1] and proposed 
> configuration file [2] are partially obsolete, *especially* if you are 
> using GnuPG 2.1. Many of the proposed options and advices are not needed 
> anymore, as GnuPG already does The Right Thing.
> 
> 
> > And the following faults are coming:
> >  gpg: keyserver option 'ca-cert-file' is obsolete; please use
> > 'hkp-cacert' in dirmngr.conf
> 
> If you're using the sks-keyservers.net pool you no longer need to 
> provide GnuPG with the CA certificate file, as it is now bundled with 
> GnuPG (>= 2.1.11) and automatically used when needed. (And with GnuPG >= 
> 2.1.16 you will no longer even need to explicity set the keyserver 
> option, as hkps.pool.sks-keyservers.net is already the default.)
> 
> 
> > gpg: keyserver option 'no-try-dns-srv' is unknown
> 
> This option no longer exists, but I *think* that if you really want to, 
> you can disable SRV lookups by explicitly specifying a port number when 
> setting the keyserver, as in:
> 
>    keyserver hkps.pool.sks-keyservers.net:443

Nope! The port is 11371. I just tried apply your suggestion (because I'd
very much like two things, see below), and I added to my:

~/.gnupg/dirmngr.conf

the line:

keyserver hkps.pool.sks-keyservers.net:443

but this are the HTTP Requests full uri that I found in my traces:

125	http://pool.sks-keyservers.net:11371/pks/lookup?op=get&options=mr&search=0x3F533109A9509B14
153	http://pool.sks-keyservers.net:11371/pks/lookup?op=get&options=mr&search=0xCBB15A68EF3AC804875D5C4E153FE398821C8394
234	http://pool.sks-keyservers.net:11371/pks/lookup?op=get&options=mr&search=0xB34135EC5C5D05CF0FBCC8D583864DFC21ABA4A6
1046	http://pool.sks-keyservers.net:11371/pks/lookup?op=get&options=mr&search=0x19419825DE14BEA8
1076	http://pool.sks-keyservers.net:11371/pks/lookup?op=get&options=mr&search=0x9011A67E3A73CDF575FA841C7BCC5A972762EBA1
1110	http://pool.sks-keyservers.net:11371/pks/lookup?op=get&options=mr&search=0x8EB8BFEFAA18B872

-- those were just some keys from the public mailing lists, I think I
used Mutt ML this time --

( gotten with the unfinished, but mostly working, script of mine:
https://github.com/miroR/tshark-hosts-conv , the number in front is the
packet the request it appears in )

> --
> [1] https://riseup.net/en/security/message-security/openpgp/best-practices
> [2] 
> https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf
> 

And the two things that I would very much like to see (in not too
distant future), is,

1) of course, HKP in secure conversation client-server, not in
plaintext, over the internet

2) secure HKP decryptable for end user, at his configuration and
request. Pls. see this youtube-dl issue:

Write TLS session keys to $SSLKEYLOGFILE #11614
https://github.com/rg3/youtube-dl/issues/11614
(of course devs will find real read in the links therefrom, but I'm not
one, I give what I can follow)

and know that Wget program has implemented that decryptability for end
user (just like some big browsers do if you set up $SSLKEYLOGFILE...)

I record SSL-keys all the time, and I believe every communication
in/with my machine must be permitted by me, and open to my inspection,
else, it's getting very close to doing/allowing things to be done behind
my back... A very good example of things possibly being done, allowed to
be done behind my back is dbus, the core of all big Desktop
Environments, the best and sine qua non friend of SystemDestruction or
systemd...

Just look it up, and apparently, that's the normal communication setup
by dbus (see below about that too):

Re: How to avoid stealth installation of systemd?
http://forums.debian.net/viewtopic.php?f=20&t=116770&start=45#p552566

where find:

$ ps aux | grep ssh
root      2184  0.0  0.0  54976  1004 ?        Ss   Sep06   0:00 /usr/sbin/sshd
mr        2447  0.0  0.0  10592    32 ?        Ss   Sep06   0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
mr       15141  0.0  0.0  19980  1796 pts/9    S+   21:48   0:00 grep ssh
$

I really hope GnuPG will go the SSL way for getting the keys, and the
decryptable-for-user way, to get it all open, at user's
request/configuration (not by default! nobody does it by default any
more, can be hijacked from non-advanced users).

I learned that recently from people at secure-os that this way is how
dbus regularly works! Quoting: 

> Both ssh-agent and dbus must be wrapped around X11 in order to do
> their job, and that is just what that process is doing. It is allowing
> you to have a functional dbus and convenient ssh key storage while
> using your desktop. You can do without these conveniences, but maybe
> not with debian... so what you saw here is regular behavior, unlikely
> to be in any way interacting with the Internet.
(not a quote from email to which this email is a reply to)

(
I'll reply to the 
> unlikely to be in any way interacting with the Internet
part there, when I find time.
)

BTW, I was happy to learn that GnuPG programmers didn't trust dbus for
IPC either.

Regards!

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170315/048628d2/attachment-0001.sig>