Matt Rude | 24 May 19:14 2015

Seeking Peers for new keyserver openpgp.us

Greetings,

I am looking for peers for a new SKS keyserver installation.

I am running SKS version 1.1.5+, on openpgp.us.
The servers are physically located in New York, Minneapolis, Dallas.
The machine has IPv6 connectivity and the needed ssl certs.

https://openpgp.us is currently using load balancing between 3 different
hosts.

I have loaded a keydump from my other keyserver; keyserver.mattrude.com.
Currently there are 3943449 keys loaded.

For operational issues, please contact me directly.

openpgp.us 11370 # Matt Rude <matt@...> 0xC4909EE495B0761F

Thank you,

--

-- 
Matt Rude
Minneapolis, Minnesota, USA
Website: http://mattrude.com
OpenPGP: 0xc4909ee495b0761f

Greetings,

(Continue reading)

Dale Scheppler | 22 May 02:10 2015
Picon

Seeking peers for cewr.info

Hi,

I am looking for peers for a new SKS keyserver installation.

I am running SKS version 1.1.5-3, on cewr.info.
This is a private machine.
The server is physically located in Keystone Heights, Florida (US).
The machine does not have IPv6 connectivity.

I have loaded a keydump from keyserver.mattrude.com, dated Thu May 21 05:03:08 UTC 2015.
I see 3940869 keys loaded.

For operational issues, please contact me directly.

cewr.info 11370 # Dale Scheppler <drscise@...> 0xF97EC882

And now to break from form just a hair. Registrar doesn't support wildcard subdomains,
so just using the root domain. If you want to get to the keys search page faster, cewr.info/keys.

Thank you,
-Dale Scheppler

Hi,

I am looking for peers for a new SKS keyserver installation.

I am running SKS version 1.1.5-3, on cewr.info.
This is a private machine.
(Continue reading)

Jayden Callahan | 20 May 19:15 2015
Picon

seeking peers for aes.keys.peer.sh

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I am looking for peers for a new SKS keyserver installation.

I am running SKS version 1.1.5+, on aes.keys.peer.sh.
This is a private machine.
The server is physically located in London (UK).
The machine has IPv6 connectivity.

I have loaded a keydump from keyserver.mattrude.com, dated 2015-05-20.
I see 3939929 keys loaded.

For operational issues, please contact me directly.


Thanks,
 Jayden Callahan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVXMC7AAoJELPqJICxO67yyuAP/jrMopQDNQAY8yQenzUEfdiY
