Re: [Sks-devel] Fwd: Re: Fwd: Re: Unde(r)served HKPS [was: Underserved areas?]
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 > An: Moritz Wirth > > > > > 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, enabl
[Sks-devel] Fwd: Re: Unde(r)served HKPS [was: Underserved areas?]
BTW: That certificate you wanted to sign at December 22nd will not be needed anymore. My server will adhere to security standards that have been around for decades. It will not use certificates signed by homegrown ca certificates that are hardcoded into software as it is a serious system not coming from Insecurity-Central. Any first-year-student will laugh at the concept of hardcoding public keys into software. Weitergeleitete Nachricht Betreff:Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?] Datum: Sun, 14 Jan 2018 19:23:51 +0100 Von:Heiko Richter Kopie (CC): sks-devel@nongnu.org Am 14.01.2018 um 16:55 schrieb Kristian Fiskerstrand: > On 01/14/2018 01:04 PM, Heiko Richter wrote: >> The fact that your GPG client shows a secure connection is >> either due to a faulty/incomplete validation algorithm that doesn't >> check the ca signature of the servers cert or because "Kristian-CA" is >> hardcoded into GnuPG. I don't know which one it is and don't really care >> because both situations would be relics of 90s-incompetence that >> compromise security and should have been removed from gnupg years ago. > Quite the contrary, this is the correct behavior from a security > perspective. And yes, the CA is included for the pool specifically. > > Using HKPS from web browser is less of an issue as that is wrong use of > keyservers in nine out of ten situations as a local client is anyways > needed to properly validate the packet information provided in the > OpenPGP keyblock. > > That said I'm a bit surprised about this discussion, nobody is required > to use a single pool of keyservers. > And another person fighting for things that were abolished decades ago. Sorry Kristian, but hardcoding a root certificate into a program has *never* been any kind of accepted security system. Quite the opposite, any program doing this is insecure because there is no way of revocing that root certificate. Roots don't belong into programs but into trusted certificate stores that are distributed in regular intervals and can be updates independent of the program. I understand why this was done when there was no other way, because Open Source projects don't have the money to buy trusted certificates. But with the establishment of Let's Encrypt that's just a security hole nobody needs anymore. You sign certificates that are valid for a year and you have no way of revocation that will make its way to the clients. That's just wrong. And again: It's not about the browsers, the fact that they seem to be the only programs that do *real* certificate validation because most other software uses concepts out of the stoneage is not a reason. It's the definition of stupidity! signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Fwd: Re: Fwd: Re: Unde(r)served HKPS [was: Underserved areas?]
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 An: Moritz Wirth 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 le
Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Am 14.01.2018 um 16:55 schrieb Kristian Fiskerstrand: > On 01/14/2018 01:04 PM, Heiko Richter wrote: >> The fact that your GPG client shows a secure connection is >> either due to a faulty/incomplete validation algorithm that doesn't >> check the ca signature of the servers cert or because "Kristian-CA" is >> hardcoded into GnuPG. I don't know which one it is and don't really care >> because both situations would be relics of 90s-incompetence that >> compromise security and should have been removed from gnupg years ago. > Quite the contrary, this is the correct behavior from a security > perspective. And yes, the CA is included for the pool specifically. > > Using HKPS from web browser is less of an issue as that is wrong use of > keyservers in nine out of ten situations as a local client is anyways > needed to properly validate the packet information provided in the > OpenPGP keyblock. > > That said I'm a bit surprised about this discussion, nobody is required > to use a single pool of keyservers. > And another person fighting for things that were abolished decades ago. Sorry Kristian, but hardcoding a root certificate into a program has *never* been any kind of accepted security system. Quite the opposite, any program doing this is insecure because there is no way of revocing that root certificate. Roots don't belong into programs but into trusted certificate stores that are distributed in regular intervals and can be updates independent of the program. I understand why this was done when there was no other way, because Open Source projects don't have the money to buy trusted certificates. But with the establishment of Let's Encrypt that's just a security hole nobody needs anymore. You sign certificates that are valid for a year and you have no way of revocation that will make its way to the clients. That's just wrong. And again: It's not about the browsers, the fact that they seem to be the only programs that do *real* certificate validation because most other software uses concepts out of the stoneage is not a reason. It's the definition of stupidity! 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: Unde(r)served HKPS [was: Underserved areas?]
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 >> 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 cert
Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Am 14.01.2018 um 12:40 schrieb Gabor Kiss: >> 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. > Folks, > > I don't want to chip on your hot debate (Honey! Is there any popcorn yet?) > I just wish to clarify some technical details. > > Now Kristian manages a single domain (sks-keyservers.net) and > he signes CSRs from a dozen operators. > All of these CSR are fabricated for subject "hkps.pool.sks-keyservers.net". > (So if a HKPS client (e.g. gnupg) connects to any pool servers > behind the hkps.pool.sks-keyservers.net entry it could verify > connection secureness.) Sorry, but completely false. The subject line is only a tiny little part of the verification process. The main part is checking the certificate's ca signature against the known list of valid root certificates on the client. The fact that your GPG client shows a secure connection is either due to a faulty/incomplete validation algorithm that doesn't check the ca signature of the servers cert or because "Kristian-CA" is hardcoded into GnuPG. I don't know which one it is and don't really care because both situations would be relics of 90s-incompetence that compromise security and should have been removed from gnupg years ago. > However pool operators have own distinguished key pairs and Kristian > signes them individually. > Using the suggested method above Kristian should put a new, > different TXT record into hkps.pool.sks-keyservers.net name > server every time a new operator need a certificate. > Also at every resigning. Also false. The code is only added *once* not for every cert renewal. As long as it's there, the client will be able to renew the certificate every 3 months. > (Corollary: Kristian cannot accept a new operator request > until the previous transaction is done.) Also false. There can be an unlimited number of records of the same type (in this case txt) for any given hostname. All verification codes stay in place as long as there is no reason to remove them. Only that way admins can renew their certs. > > At this point I don't understand exactly this sentence: > >> 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. > I assume Let's encrypt asks TXT record for the _same_ FQDN each time. E.g. > > _acme-challenge.hkps.pool.sks-keyservers.net. TXT "funny string here" Also completely false. There can be more then one txt record for a given hostname. Also they are not just random strings or encrypted requests. They are hash-codes derived from some values that will not change during cert renewal (like the private key for example). It would look like this: hkps.pool.sks-keyservers.net. IN TXT 180 "admin x verificationstring" hkps.pool.sks-keyservers.net. IN TXT 180 "admin y verificationstring" hkps.pool.sks-keyservers.net. IN TXT 180 "admin z verificationstring" If somebodys server is compromised or they are detected to do things they shouldn't Kristian can remove their txt record from dns and stop them from renewing their cert. > > How Kristian could "remove challenge code for _his_ server" selectively > if the DNS always contains the challenge _only_ of the latest > signing transaction? Every server has it's own challenge code that stays the same as long as the cert is just renewed and not re-generated. So removing one admin's key is quite simple. Let's assume Admin Y needs to be forced out of the pool: nsupdate -l zone sks-keyservers.net del hkps.pool.sks-keyservers.net TXT "admin y verificationstring" send quit > > Did I miss something? Just everything. > > Regards > > Gabor signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Fwd: Re: Unde(r)served HKPS [was: Underserved areas?]
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 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 be
Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
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 certific
Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Hi, 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. 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 decide wether or not to publish a server's authentication token in the dns zone or not. Furthermore you will receive "real" certificates where the admins could add the pool hostname along with their own site specific hostname into on certificates that is trusted by practically all browsers and operating systems. If you want to kick somebody out you just delete their token and their ip address from the dns zone so they won't be able included in the pool and won't be able to renew their shortlived-certificate. Furthermore you can first add the token and then do some kind of automation to check if they have a valid certificate before including them in the pool so you only need to manage the dns-01 authentication tokens. 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. Heiko PS: On December 22nd you wanted to sign the certificate for my server. Is there an update on that? Am 13.01.2018 um 21:10 schrieb dirk astrath: > Hi Kristian, > >> A misissued cert could still be used if attacker is persistent >> enough. Either through dns poision or other attack vectors. >> And yes, I only issue certs to servers I recognize to have been in >> the pool for a while and operator should be in the openpgp wot >> strong-set. > > Maybe it's wise if give some more details to the *.csr-file ... as you > will not sign certificate requests containing > unneeded/unverifyable/... information. > > (Well ... at CAcert site we remove all data we couldn't verify from > CSR and create the certificate only with the details we're able to > verify ... this could be a possibility for you, too.). > > And ... (remembering a discussion we had at Fosdem last year): > > Maybe you give some dates like (please provide CSR-requests before > 2018-xx-01), so there will only some special days per year for your to > sign a bunch of requests instead of getting the requests all over the > year ... > > Kind regards, > > dirk > > PS: Which reminds me, that i wanted to send you updated CSRs ... ;-) > > ___ > 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
Re: [Sks-devel] Looking for peers
Am 26.08.2017 um 12:43 schrieb Moritz Wirth: > Some recommendations: > > - You must run a reverse proxy in front of your sks instance to be > included in the pool. I will adapt my webserver to act as reverse proxy, will add that soon. > - The server contact should only be a PGP KeyId without your > email-address (though I dont know if it can be included there). My spam filter is working quite well and anybody who wants to feed my spam traps is welcome do do so. > - A simple key lookup on your server fails ( Error handling request: Key > could not be fetched from offset: No key dump found) Didn't know I wasn't supposed to delete the dump after building the database. Just uploaded it from last night's backup and everything is fine now. > > You can find some information here: > https://bitbucket.org/skskeyserver/sks-keyserver/overview > > If you need any help, let me know! > > Best regards, > > Moritz > > Am 25.08.17 um 20:16 schrieb Heiko Richter: >> Am 25.08.2017 um 17:37 schrieb Kiss Gabor (Bitman): >>> On Fri, 25 Aug 2017, Heiko Richter wrote: >>>>> May we see page http://www.heikorichter.name:11371/pks/lookup?op=stats >>>> Of course you may. >>>> >>>> It seems the server is still importing the dump and therefor not answering >>>> yet. >>> JFR. >>> Ten and half hour later I can see no change... >> it's up and running, sorry for the delay >> >>> Gabor >>> >> >> >> ___ >> 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
Re: [Sks-devel] Looking for peers
Am 25.08.2017 um 17:37 schrieb Kiss Gabor (Bitman): > On Fri, 25 Aug 2017, Heiko Richter wrote: >>> May we see page http://www.heikorichter.name:11371/pks/lookup?op=stats >> >> Of course you may. >> >> It seems the server is still importing the dump and therefor not answering >> yet. > > JFR. > Ten and half hour later I can see no change... it's up and running, sorry for the delay > > Gabor > signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Looking for peers
Hi there! I just finished installing and configuring sks on a server I intend to add to a pool and am now looking for some well-connected servers that are willing to peer with me. If you want to help me out please add this server to your peering list and tell me your hostname so I can add you back: www.heikorichter.name 5.9.38.226 2a01:4f8:161:22ec::2 Please note that my recon port is behind a firewall so connections will fail until I've opened the firewall for your incoming connections. With kind regards Heiko Richter signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
