Major internet keyservers are not forced to https

[jumper444]

Keyservers on the internet hold and verify encryption, keys, signatures, etc...of pretty much everything. Keys are retrieved and uploaded using various programs such as GPG. However most, if not all, of these keyservers also have a web interface whereby the same keys can be searched for, verified, retrieved, etc.

Two of the largest keyservers are below. You can visit their web interface normally in a browser. pgp.mit.edu keyserver.ubuntu.com (There are more and readers are welcome to help me expand the list to get all the main servers).

ISSUE: visiting either of these sites while "HTTPS Everywhere" is on does not switch to or enforce an https:// link even though each of these servers has one and can serve secure/encrypted content. When a person is trying to look up or verify keys the use of https connection is very important to prevent man in the middle attack changing a key during internet transit.

I'm not aware of the inner workings of HTTPS Everywhere, but please add automatic enforcement of https connection for these two keyservers and for any other major ones that others can suggest. I presume you have a ruleset or list these would be added to. Thank you.

[jumper444]

Here is a list of approx 114 keyservers that seem to be active across the internet and in some sort of verified 'pool' (mit.edu and ubuntu.com are included among many many others): https://www.sks-keyservers.net/status/

I don't know the criteria for this pool, but these seem to be the main authoritative internet keyservers. I spot checked a few of them and most/all seem to have an http interface that will also switch to https if you manually retype the url (or, as mentioned, if HTTPS Everywhere starts enforcing it). In one or two instances I had to drop the port number from the keyserver's listed address in order to get https connection).

I suggest this list of servers (minus port numbers) be placed on the HTTPS Everywhere 'enforce https' list (or however the program determines it should enable for a site.)

[ghost]

12000

[ghost]

12001

[ghost]

12003

[ghost]

12004

[ghost]

12005

[Bisaloo]

As a side note: most of the time, keyservers will be accessed using hkp not http so adding targets for them will only offer very limited protection.

[jumper444]

There is a specific and valuable use to access keyservers with HTTPS. The GPG '--retrieve-keys' command (from a keyserver) does not use any encryption when downloading keys. (Surprising, I know). Thus anything downloaded this way can be replaced MITM attack.

The reply/defense you will get on threads is 'well...it doesn't matter because all the keys verify each other in webs of trust and therefore any replaced key will be caught'.

Yet I don't have any web of trust connection between myself and high level keys on various projects like Ubuntu or OTR or whatever across the internet. In light of not having a trusted connection I have fallen back on my 2nd best approach (which frankly can be automated, but I'm not sure anybody has done it yet in some sort of program.) That approach is to seek and retrieve keys from multiple locations (using HTTPS) and further comparing to the originating software site download page. The theory here is that while a malicious party might be able to compromise a specific keyserver, or download page, or non HTTPS link, or a specific cert provider....that they will NOT be able to compromise multiple accesses of such a signing key when I use 2, 3, or 4 distinct and different routes and methods to find it.

Thus...if i'm trying to verify something, I can have gpg download and verify the key from pgp.mit.edu (which is unsecure). It will say the key matches, but that it is untrusted. Then...I can access keyserver.ubuntu.com via HTTPS to look at the same key and check fingerprint. Finally I might open Tor and use it check a 3rd keyserver (or to look at the sig on the original software download page, but thus looking at it from a different internet endpoint instead of my home ISP outgoing.)

It isn't as good an approach as just haveing a trusted key chain, but it is 2nd best because (other than my actual desktop being compromised which kilss the idea, but would compromise the GPG executable anyway) a malicious party has to get to multiple points on the internet AND compromise multiple certs, machines, or endpoints for me not to catch it.

That is how I uncovered this problem with HTTPS Everywhere...i was visiting (manually) keyservers to do double and triple checks on some sigs and realized it wasn't forcing https even though it was available. Thank you for adding the keyservers to the 'force https' list which is what I presume the pull request above does. In the situation/reasoning I've provided there is a real need and use and if somebody doesn't catch it they won't realize they are reading certs from keyservers in the clear.

[ghost]

@jumper444 The key's fingerprint won't match if was replaced.

[J0WI]

AFAIK the no-honor-keyserver-url option is default in GnuPG. You can also set your default keyserver in your gpg.conf to one that supports https or hkps. But this is far away from the scope of this project.

Please add a list of specific HTTP hosts that are not yet included in HTTPS Everywhere. You're also welcome to open PRs to add this hosts.

[ghost]

@J0WI I am already working on adding the hosts from the list @jumper444 linked to.

[jumper444]

Thank you koops. I haven't written any rulesets (of course I could learn) however it also mentions that there are bulk toolsets available which is another step. Someone familiar with both could do this in a fraction of the time (I haven't done a pull request yet either.) If it isn't much more than a copy/paste/go/upload for somebody who has done dozens of these before, the help is appreciated.

[jeremyn]

It's definitely okay to create PRs to rewrite GPG-related domains to use HTTPS. That said, the equivalent for getting GPG keys through an encrypted channel using the gpg command-line tool is to use hkps URLs.

[jumper444]

"hkps" (I had to look it up) is just one more protocol/setting/option/transport that a person has to learn (or know about; I didn't) in order to get things done in life. (And what I did find didn't say it was encrypted...it just said it was the special method of transporting keys, like json and others are special ways of packaging data.)

In today's world there are simply too many complexities already in computers...often in encryption terribly so....to force (that wasn't what you are doing; it was a polite suggestion, I understand) one more manual, man page, or ITEF spec on somebody. Most know HTTPS and most know how to use it and what it means. It's great that there is some custom key protocol out there and if I was in the key server business obviously it would be necessary, but if many people can get to a keyserver securely and retrieve/verify a key using a simple browser then that is a very valuable path to not exclude. (Thanks again for you guys adding it)

[zoracon]

This seems resolved, closing.