hdC+EyGB1ITXYfPRJYNsIjBPQAxPr0ts5cQHXHX4N2mA3iVfdRX0UVYHPI0MkmNb
wy+8B/tlDVpSRBswE+9FVlEgNoaefutgpx5whqdq4b6fSARzJ7hj1ah/jYMs1NCa
8lNrCFJyHYvFx7tIyojI4Eaf68ZbH/bQDBqVNgLTlpKJJbMWBX+zzLumRVw4WjGh
BJxapazo7Q4vOlw7EPmDqQtEiMRU0N/A0iKNSftqY96wgynG29hbnAClXOaUo01U
g2ke6Q+EG0wXVNvmNiHJV2tf+9SmVtcYwO/XEI2xpgCYZp8tnZ9LvY4Zkkb9gDBT
jONm7tTBPp4MebjvICII46l6HOit/Sl98RndTtLjChV+76qnYBSU4mSBJqkAIGcO
+TnVg+qDG1gnXVyVooAXFHh8A2/bqmyQS+gvI2aTE214Yr5jaCp0v8xv/UXyETM7
KY1PSbPSs/I2UpMHtstlcfkq47kxHKKHB9YSxPZ7FVBv4aH2u7NX9UTQtZ93EI5d
xqmKQfzeWfrNdS7inAVDD94BsDTuz63YZarn35SDr4+0maeFdznObZJcRsOIIF4w
9wbBhYU/0AV8xETUu5HF+l44f2gyzx4SA5c0jL+nm/bxYruGbw4xG24eBb2EjY5a
0ETSKrwrLQVDedxgn2lk
=csgb
-----END PGP SIGNATURE-----
<div><div dir="ltr">
<div>-----BEGIN PGP SIGNED MESSAGE-----</div>
<div>Hash: SHA1</div>
<div><br></div>
<div>Hi,</div>
<div><br></div>
<div>I am looking for peers for a new SKS keyserver installation.</div>
<div><br></div>
<div>I am running SKS version 1.1.5+, on <a href="http://aes.keys.peer.sh">aes.keys.peer.sh</a>.</div>
<div>This is a private machine.</div>
<div>The server is physically located in London (UK).</div>
<div>The machine has IPv6 connectivity.</div>
<div><br></div>
<div>I have loaded a keydump from <a href="http://keyserver.mattrude.com">keyserver.mattrude.com</a>, dated 2015-05-20.</div>
<div>I see 3939929 keys loaded.</div>
<div><br></div>
<div>For operational issues, please contact me directly.</div>
<div><br></div>
<div>
<a href="http://aes.keys.peer.sh">aes.keys.peer.sh</a> 11370 # Jayden Callahan &lt;<a href="mailto:rails@...">rails@...</a>&gt; 0xDB0EEEB1</div>
<div><br></div>
<div>Thanks,</div>
<div>&nbsp;Jayden Callahan</div>
<div>-----BEGIN PGP SIGNATURE-----</div>
<div>Version: GnuPG v2</div>
<div><br></div>
<div>iQIcBAEBAgAGBQJVXMC7AAoJELPqJICxO67yyuAP/jrMopQDNQAY8yQenzUEfdiY</div>
<div>hdC+EyGB1ITXYfPRJYNsIjBPQAxPr0ts5cQHXHX4N2mA3iVfdRX0UVYHPI0MkmNb</div>
<div>wy+8B/tlDVpSRBswE+9FVlEgNoaefutgpx5whqdq4b6fSARzJ7hj1ah/jYMs1NCa</div>
<div>8lNrCFJyHYvFx7tIyojI4Eaf68ZbH/bQDBqVNgLTlpKJJbMWBX+zzLumRVw4WjGh</div>
<div>BJxapazo7Q4vOlw7EPmDqQtEiMRU0N/A0iKNSftqY96wgynG29hbnAClXOaUo01U</div>
<div>g2ke6Q+EG0wXVNvmNiHJV2tf+9SmVtcYwO/XEI2xpgCYZp8tnZ9LvY4Zkkb9gDBT</div>
<div>jONm7tTBPp4MebjvICII46l6HOit/Sl98RndTtLjChV+76qnYBSU4mSBJqkAIGcO</div>
<div>+TnVg+qDG1gnXVyVooAXFHh8A2/bqmyQS+gvI2aTE214Yr5jaCp0v8xv/UXyETM7</div>
<div>KY1PSbPSs/I2UpMHtstlcfkq47kxHKKHB9YSxPZ7FVBv4aH2u7NX9UTQtZ93EI5d</div>
<div>xqmKQfzeWfrNdS7inAVDD94BsDTuz63YZarn35SDr4+0maeFdznObZJcRsOIIF4w</div>
<div>9wbBhYU/0AV8xETUu5HF+l44f2gyzx4SA5c0jL+nm/bxYruGbw4xG24eBb2EjY5a</div>
<div>0ETSKrwrLQVDedxgn2lk</div>
<div>=csgb</div>
<div>-----END PGP SIGNATURE-----</div>
</div></div>
Christiaan de Die le Clercq | 19 May 21:18 2015
Picon

Nginx. HKP and HKPS on same port

Hi all!

I just want to share something I use on my keyserver.
If you enable ssl (hkps) Nginx will automatically assume that the 11371
port is ssl.

However if you add this:
error_page 497  https://$host:$server_port$request_uri;

Then Nginx will redirect http requests to port 11371 to https requests
when the port is SSL.
That way you can have both on the same 11371 port!

Something worth sharing, have a nice day!
-- 
Kind regards,

Christiaan de Die le Clercq
Administrator of keys.techwolf12.nl

GPG: 0x9FB800372F2546D8

Hi all!

I just want to share something I use on my keyserver.
If you enable ssl (hkps) Nginx will automatically assume that the 11371
port is ssl.

However if you add this:
error_page 497  https://$host:$server_port$request_uri;

Then Nginx will redirect http requests to port 11371 to https requests
when the port is SSL.
That way you can have both on the same 11371 port!

Something worth sharing, have a nice day!
--

-- 
Kind regards,

Christiaan de Die le Clercq
Administrator of keys.techwolf12.nl

GPG: 0x9FB800372F2546D8

Daniel Roesler | 17 May 22:47 2015
Picon

Proposal: Start verifying self-signatures


Howdy all,

I'm sure by many of you have read the news that a very poorly
generated 4096 RSA keypair was factored.

