sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sks-devel] Fwd: Re: Unde(r)served HKPS [was: Underserved areas?]


From: Heiko Richter
Subject: [Sks-devel] Fwd: Re: Unde(r)served HKPS [was: Underserved areas?]
Date: Sun, 14 Jan 2018 10:45:21 +0000 (UTC)
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

PS: Everything you wrote would have been true in 1998. The world of SSL has evolved since then......



-------- Weitergeleitete Nachricht --------
Betreff: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Datum: Sun, 14 Jan 2018 11:39:34 +0100
Von: Heiko Richter <address@hidden>
An: address@hidden
Kopie (CC): address@hidden


Am 14.01.2018 um 10:27 schrieb dirk astrath:
> Hello,
>
>> fist of all CACert is total crap. They have been removed from the linux
>> distributions they were (falsely) included in and no browser ever
>> trusted them because they can't seem to pass the security audits. I
>> realize this comment will probably cause me a lot of ranting but it has
>> to be said that having certficates signed by CACert is no better then
>> signing them yourself.
>
> We could now start a flame-war against CAcert and/or PGP, for or
> against different styles of Web-Of-Trust, for or against different
> tools to be installed to use the this Web-Of-Trust or inclusion in
> mail- or webclients/browsers/distributions ... or not.
>
> But we should not do it here ... ;-)
>
> (NB: There is a difference between selfsigned and CAcert ... see below)

If the ca certificate is self-signed an untrusted by *all* browsers
there is no difference at all. CACert failed all audits and has been
removed from all browsers and operating systems with good reason. Having
a certificate signed by them or signing it yourself makes *no*
difference in terms of security and trust.

Furthermore it is not the question if *you* trust that certificate and
if *you* installed the CACert root into you ca store. The question is
about the error messages a visitor will receive. With CACert,
Kristian-CA and self-signed that message will be
"hkps.sks-keyservers.net" is not trustworthy. With Let's Encrypt the
message will be "You are surfing on a secure site".

>
>> Just use Let's Encrypt certificates. They are short lived certificates
>> and through the dns-01 challenge you will stay in control as you can
> (..)
>> That way you can drastically increase the amount of servers included in
>> the hkps pool while decreasing your workload and and having a huge plus
>> in security and trust through the validatable certificates.
>
> Using LE (or any other being-in-the-browser-CA) will not easily be
> possible.

Sorry, but this is just a flat-out-lie.

Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.

>
> For your Keyserver you can use a Certificate issues by any CA as long
> as it should not contain one of the pool names. On my server I decided
> to use Let's Encrypt.

You can of course but certificate validation will fail if the user comes
to you through the pool hostname. It's ugly, impolite and just rude to
confront the user with such a message. And a web-of-trust that greets
it's users with a this-site-is-not-trusted message ist just stupid.

>
> To contain one (or more) of the pool names the certificate has to be
> issued (or provided) by the owner of this domain (in this case Kristian).

That's another lie, the admin can create the certificate himself if the
dns-01 challenge is used (see above).

>
> But ...
>
> Kristian will not hand over the private key for a pool-certificate to
> anybody. If he would nearly "anybody" would be able to get the private
> key and CA-signed certificate (as it's outside of Kristians control)
> ... which would not strengthen the security of a pool-certificate.

Why should he have to hand ofer a private key? The admin creates the
certificate himself (see above).

>
> Another way is setting up a CA by Kristian especially for this purpose
> to create certificates only for keyserver-pool-names (and your
> servername). Unfortunately this local CA is in the same status as your
> self-signed certificate or CAcert: Not included in any mail-clients or
> browsers.
>

Having your own private CA that is not trusted by browsers ist just as
bad as using CACert. Greating users (who potentially don't know what
they are talking about) with a this-site-is-insecure message just
stupid, especially when a better alternative is available.

> But ...
>
> This special "Kristian-CA"-case has advantages even without being in
> the mail-clients/browsers:
>
> The software to be used to "ask" the keyserver-pools can contain the
> root-certificate of this CA ...
>
> ... and ... signing your webserver-key by "Kristian-CA" will show
> others, that your server is a trusted server of the keyserver-pool (a
> status you will not get by using a self-signed certificate).

This way has only disadvantages. Especially because the revocation
status of a certificate cannot be checkt by a normal user. If
Kristian-CA revokes a certificate, the user will have a message that is
the same (or almost the same) as the message he always receives. So he
will just click ignore. This reeks of stupidity and incompetence.

>
> Kind regards,
>
> dirk



Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]