sks.spodhuis.org, a mostly private keyserver providing HKP access to keys on ports 11371, 80 and 443. Note that while port 11371 does not require a Host: HTTP header, ports 80 and 443 do, and port 443 requires TLS SNI to serve the correct certificate.
This service may be withdrawn at any time and without notice to end-users. (Peers will be notified). End-users should either use a service which they evaluate and have a trust relationship with, or use a pool definition, such as keys.gnupg.net which will alias into an operational pool.
Note: this service is provided free, to the public, in the hopes that it might prove useful. No warranty is provided, nor any offer of continuing service or access. By using this service, you MUST understand that presence of data in the keyserver (pools) in no way connotes trust. Anyone can generate a key, with any name or email address, and upload it. All security and trust comes from evaluating security at the “object level”, via PGP Web-Of-Trust signatures. This keyserver makes it possible to retrieve keys, looking them up via various indices, but the collection of keys in this public pool is KNOWN to contain malicious and fraudulent keys. It is the common expectation of server operators that users understand this and use software which, like all known common OpenPGP implementations, evaluates trust accordingly. This expectation is so common that it is not normally explicitly stated.
My company, ‟Pennock Tech, LLC”, provides the funding and resources of this keyserver as a public-good; the keyserver continues to operate under the name of some personal services I ran before the company existed, rather than break historical compatibility.
For administrative questions, contact any of the non-revoked email addresses in my PGP key. (Use verbose index to see which are revoked.) Or use keyserver as the left-hand-side, in the domain spodhuis.org.
Note that this host peers as
sks-peer.spodhuis.org and SKS-protocol peering requests are often accepted; I'm willing to set up email-based exchange for non-SKS speakers.
For more information on PGP, try starting at: Mr Dibowitz's PGP pages.
For more information on SKS keyservers, see www.sks-keyservers.net which maintains current status listings and a map of the keyserver connectivity. Meanwhile SKS is nongnu GPL software. The code site is hosted on Atlassian BitBucket and the wiki there does not yet contain much, but does include a guide to setting up peering, written by me.
Some more information about PGP keyservers in general, focusing on HKP-speakers (such as this one) is available on this author's personal pages.
Keys sign other keys, building up a “web of trust” based on chains of signatures. If you group the keys together based on existence of paths between them, to make multiple islands of keys, then the largest such island is the Strong Set. Henk Penning has a page with more formal definitions and various statistics. If your key is in the Strong Set, then you can use tools which find the paths between two keys to find the keys you might need to reach another key in the Strong Set, if you decide to trust those intermediates.
This keyserver peers as
The code for the mesh is available on GitHub.
There are three categories of data relevant to privacy here: the public keys stored; the HTTP/HKP requests made to access/upload/retrieve those keys; what I as a keyserver might do with those requests (logs).
For the public keys: the SKS keyserver pool, run globally by disparate individuals with no formal affiliation, is currently an append-only store, designed to protect against attempts to remove data. Once a key has been uploaded, that data is part of the public record, designed to allow anyone to attempt to verify the name binding within the key, using the public attestations by others about the identity of the key (key signatures). Keys not intended for public disclosure should not be uploaded, nor shared to people who might upload the keys of others. Note that there's no protection against fraudulent keys, with bindings of any name to any email address, and there is no basis to believe any such pairing without first proceeding through evaluation of the public attestations.
The requests to retrieve/publish public keys are made over HTTP/HTTPS, following a specific schema which in combination is called HKP. If you make a request over HTTP, you have no privacy against on-path snoopers. If you use HTTPS without verification, you have no privacy against on-path tampering systems (‟active attacks”).
If you use HTTPS to access this keyserver under the name sks.spodhuis.org then you should be presented with a verifiable certificate (currently: issued by Let's Encrypt) and be able to have some confidence in the privacy of links between your software and the server instance(s) which I run. This can be configured in some OpenPGP clients (such as GnuPG) with the URL hkps://sks.spodhuis.org/.
If you access this keyserver via a name which is a ‟pool name” then you do not know if you are accessing this keyserver or any other keyserver in the pool. Using HTTPS (HKPS) provides protection against on-path tampering, but does not provide any protection against malicious keyserver operators. There is no known sane way to have meaningful verification of affiliation or character before admitting a keyserver operator into the HKPS pools. Use of such a pool is a trade-off between ‟some privacy, at least” and ‟privacy you can count on”. If this is a concern for you, then find a keyserver operator whom you trust and configure your client to use a keyserver operated by them.
As to logs: I can only assert the behavior of the keyserver(s) I control, not any others in the pool or otherwise. The spodhuis.org keyserver(s) has two categories of logging, both applied for operational reasons. There are no tracking cookies, no affiliate systems and no loading of resources from other entities. The server itself may be run as a virtual machine in a ‟cloud provider” which means that the policies and practices of such a provider come into play too. At this time, I am using Amazon Web Services (AWS).
The operational logs are divided into "HKP" and "non-HKP". The non-HKP traffic is typically that of a web-browser and affects you as you're reading this text. These are normal webserver logs, retained for an operationally relevant period of time, including origin IP address and other information sent by your browser, together with diagnostics about the access. The HKP traffic, for retrieving/sending keys, is all under the /pks/ path on this server, and that logging completely avoids anything which might reasonably be considered sensitive. In particular, your IP address and browser User-Agent are not logged for HKP. In an emergency, I reserve the right to temporarily increase logging or otherwise capture traffic: (1) to protect my systems from attack or being used as a source/reflector/amplifier of an attack; (2) to comply with an appropriately issued legal order.
This server is a VM in the USA, operated by a US citizen and subject to the laws of two states of the USA; specifically, of Pennsylvania (the operator) and perhaps Ohio (the VM).
All keyserver clients must use TLS 1.0 or greater, and must send ServerNameIndication in the TLS handshake. While there is no standard stating this, operation of the public keyservers in practice requires it.
Each keyserver implementing TLS is currently doing so with a “reverse proxy” in front of SKS (or equivalent), and the proxy handles TLS termination. In practice, a keyserver can be known by many names and each keyserver operator chooses for themselves what certificate policy they choose for names which identify just their keyserver. Separately, a keyserver DNS pool operator can choose entry criteria for their pool and work with the individual operators to make that work.
At present, there is one public pool collecting HTTPS/TLS servers, hkps.pool.sks-keyservers.net. Membership in that pool uses certificates signed by a root CA certificate (and detached PGP signature) issued by Kristian Fiskerstrand. See the GnuPG configuration instructions on www.sks-keyservers.net/overview-of-pools.php.
Operators generate a key for the relevant vhosts, send a CSR (PGP signed) to Kristian, who issues a TLS X509v3 cert for use for the relevant vhosts. Thus the need for ServerNameIndication. (The sks-keyservers.net root CA cert is also available on this site (signature) and on my security site (signature), where it is available over https with an X.509 TLS certificate issued by a root CA in most common browsers.)
hkps://sks.spodhuis.org/ uses a certificate issued by Let's Encrypt. Historically it was issued by the server operator's private CA. No guarantees about what will be used in the future, but we're currently happy with Let's Encrypt.
Some other test names use a certificate issued by the server operator's private CA, which there's no reason for the general public to trust. This operator is currently willing, at his discretion, to work with anyone else setting up a pool, providing vhosts.
The ServerNameIndication (SNI) sent should be the trusted name supplied by the user (or config) and not derived from DNS (via SRV records), perhaps unless DNSSEC is used. It's simplest (and likely correct) to just mandate “never chase names from SRV, even with DNSSEC present”. This name is used for selecting the certificate, and should then be used for validating the cert during the handshake. (In GnuPG terms, leave “ --keyserver-options check-cert” turned on).
The choice of name for SNI is not correctly handled in current GnuPG releases [issue 1447] (awaiting word from GnuPG folks to confirm that they agree this is a bug).
The “hkp:” (& “hkps:”) URL scheme is effectively HTTP, with a different default port and a template for constructing a query given a search term. There is no published standard; there was a draft, and today the de-facto rules are “whatever the SKS developers and GnuPG developers agree to between them”.
Thus the default port for HKP is 11371; the default port for HKPS is 443.
The SRV records used are for _pgpkey-http._tcp & _pgpkey-https._tcp respectively.
Bugs in some releases of GnuPG might cause the port number from the SRV records to be ignored. [issue 1446]