Disclosure: http://trilema.com/2015/full-disclosure-4096-rsa-key-in-the-strongset-factored/

Discussion: https://news.ycombinator.com/item?id=9560790

The key in question (0x51221121) is listed in the keyserver pool as a
subkey for H. Peter Anvin[1]. However, it appears that the signature
on this subkey[2] is a direct copy of the signature on HPA's other
subkey[3]. So this broken subkey appears to have been added manually
and the signature packet copied. Unfortunately, since sks-keyservers
don't check self-signatures on public key packets, this broken subkey
was allowed to be uploaded to the sks-keyserver pool and gossiped
around. If a client imported this public key without checking the
subkey signature (there are more clients out there than GPG), they
might have been fooled into believing that a file was signed by HPA.

I'd like to propose that we revisit the decision to not be proactive
about verifying signatures in the sks-keyserver. Yes, it will always
fall on the client to verify signatures themselves (which GPG does by
not importing the broken subkey), but we should also make and effort
to prevent unverified subkeys from being gossipped around the pool.
Adding defense in depth is a good thing.

To start, I'd like to propose that User ID, User Attribute, or SubKey
self-signatures are verified on upload and on receive from gossip are
verified. If a User ID, User Attribute, or SubKey packet is not
verified via self-signature, the packet should be considered in an
invalid format and dropped.

Pros:
1. Makes it more difficult to insert bogus subkeys into the keyserver pool.
2. Prevents denial of service attacks that allows Mallory to spam a
bunch of new subkeys, user ids, or huge images onto a public key.
3. More confidence for users that are browsing the web interface that
the subkeys/userids that they are seeing are verified.
4. Adding defense in depth to the public key infrastructure.
5. Since we are just verifying self-signatures, there are no worries
about what to do if the issuer does not have their public key in the
pool (we should discuss being proactive about verifying
non-self-signatures, too, but we can discuss that at a later date).

Cons:
1. This adds some cryptography to the sks-keyserver. Luckily,
signature verification crypto doesn't have to worry about side channel
attacks. Alternatively, we could add openssl as a dependency and
outsource the signature verification to it.
2. This adds verification overhead to the server when uploading or
gossiping keys. Computers are much faster nowadays, so I don't know
that we can use this excuse anymore. We should error on the side of
being more proactive about security rather than efficiency.

What were the previous arguments against verifying self-signatures?

Thanks!
Daniel Roesler

[1]: http://p80.pool.sks-keyservers.net/pks/lookup?op=vindex&search=0x51221121
[2]: https://gist.github.com/anonymous/ba23ca66d2ca249e6f84#file-hpa-pub-json-L498
[3]: https://gist.github.com/anonymous/ba23ca66d2ca249e6f84#file-hpa-pub-json-L566

Alain Wolf | 17 May 17:03 2015
Picon

HKP and HSTS


Hi all

I don't suppose that a lot of people a affected by this. But it doesn't
look nice so I had to do something about it. Maybe some of you are
interested.

If the domain of your keyserver has strict HSTS enabled it may create a
problem for browsers accessing the HTML interface of your keyserver on
the SKS port.

If a modern browser is directed to a website on a non-standard TCP port
in a HSTS enabled domain, the browser will attempt to initiate a TLS
connection on that port, even if the URL starts with http:// and not
https://. If the TLS handshake subsequently fails, an error page is
displayed to the user and thats it then.

So users visiting our keyservers web-interface on port 11371 will be
greeted with a security error message.

This behavior may seem strange but its currently the only way of
ensuring security. The browser MUST enforce HSTS but also has no secure
way to learn about or assume on what other presumably non-standard TCP
port number, he could attempt a secure connection.

The problem and and decisions made on how to handle it are described in
this blog post by Andy Steingruebl:
http://securityretentive.blogspot.ch/2010/11/quick-clarification-on-hsts
-http-strict.html

I noticed this when I tried to click on the links of some SKS servers on
the pool status pages. i.e. http://keyserver.mattrude.com:11371/ or my
own http://pgpkeys.urown.net:11371/

