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

[Heiko Richter]

Am 14.01.2018 um 19:24 schrieb Heiko Richter:

didn't send that one to the list, sorry.

-------- Weitergeleitete Nachricht --------

Betreff:	Re: [Sks-devel] Fwd: Re: Unde(r)served HKPS [was: Underserved areas?]
Datum:	Sun, 14 Jan 2018 19:15:59 +0100
Von:	Heiko Richter <address@hidden>
An:	Moritz Wirth <address@hidden>

Am 14.01.2018 um 14:18 schrieb Moritz Wirth:

All in all, what do you want to do? Just keep trusted certificates or improve the numbers of HKPS Servers in the pool?

I just wrote that in several e-mail. Use established technologies to distribute valid certificates. That way it's easy to increase the number of servers in the pool. So it not an either or, but both!

So how many certificates are issued with OCSP Stapling? 0.001%? And of course you need OCSP for that (which is not the case right now, but yes you do not have the problem with a trusted CA). And what about pool servers that do not use/do not support OCSP? You want to kick out 95% of all pool servers because they do not support HKPS? Great...

Any kind of CA has OCSP, so enabling OSCP stapling is just a problem for people using insecure systems like selfsigned certificates and untrusted CAs. Furthermore wether OCSP is used or not is not the question. The question was abolishing the freaky non-secure selfsigned certificates and homegrown CAs. Enabling OCSP stapling (where available) was just an answer to you out-of-topic question earlier.

But let's go on and imagine we use Letsencrypt for HKPS. So I want a new certificate, generate a DNS challenge and send it over to? Kristian? Where is the difference with the current way of manually signing a CSR? Or you want an API so you can change the records yourself? How do you verify that and what keeps somebody from randomly issuing certificates to other people over that API using his key? You really want anybody to change the zone data? Or you really rely on Kristian to set the TXT Records for 100 certificates every month? What do you do if something happens and your certificate expires? Then you still have your browser warning (or worse...).

For you and anybody else who didn't read and/or understand the email about dns-01 challenge here it is again:
1) you create the challenge colde and send it to dns dns admin (which is kristian).
2) he publishes it into the dns zone and tells you when he's finished
3) as long as your code is there your letsencrypt client will be able to get it's certificate signed and renewd any time.
So in case of verification it's the same as right now. You send something to Kristian and hope he trustes you. At the moment this is a CSR. With Let's Encrypt it would be a DNS01 challenge code.
And who is talking about sending something every month????? Obviously you don't know what you are talking about. The challenge code is calculated *_ONCE_*, then published in DNS and as long as it's there you can renew your certificate without talking to Kristian. Whenever he decides you are not to be trusted he can delete your challenge code from the DNS and your next renewal will fail.

Feel free to propose something how this might work (and maybe setup a test environment for that)...

I did at least three times today, including this email. I hope you read it this time.

I agree that well audited, highly secured CAs are better than a single CA running somewhere on a simple server. but what keeps the CA from issuing certificates without OCSP stapling? And even with OCSP Stapling and revocation checking, if I have a trusted certificate I can simply set a HPKP Header (lets just imagine these things really work) so my leaf certificate is the only one that is trusted and serve that to everybody that connects to my server and kill all other trusted certificates for a very long time :)

Obviously nothing is 100% secure, but everything is more secure than the homegrown "Kristian-CA" which is just crap. Everything I read on this list is people like you fighting to keep crappy things that have hundrets of security holes in them. Furthermore breaking the system with something like you wrote there is much easier with the "Kristian-CA" than it is in a professional environment with real trusted certificates and CAs. Furhtermore there can be steps taken with the daily chekup script that will remove your ip addresses from the pool automatically if there's something not up to specs (e.g. checking certificate validity, enabled ocsp stapling, which headers are send ......).

FWIW, if you really want a serious discussion about this, you probably should stop calling everything you dont agree stupid, because right now you are the one behaving childish. I think we have bigger problems if aliens invade, but You are pretty sure that a CA would never issue rogue certificates (remember Symantec and Google? ;)) 

Last thing I forgot while writing this e-mail:

