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

2018-01-14 Thread Kristian Fiskerstrand
On 01/14/2018 07:43 PM, Heiko Richter wrote:
> 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.

To make sure this isn't un-challenged in the archives, the secret key
never touches an online system, all operations are done on airgapped setup.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Qui audet vincit
Who dares wins



signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


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

2018-01-14 Thread 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 <em...@heikorichter.name>
> An:   Moritz Wirth <m...@flanga.io>
>
>
>
>
> 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,