As a workaround I installed sslh
(http://www.rutschle.net/tech/sslh.shtml) on my keyserver. It listens on
TCP port 11371 and tries to sniff out the protocol used and forwards the
connection either to port 11371 or 443 on the localhost address where
Nginx is listening.

sslh is available in the Ubuntu, Debian, SUSE and Fedora software
package repositories.

My /etc/sslh.cfg file:

-------------<snip>-------------
#
# sslh configuration for HKP OpenPGP keyservers
#

verbose: false;
foreground: false;
inetd: false;
numeric: true;
timeout: 2;
user: "sslh";
pidfile: "/var/run/sslh.pid";

# List of interfaces on which we should listen
listen:
(
    { host: "192.0.2.37"; port: "11371"; },
    { host: "2001:db8::37"; port: "11371"; }
);

# List of protocols
protocols:
(
     { name: "http"; host: "127.0.0.37"; port: "11371"; probe: "builtin"
; },
     { name: "https"; host: "127.0.0.37"; port: "443"; probe: [ "" ]; }
);

# Fallback protocol
on-timeout: "http";
-------------<snip>-------------

Of course you have to tell Nginx not to listen on port 11371 on the
those IPs and listen on 127.0.0.37 instead.

Regards

Alain
Andreas Puls | 15 May 12:59 2015
Picon
Picon

IPv6 / IPv4 address change for keys.andreas-puls.de

Hey folks,

The AAA and A record for *keys.andreas-puls.de* has been changed.
New records are:

  AAA : 2a00:1910::edc5:5134
  A   : 85.93.13.183

The old address aren't not working anymore

Kind regards
  Andreas

Hey folks,

The AAA and A record for *keys.andreas-puls.de* has been changed.
New records are:

  AAA : 2a00:1910::edc5:5134
  A   : 85.93.13.183

The old address aren't not working anymore

Kind regards
  Andreas

Christiaan de Die le Clercq | 14 May 13:02 2015
Picon

HKPS certificate

Hi!

I am wondering if I can still get a certificate for keys.techwolf12.nl,
my server has been stable for over 3 months now and I would like to add
an extra layer of security.

I've emailed Kristian a few times now without getting a response.

Does anyone know how to get an certificate?

-- 
Kind regards,

Christiaan de Die le Clercq

GPG: 0x9FB800372F2546D8

Hi!

I am wondering if I can still get a certificate for keys.techwolf12.nl,
my server has been stable for over 3 months now and I would like to add
an extra layer of security.

I've emailed Kristian a few times now without getting a response.

Does anyone know how to get an certificate?

--

-- 
Kind regards,

Christiaan de Die le Clercq

GPG: 0x9FB800372F2546D8

Antony Prince | 7 May 00:49 2015

Change of contact for keyserver.blazrsoft.com


To all the peers of keyserver.blazrsoft.com, my contact key ID has
changed from 0xA6E162424F040744 to 0xAF3D4087301B1B19.

0xA6E162424F040744 has been revoked as it has been superseded by
0xAF3D4087301B1B19.

I apologize for any inconvenience.

--

-- 

Antony Prince

Key ID: 0xAF3D4087301B1B19
Fingerprint: 591FF17F7A4AA8D0F659C482AF3D4087301B1B19
URL: https://keyserver.blazrsoft.com
Kim Minh Kaplan | 6 May 17:59 2015

Re: normalbuild segfaults

Please keep the mailing list tuned in.

malte <at> wk3.org <malte <at> wk3.org> wrote:

> Kim Minh Kaplan wrote:
>
>> I can see some functions that are not tail recursive¹ and could cause
>> some out of memory condition when “-n” is too big. We should probably
>> fix this. In the mean time check that your stack allocation is not
>> overly restrictive (ulimit -s).
>
> Ok. Is
>
> ulimit -s
> 8192
>
> good enough?

I do not know. Good enough would be when build does not segfaults.
Does it? Can’t you set it to unlimited ?

> (and how would I increase it?)

If you are using bash I think “ulimit -s unlimited” should do it.
--

-- 
Kim Minh.
http://www.kim-minh.com/

_______________________________________________
Sks-devel mailing list
Sks-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Alain Wolf | 5 May 01:48 2015
Picon

pgpkeys.urown.net is looking for peers


Hi,

I am looking for peers for a new SKS keyserver installation.

pgpkeys.urown.net is running SKS version 1.1.5+ on a a private machine.
The server is physically located in Zurich, Switzerland.
The machine is reachable over IPv6 and as Tor Hidden Service.

I have loaded a keydump from keyserver.mattrude.com, dated 2015-05-01.
I see 3,924,514 keys loaded.

For operational issues, please contact me directly.

pgpkeys.urown.net      11370 # <keymaster@...> 0x27a69fc9a1744242
pgpkeysximvxiazm.onion 11370 # <keymaster@...> 0x27a69fc9a1744242

Thank you,

Alain Wolf

Gmane