didn't send that one to the
list, sorry.
-------- Weitergeleitete Nachricht --------
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? ;))
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 --------
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