Re: [Sks-devel] quality of keyservers offering hkps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14. August 2014 05:31:40 MESZ, Phil Pennock sks-devel-p...@spodhuis.org wrote: What is the threat model which you are trying to protect against? As the public keys themselves are of cause nothing which needs to be secured, I see these two possible aspects: - - meta data like 'who up-/downloaded which keys' could be revealed - - mitm attacks may manipulate up-/downloaded keys Or am I thinking in the wrong direction? -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iHEEAREIABoFAlPsndgTHE1hdHRoaWFzIFNjaHJlaWJlcgAKCRCTx5mTdvm6YJoP APdcwvUoviWwrXwQXnFl4xgcJdsMxpmrwi3OhYjMbMxDAP92ncpZ6L690fsP56mI y6/1D3UJxrVuQvoS6BLZylceSA== =O+Ja -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] quality of keyservers offering hkps
As the public keys themselves are of cause nothing which needs to be secured, I see these two possible aspects: - meta data like 'who up-/downloaded which keys' could be revealed yes - mitm attacks may manipulate up-/downloaded keys no Every uploaded key can be manipulated legally by anyone. (I.e. you attach a new signature to your friend's key and you send back to the key servers.) Moreover anybody can send a totally new key in the name of you. Public key server is like Wikipedia or a piece of paper. And everybody has a pencil. :-) It is the keysigning by other peoples only what ensures integrity of your data stored on SKS servers. Gabor ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] quality of keyservers offering hkps
Kiss Gabor (Bitman) ki...@ssg.ki.iif.hu writes: - mitm attacks may manipulate up-/downloaded keys no Every uploaded key can be manipulated legally by anyone. (I.e. you attach a new signature to your friend's key and you send back to the key servers.) Moreover anybody can send a totally new key in the name of you. Public key server is like Wikipedia or a piece of paper. And everybody has a pencil. :-) You can still block certain pakets from up/downloads (i.e. not providing signature pakets for some key -- kind of a DoS when checking a trust path) Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer pgpBlJJTv23Qa.pgp Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] quality of keyservers offering hkps
You can still block certain pakets from up/downloads (i.e. not providing signature pakets for some key -- kind of a DoS when checking a trust path) We spoke about information leakage and manipulation so far. DoS is a quite other topic. SKS network is quite vulnerable from this point of view. A script kiddie or a TLA could blow up all the servers with 100 million dummy keys within in a day. Gabor ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] quality of keyservers offering hkps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/14/2014 02:12 PM, Christoph Egger wrote: Kiss Gabor (Bitman) ki...@ssg.ki.iif.hu writes: - mitm attacks may manipulate up-/downloaded keys no Every uploaded key can be manipulated legally by anyone. (I.e. you attach a new signature to your friend's key and you send back to the key servers.) Moreover anybody can send a totally new key in the name of you. Public key server is like Wikipedia or a piece of paper. And everybody has a pencil. :-) You can still block certain pakets from up/downloads (i.e. not providing signature pakets for some key -- kind of a DoS when checking a trust path) Or even more importantly, providing a public key where a revocation signature has been removed. - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Nosce te ipsum! Know thyself! -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJT7KpTAAoJEPw7F94F4TagP7kP/AyX57IC3nhGIe7whBdzr5SO Ib2J/ORJbR3wuYmbf6tT/g347W9RXxRXhu37fQi3Iu2iFN3XAhbPZpwIdZ9lo0Q8 bfigpsdrCjLYnW1ll8zqB2tPwexeJbKxzI5RXvM5xXBna2vWAA+oeN6XaPLU9zVU Bw2ST90T6YOP7q5ShPI0aqcuKZx4wbttyAYyvd+IES/hhf4wUe4Zbbqdry4eRXEU j9tvw0kH7Ey7NO/SAM1IGTqXMxpMZZQ+ZMIL1QPK8UtvXdI0dKId4U2mLjHdbv4g xFSfvtRl/7T1pggDdgB1abCLAwqlup7q72QFYhp8Fq5gM3nYIuzRmRrFZkTyRw+m RZDYUouhSM/qPMwBLFRjEwiWXXjua/gJWBmXLmmsshFSKxftiB5X2J3MjdFaJfmq 6RQ+AHkndwxP47/KyQ2vUVhVO5f1x5Ctjg7ASQLxhdvGWLnGeGEANXEStPBLXBEj t5QgDNmeJL8/uCnpr7iqlcsPpTsYBN4Ivx0PV0HRvYpuuIfTKQiphruWF5+1Teog IOqH3RKOMbkU5r4Pj/DsWbg4DGTuxV9KkyDv9IZtqoiegcaB9gcLsYCHRjh8q1gt SCosH5AmCjGo0GRI4VjRt5wHu28VtJ2jSQD9AtncgBEBQgTT9lwIdfExe+1xsZ8m +f1oVKBMBXRmFbYS6QPf =nzIX -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] quality of keyservers offering hkps
On 8/14/2014 2:23 PM, Kristian Fiskerstrand wrote: On 08/14/2014 02:12 PM, Christoph Egger wrote: Kiss Gabor (Bitman) ki...@ssg.ki.iif.hu writes: - mitm attacks may manipulate up-/downloaded keys no Every uploaded key can be manipulated legally by anyone. (I.e. you attach a new signature to your friend's key and you send back to the key servers.) Moreover anybody can send a totally new key in the name of you. Public key server is like Wikipedia or a piece of paper. And everybody has a pencil. :-) You can still block certain pakets from up/downloads (i.e. not providing signature pakets for some key -- kind of a DoS when checking a trust path) Or even more importantly, providing a public key where a revocation signature has been removed. Is this possible? My (albeit limited) understanding is that SKS is an append-only system, and that it is not possible to remove key packets that are already on the servers. Wouldn't a bad guy: a. Need the private key to edit self-signed elements, like revocation signatures? b. Be unable to remove the revocation signature, as SKS servers are append-only? Cheers! -Pete 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] quality of keyservers offering hkps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/14/2014 04:04 PM, Pete Stephenson wrote: On 8/14/2014 2:23 PM, Kristian Fiskerstrand wrote: On 08/14/2014 02:12 PM, Christoph Egger wrote: Kiss Gabor (Bitman) ki...@ssg.ki.iif.hu writes: - mitm attacks may manipulate up-/downloaded keys no Every uploaded key can be manipulated legally by anyone. (I.e. you attach a new signature to your friend's key and you send back to the key servers.) Moreover anybody can send a totally new key in the name of you. Public key server is like Wikipedia or a piece of paper. And everybody has a pencil. :-) You can still block certain pakets from up/downloads (i.e. not providing signature pakets for some key -- kind of a DoS when checking a trust path) Or even more importantly, providing a public key where a revocation signature has been removed. Is this possible? Certainly My (albeit limited) understanding is that SKS is an append-only system, and that it is not possible to remove key packets that are already on the servers. Wouldn't a bad guy: a. Need the private key to edit self-signed elements, like revocation signatures? No, you can drop the full signature or just use a copy of the key from before reovcation was appended. b. Be unable to remove the revocation signature, as SKS servers are append-only? Not in a MITM scenario where you don't really talk with SKS in the first place, hence a very good reason for HKPS in the first place. - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Timendi causa est nescire The cause of fear is ignorance -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJT7MJPAAoJEPw7F94F4TagfUgP/jCCNLaGvdk+OUk9x6P9rCXL HF3S69oKshq2ptalsyUI+3yEOvRuM40q7Syd0i7r9kl3irrPAmKXOfIt+JAaLTbS yYYaUiMJXyUctifdj0vLAj48Us/6GET7jOeuflD/9lB8MFR+iIKbdj/wIJEkbfXd +PFAdozfE8kJ6ziGnXDZ6xp1TPDPKiOZ/FVpKyKZ9CJj+KqYHHPFKgt5L5ynEVcj 5vFdtdI2jTkYQ2vDX6GsM1ukhxnyhtxLDPf2L4LcZFgK/o6/ioLq/Qss2KDyC99Q BF+jiRtRFCJ4exnaEKPzzDW/rdINX5NTUoM+OXZPVi1wP0x54TLPqKL1aso8jwHN y1dSgmyVbS0SXfQAM88ZWO6vmgBEPdchNezb9Fqsvs7n9k9X7/RwpeezJomPXHrB 58ZzD2g8+iJluof6SWiKtH4lNMoagPoSWzlsNNvod4hzt9aDWdl3GVl0kPxqXTXw MUB0iZSVgLaGYLX7rgj8cNyKx+odMfEw/H0v1zaUUplshGQZ/HQwRkl+qqR1hXr/ 9+zWAlZm/KnQEy5Zq3USZqYRARK0dJk9RbnjnJu3C46UJ4J7hfRB7u6tKEXSPtuY MGoVkGLms16bxTsfaoEkNgUrvMaI/TL625DWJdknBgtLFg2uT32vNQMFBmFV8Ztb Ux3SsCGuYLmp2qrKCF5v =+ktI -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] quality of keyservers offering hkps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/14/2014 04:36 PM, Pete Stephenson wrote: On 8/14/2014 4:06 PM, Kristian Fiskerstrand wrote: On 08/14/2014 04:04 PM, Pete Stephenson wrote: My (albeit limited) understanding is that SKS is an append-only system, and that it is not possible to remove key packets that are already on the servers. Wouldn't a bad guy: a. Need the private key to edit self-signed elements, like revocation signatures? No, you can drop the full signature or just use a copy of the key from before reovcation was appended. b. Be unable to remove the revocation signature, as SKS servers are append-only? Not in a MITM scenario where you don't really talk with SKS in the first place, hence a very good reason for HKPS in the first place. [re-sending to list, as I inadvertently sent this response directly to Kristian] Ok. Just for clarity, these attacks are only possible in a MITM scenario, correct? Am I correct in my understanding that the bad guy could only do the packet stripping if they were MITMing the client and presented the user with the desired key sans the revocation signature? That is, the bad guy can't upload the key sans revocation signature to the actual pool, since the pool is append-only and so the revocation signature would not be removed from the pool. Affirmative. Or DoSing the client so that no request for update of the key containing the revocation certificate is in place. Or the user's operational security parameters are insufficient at updating certs regularly. - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Fabricando fit faber Practice makes perfect -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJT7PAcAAoJEPw7F94F4Tag+EoP/jz5V0gBQ6njInm7k7mvL8CJ 2veLIqoApZoq5bihoMRcsx/4zDjogRUVHf+MUhEHpmCN4QEmFcUurLxh3VTK1yYQ eJmsL56K1+6q83AxX4lfjX2hVpvfv1VdrF35dUwEBZF3vK3k8UTPtYD2XG94Qpow w93y9OBNtN9jgROuGBrWJki/Wi4dwfpVAxpPKclARZC/c4y8FZw9txiGAV4xwt18 Ckf3iEL7aKdbcWfe8HU2c1Ur9l1tMTNiSC7ZPmHHCTfjur2oM+tsx1WpYuLT38Ax CI7w4Qt1Vp6wSjEQB6Q+uE70fVCT08rAEE1M7S2cIjsW+eoJzrOliG1i+JI9rsLt yMzJVhjBDxJJCfU63aWa03IbaULQPc6zGG/haYUPzqmgTG+IBkEu8i5UffAIL3JI sFXE4rMBGin7EIra7fdjgsrbt8suVqlOtm4SNRhvk8Yo9JlgogB/hLG+u//jZNZW szFt9k/yrU/XfKP/tqSMHQmzNjCzZVzezkYZK6rz8rez1a22hKKudtmbQXylGkgM /MbO+8UVUCnMA4petIlDVIPJ0viveIpduro5IVqCwCyFuOijN7gHyebqy/LjfuCl G6SDcbjKBnBqqLpww4uyGTz8i2t+UakIy7vgEQRr1O8p1FJLNZ3zUBI4vA3HBd2q EG66xQexKq6YjGZZUJdh =lj88 -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] quality of keyservers offering hkps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-08-14 at 13:30 +0200, Matthias Schreiber wrote: On 14. August 2014 05:31:40 MESZ, Phil Pennock sks-devel-p...@spodhuis.org wrote: What is the threat model which you are trying to protect against? As the public keys themselves are of cause nothing which needs to be secured, I see these two possible aspects: - meta data like 'who up-/downloaded which keys' could be revealed - mitm attacks may manipulate up-/downloaded keys Or am I thinking in the wrong direction? No, but it's important to understand something about keyservers. The data which they hold is unauthenticated, and anyone can run a keyserver. For context before I continue: I run an HKPS keyserver, was one of the first to do so, and have worked with Kristian on the setup and with the GnuPG developers on establishing which identity should be verified. So I support HKPS as a feature and I _cautiously_ support it for a public pool, but I worry about the false sense of security it engenders. If an acronym agency is not running a public keyserver, under an innocuous name, then they're slipping. It's the easiest way to automatically get a feed of every PGP public key created and uploaded for general use. Great ingress, can check for names and pseudonyms immediately and schedule some keys for priority factoring. If an acronym agency is not running a set of public keyservers, logging all client queries, to get a statistical sample of communicant flows, then they're slipping. Kristian is not in a position to filter the keyservers in his pool by the affiliation, public or hidden, of the keyserver operators. Selection is entirely based on technical merit, as assessed by a few simple heuristics. It is likely that at _least_ one of the currently participating members works for an acronym agency. Frankly, while it would be nice if no keyserver operators did so, if you have no connection or affiliation with the operator of the keyserver you use, then it's naive to _demand_ that the operators conform to your desired profiles and requirements. Thus, if you run an organisation where you care about traffic analysis and communicant pairing, then you should run your own PGP keyserver and get people in your organisation to exclusively use that keyserver. If you have the resources to run a keyserver, bias towards only using your own. The _default_ keyservers are a selection of publicly available keyservers where *NO* warranties are made about who is running them. So, to your two points, let's first look at when using the general pool and then when using a particular keyserver * meta data revelation: far easier to perform, and harder to detect, to just run an SKS keyserver publicly, under a pseudonym used by an agency employee. Run up HTTPS with a high quality cert, make sure you pass every quality assessment for the cert and HTTPS TLS negotiation. Provide a great service. Locks out analysis by people at other (foreign, or just competing) agency and still gives you full logs. MITM is usually detectable, even if just after the fact (oops, where did that BGP announcement come from?). Running quality servers which people appreciate, and _choose_ to use, is absolutely legal, requires no wiretapping, no warrants, and lets you keep the usual, routine logs. Everything is above board, legally, in just about every jurisdiction. It's a no-brainer. * MITM attacks: similarly, no need, just write logic into the keyserver, or between the front-end proxy and the server, to filter results for keys of interest. Do it behind the HTTPS, so that you don't need to tamper with the quality and are not detectable, and do it on your own systems, when queried, so that no laws are broken and no warrants required. So, for the general pool, I think revisiting the threat model may be of use. Having HKPS available, and of good quality, is useful for those of us who do not work for an acronym agency, to help protect end-users against attack when their client resolves to one of our servers. It keeps us from becoming complicit. It increases the chances of tampering becoming evident. It's chicken soup for the soul. It's good to have this, for the pool, to increase the difficulty of attack against queries going to non-agency servers. But for the end-user, using HKPS with the public pools is like playing Russian Roulette: sooner or later, the chamber is loaded with a bullet and you lose. HKPS available and verifiable protects against regimes outside of the nation where the keyserver is (and their spying allegiance nations). So for folks going into the Middle East, using a keyserver pool constrained to the USA is probably a good call, as long as you also use a validating DNS resolver (with a trusted root key set), so that DNS attacks can't redirect you to a member of another pool in a nation friendly to the local regime of concern. Kristian has set
[Sks-devel] quality of keyservers offering hkps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, after reading the posts related to protocols and cipher suites started by Pete last week [1] I wanted to check the settings of the keyservers in the hkps pool using the SSL Server Test from Qualys [2] in order to evaluate the quality of the applied settings. Ignoring the untrusted certificate warnings, these are the compact results of the test using Qualys' grade system: A- or better23 servers B 2 servers C 1 server F 9 servers So, from the total of 35 servers (of which 3 aren't currently in the hkps pool due to missing keys) basically 2/3 show secure and robust settings. 5 servers (grades B and C as well as 2 from the F group) have lower standards on different levels by either not supporting modern protocols like TLS 1.1 1.2 and/or allowing weak or even insecure cipher suites. Here, an improvement would be to apply a more secure configuration [3] as e.g. already suggested in the aforementioned thread [1]. In case of the last remaining 7 servers (= every 5th server) the test showed an exploit opportunity related to CVE-2014-0224 [4], which can be eliminated by simply updating the OpenSSL package on these systems. As I'm not that much deep in the topic I'm not sure about the impact of this issue on the security of hkps connections. Perhaps anyone can give an advise here. Could this be a threat and should be also checked before including servers to the hkps pool? In general, is this kind of test useful to find possibly weak servers in the mentioned pool? Should it be done on a regular basis perhaps or is of low relevance? Greetings, Matthias - - [1] https://lists.nongnu.org/archive/html/sks-devel/2014-08/msg00019.html [2] https://www.ssllabs.com/ssltest/ [3] https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy [4] https://community.qualys.com/blogs/securitylabs/2014/06/13/ssl-pulse-49-vulnerable-to-cve-2014-0224-14-exploitable -BEGIN PGP SIGNATURE- Version: GnuPG v1 iF4EAREIAAYFAlPr58QACgkQk8eZk3b5umD9gAD+Ndc4xddShiBquTZ+7JgYTBy3 IvsXKUkFmeYUaelwQHMA/3J64JjkOhAGOBOmaitg7lMt/kVQKxk5RYOIY5Bm1R0M =78VF -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] quality of keyservers offering hkps
On 2014-08-14 at 00:33 +0200, Matthias Schreiber wrote: after reading the posts related to protocols and cipher suites started by Pete last week [1] I wanted to check the settings of the keyservers in the hkps pool using the SSL Server Test from Qualys [2] in order to evaluate the quality of the applied settings. What is the threat model which you are trying to protect against? -Phil ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] quality of keyservers offering hkps
In case of the last remaining 7 servers (= every 5th server) the test showed an exploit opportunity related to CVE-2014-0224 [4], which can be eliminated by simply updating the OpenSSL package on these systems. As I'm not that much deep in the topic I'm not sure about the impact of this issue on the security of hkps connections. Perhaps anyone can _Every_ SSL encrypted traffic of these servers can be decoded by an eavesdropper after silently eliciting the secret key. give an advise here. Could this be a threat and should be also checked before including servers to the hkps pool? Definitely yes. Gabor ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