You just made my point. Verisign/Symantec doing their illegal braindead stuff was detected because of the existing structures. Hardcoded root certificates, homegrown CA certificates and selfsigned childplay-certificates are just as wrong as the things Symantec did and they are far mor ease to roll back as soon as a private key gets lost. What's to stop sombody from stealing the "Kristian-CA" private key and signing their own certs with it? I bet the private key of "Kristian-CA" is on a system that is permanently connected to the internet and as soon as that key gets lost *all* GnuPG installations can't be trusted to do secure HKPS because some brainbug who didn't know the first thing about security hardcoded that certificate into the software.

At least 2 people answering to the list (including you) didn't read my previous e-mail and assumed facts that were 100% *not incorrect*. Also fighting for things like homegrown CAs which were abolished decades ago for insecurity is the definition of stupidity.

But just my 2 cents...

Am 14.01.18 um 13:25 schrieb Heiko Richter:

Am 14.01.2018 um 13:04 schrieb Moritz Wirth:

Certificate Revocation is broken in most browsers today so there is no reliable way to revoke a certificate (especially if you do not use OCSP).

They are ways to deal with that and any given trusted ca does so (OCSP stampling and the must-staple header in certs just to name one of them). Having an untrusted CA like "Kristian-CA" makes it impossible to deal with that. Is there OCSP or any other kind of revocation checking available that is supported by all (or most) clients? I think not...

I don't think that it would be a big problem to get trusted certificates for HKPS, however the trust problem stays the same and it comes with other problems.

- You give up authority to a third party. Imagine, you validate the chain of a certificate to the root and the intermediate changes (because of compromise/BR Changes, whatever), it would break the HKPS implementation of all clients.

1) thats how it is with every CA (including "Kristian-CA").
2) exchanging the intermediate CA is completely immaterial as long as it is not revoked. class-3-rollovers are happening daily and they are done in a completely transparant way the users won't notice.
3) Is there an intermediate ca to encrease security on "Kristian-CA"? I Think not....
4) I would trust a large, trusted, audited CA anyday over a "Kristian-CA". That's why they have audits secure their Root-CAs offline in vaults whereas "Kristian-CA" is just a selfsigned certificate, probably stored on some server that's connected to the internet 24/7 and has not class 3 cert to increase security.
4) What kind of stupid argument is that? What happens if "Kristian-CA" is compromised? Or is that unthinkable? Perhaps you could set some time aside to discuss what will happen to the certs if aliens invade, too....

- Trusted certificates may cost some money (except for Letsencrypt but we have the validation problem there...)

We have no validation problem at Let's Encrypt. Just read my previous message, I'm not willing to type it all again.

- It is still possible for an attacker to get a certificate and do bad things with it so there is no advantage of selfsigned/Kristians certificates over trusted certificates (except the browser warnings..)

Anything is possible. The problem is not if some social engineering can give somebody a certificat. The problem is how can you revoke that cert (with "Kristian-CA" you cannot, with Let's Encrypt and OCSP-stapling you can). The other prblem is whether you are trusted by the users. If they receive error messages on a daily basis or are asked to import "Kristian-CA" that's just wrong and leaves them clueless and ignorant in case such a message is really needed because of a revoked cert. Selfsigned certs and untrusted ca certs belong in experimental environments and learning children. In the real world there are better ways to deal with security and trust and since letsencrypt you can have them for free.

I am not sure how many people really use HKPS over the web browser, most people just land on Port 11371 or Port 80.. For the SKS clients it does not matter if the certificate is widely trusted as it has the root included.

Well, just because GnuPG is fucked up in terms of certificate validation doesn't mean you should use faulty certificates. Also Several Browsers are moving to "All-HTTPS", so it's time to stop the 90s childish self-signed certificate crap and get serious about using well-established technologies. It's a sad day that your argument for not caring about correctly established certificate chains is that GnuPG is faulty and doesn't check certificates correctly.

Best regards,

Moritz

Am 14.01.18 um 11:45 schrieb Heiko Richter:

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

_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc
Description: OpenPGP digital signature