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, 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 <em...@heikorichter.name> >>>>> An: sks-devel@nongnu.org >>>>> Kopie (CC): dastr...@gmx.de >>>>> >>>>> >>>>> >>>>> 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 >>>>> Sks-devel@nongnu.org >>>>> https://lists.nongnu.org/mailman/listinfo/sks-devel >>>> >>> >>> >>> >>> _______________________________________________ >>> Sks-devel mailing list >>> Sks-devel@nongnu.org >>> https://lists.nongnu.org/mailman/listinfo/sks-devel >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
