Re: Client certs
On 25/09/14 17:53, Robin Alden wrote: I can send out a million client certificates for negligible cost. Good point. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 25/09/14 22:33, Matt Palmer wrote: * Client certs can be invisibly stolen if a machine is compromised Well, the cert is quasi-public information, so it doesn't matter if they get stolen, invisibly or otherwise. The private key, on the other hand... grin But at any rate, just stick the key/cert in a USB HSM. Problem solved. Right. That does make it better from this perspective, but a) there is a risk (depending on design) that key ops can be done without your knowledge as long as the key is plugged in, and b) surely this just adds to the system any disadvantages a widget might have? But, yes, many other good points. I am being enlightened :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
Gervase Markham schrieb: A question which occurred to me, and I thought I'd put before an audience of the wise: * What advantages, if any, do client certs have over number-sequence widgets such as e.g. the HSBC Secure Key, used with SSL? http://www.hsbc.co.uk/1/2/customer-support/online-banking-security/secure-key It seems like they have numerous disadvantages (some subjective): * Client certs can be invisibly stolen if a machine is compromised * Client certs are harder to manage and reason about for an average person * Client certs generally expire and need replacing, with no warning * Client certs are either single-machine, or need a probably-complex copying process What are the advantages? With client certs you can build very nice infrastructures which deliver: * Single identity across multiple services without the need to integrate all services into an OTP structure. * Deployable with services from different organisations. * Some kind of single sign on for all services on one host (because the browser remembers the latest selected certificate for a given host). * Issuance under strict policies. This helps organisations to enforce security standards and accountability. * Relatively easy to implement on the server side. * Requires https (no possibility to accidentially open a non-https-login-page). * Possibility for central revocation management on the server side. * Possibility to integrate mail encryption and document signatures. Jürgen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Security Blog about SHA-1
Le jeudi 25 septembre 2014 22:54:07 UTC+2, Hubert Kario a écrit : - Original Message - From: Chris Palmer p@google.com [...] SHA-1 signature algorithms are not per se bad right now; what's bad is certificate chains using SHA-1 that will/would be valid too far in the future. Between now and 1 Jan 2016, and between then and 1 Jan 2017, there is plenty of time to get a new certificate, signed with a SHA-256-based signature function. It's debatable if the 2016 date is good. NIST doesn't agree According to NIST SP800-57 Part 1, doing a signature with SHA-1 is deprecated since 2011 and disallowed since 2014. We're not too far from NIST. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On Fri, September 26, 2014 2:39 am, Erwann Abalea wrote: Le jeudi 25 septembre 2014 14:29:04 UTC+2, Gervase Markham a écrit : A question which occurred to me, and I thought I'd put before an audience of the wise: * What advantages, if any, do client certs have over number-sequence widgets such as e.g. the HSBC Secure Key, used with SSL? That needs to be thoroughly checked, but I think it also renders MitM impossible on TLS. Not impossible. Difficult. In 'normal', server-authenticated TLS, the client has assurances that the peer (as identified by the certificate) is the same as the peer during the handshake. The server has no such assurances. When performing client auth, the server has assurances that the client (as identified by the client certificate) is the same as the peer doing the handshake. That's because the client cert (and signature exchange) become part of the channel's cryptographic identity. To a degree, Channel ID ( http://tools.ietf.org/html/draft-balfanz-tls-channelid-01 ) does this too, as does any protocol that enforces tls-unique channel bindings ( http://tools.ietf.org/html/rfc5929 ) as part of a secondary authentication exchange (Kerberos, NTLM w/ token bindings, etc) However, this is not in and of itself an intrinsic guarantee against MITM. Any MITM that can obtain the client key can perform the same impersonation. This may be because the user is compelled to yield their certificate/key to the MITM (Yes, this really does exist and happens), or because of malware ( http://www.computerworld.com/article/2493077/malware-vulnerabilities/proof-of-concept-malware-can-share-usb-smart-card-readers-with-attackers-ove.html or http://www.alienvault.com/open-threat-exchange/blog/sykipot-variant-hijacks-dod-and-windows-smart-cards ) that can perform signing operations without user knowledge. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On Fri, September 26, 2014 2:06 am, Gervase Markham wrote: On 25/09/14 22:33, Matt Palmer wrote: * Client certs can be invisibly stolen if a machine is compromised Well, the cert is quasi-public information, so it doesn't matter if they get stolen, invisibly or otherwise. The private key, on the other hand... grin But at any rate, just stick the key/cert in a USB HSM. Problem solved. Right. That does make it better from this perspective, but a) there is a risk (depending on design) that key ops can be done without your knowledge as long as the key is plugged in, and b) surely this just adds to the system any disadvantages a widget might have? But, yes, many other good points. I am being enlightened :-) Gerv Smart cards are not, in and of themselves, guarantees of mitigation, particularly against malware. As you note, it depends on design. That said, for systems where it matter, things like Secure Pin Entry (Part 10 of http://www.pcscworkgroup.com/specifications/overview.php ) exist and are used in real products ( http://www.hidglobal.com/products/readers/omnikey/3821 ), although NSS does not support the CKF_PROTECTED_AUTHENTICATION_PATH attribute with respect to C_InitToken. And, you know, the UX is absolutely horrible for these SPEs (Hey 1990s, we LOVE blocking APIs for things that are theoretically multithreaded but in practice single-threaded), so it's more academic than anything. However, what I'm surprised to see no one having pointed out is that all of these 2FA systems - including the one you mentioned - is phishing. This is where 2FA systems like FIDO come in to play, because the cryptographic assertion is bound to the channel (like TLS client certificates), and thus cannot be phished (as the assertion is no longer a bearer token, as it is with those PIN systems). You can see more at https://fidoalliance.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On Thu, September 25, 2014 11:18 pm, Henri Sivonen wrote: On Fri, Sep 26, 2014 at 12:33 AM, Matt Palmer mpal...@hezmatt.org wrote: On Thu, Sep 25, 2014 at 01:29:04PM +0100, Gervase Markham wrote: A question which occurred to me, and I thought I'd put before an audience of the wise: * What advantages, if any, do client certs have over number-sequence widgets such as e.g. the HSBC Secure Key, used with SSL? http://www.hsbc.co.uk/1/2/customer-support/online-banking-security/secure-key I can see one advantage: * A client cert that's *not* on an external token is just bits on your device and doesn't add a physical thing you have to carry around. It seems like they have numerous disadvantages (some subjective): * Client certs can be invisibly stolen if a machine is compromised Well, the cert is quasi-public information, so it doesn't matter if they get stolen, invisibly or otherwise. The private key, on the other hand... grin But at any rate, just stick the key/cert in a USB HSM. Problem solved. On a more serious note, putting the private key on a USB device or a smart card isn't a realistic solution. It's not even a now you have two problems kind of solution. If you do that, you have way more than two problems. I live in a country with a failed but still zombied initiative to issue client certs on smart cards to all citizens (or maybe residents; I'm not quite sure; I believe the issuance never reached more than 10% of the population anyway because for many people it makes more sense to have a driver's license for domestic use and to have a passport for global use than to have an ID card for EU use [the certs are on ID cards] and only a handful of people ever had hardware and drivers to use the issued certs) and I've worked in a project that was supposed to use these things for user login. The initiative is an expensive boondoggle that's a big waste of tax money. With desktops, there's the problem of having to obtain a card slot [not a problem with a direct USB device you mention], driver problems and usability problems. With non-desktops, there's the problem of not even theoretically having suitable hardware interfaces. Sure, it would be fair to say that the initiative in Finland was just badly executed: It occured to the government CA to file https://bugzilla.mozilla.org/show_bug.cgi?id=463989 only in 2008, even though the lack of root program inclusion was a major usability problem already in 2003 when I worked in a project that was supposed to use this stuff. And they've failed to follow up on that bug for 6 years now! Even if you point to e.g. Estonia for better execution, observation at a point in time is not enough. Compare with the South Korea ActiveX bank crypto, which might have looked like a good idea to some at some earlier point in time. Also, committing a large population to particular hardware interfaces for the token inherently risks obstructing progress. Paper-based one-time passcodes FTW! (That's how identifying people for government Web sites actually works in Finland--with banks acting as IdPs.) Now, you may say that tokens work on the scale of your company and of course they don't scale on the level of a country, but Gerv's case of a large bank in the UK is on the same level of scale as the population of a less populous European country. * Client certs are harder to manage and reason about for an average person Hmm... I think this one could go either way. If you get a cert/key on a USB stick, is that massively different from the consumer's perspective from getting a Yubikey or number-sequence token? A USB HSM and a Yubikey are massively different from each other, because the latter acts as a USB keyboard and, therefore, doesn't require special drivers or any sort of infrastructure work to integrate with a browser. * Client certs generally expire and need replacing, with no warning As has been noted elsewhere, that's a UI problem, and number-sequence tokens aren't immune either. The UI problems with client certs are on a completely different level of problem than the UI problems with having to type four to six digits that you look up from a paper sheet or a small hardware widget. (Paper sheets FTW, BTW. More eco-friendly than hardware widgets. Don't break when bent or exposed to cold weather. Paper is easier to clone, yes, but that's not enough of a Real Problem to deserve solving. Usually, the problem isn't cloning but losing the original paper/widget.) * Client certs are either single-machine, or need a probably-complex copying process Or a USB HSM. (I'm starting to see a pattern here) How do you plug that USB HSM into a tablet with no USB host capability? (I'm saying tablet rather than phone so that you can't go Well, with mobile devices, you just put the private key on the SIM.) All in
Re: Client certs
Le vendredi 26 septembre 2014 11:50:32 UTC+2, Ryan Sleevi a écrit : On Fri, September 26, 2014 2:39 am, Erwann Abalea wrote: Le jeudi 25 septembre 2014 14:29:04 UTC+2, Gervase Markham a écrit : A question which occurred to me, and I thought I'd put before an audience of the wise: * What advantages, if any, do client certs have over number-sequence widgets such as e.g. the HSBC Secure Key, used with SSL? That needs to be thoroughly checked, but I think it also renders MitM impossible on TLS. Not impossible. Difficult. Right. Server-only MitM impossible, in the sense of attacking a CA ;) It's clear that if an attacker can get the client's private key or have the client perform crypto operations on its behalf, the client is doomed. In general, if some hostile code gets executed on the client's host, it's finished. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: HSTS
- Original Message - From: fhw...@gmail.com To: dev-security-policy@lists.mozilla.org Sent: Thursday, 25 September, 2014 7:39:33 PM Subject: Re: HSTS I'll address the DoS thing momentarily but first I'm curious if there's any data out there on how widely deployed HSTS currently is About 2% of sites advertise HSTS, see https://www.trustworthyinternet.org/ssl-pulse/ -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: KIR S.A. Root Inclusion Request
Answers for Matt Palmer questions: I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). KIR's answer: To get a SSL certificate client has to provide(CSP s.3.2): -agreement, -order, -document confirming rights to the domain . Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4): 1. verification of agreement (we check if the company exist, who sign agreement, if it is entitled representative), 2. verification of order (we check who sign order, if it is entitled representative, if the data given in order are correct), 3. verification whether the client has granted the right to the domain (we check who is an owner of the domain); 4. verification whether the client controls the domain (we ask to place data indicated by KIR on server); 5. identity of person authorised to represent client (we meet face to face with that person). If it is still unclear in CSP we can make it more clarified. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. That is not clear from the CPS. KIR's answer: When issuing test certificate, we check the points 1 -4 listed above, and the validy of the renewed certifcate. Best regards Przemyslaw Rawa Od: Matt Palmer mpal...@hezmatt.org Do: dev-security-policy@lists.mozilla.org, Data: 2014-09-25 22:38 Temat: Re: KIR S.A. Root Inclusion Request Wysłane przez: dev-security-policy dev-security-policy-bounces+certificates=kir.com...@lists.mozilla.org On Thu, Sep 25, 2014 at 03:06:59PM +0200, Certificates wrote: Answers for Matt Palmer questions: On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircertifica...@gmail.com wrote: As you can see above in the same point of CPS: To receive a certificate it is necessary for the subscriber who is a natural person or an authorised representative of the recipient of certification services to present: 1) an identification card (or its photocopy depending on the type of certificate); 2) documents confirming rights to the domain (optionally, relative to the certificate type); 3) a file with the certificate request (if the pair of keys is generated individually by the subscriber). In case of test certificates according our CPS we can skip point 1 from the above list. It means that we do not force subscriber to visit our RA and show his identification card, as we do in case of another kinds of certificates. But still all other things like agreement, order and documents confirming rights to the domain are verified carefully. Rights to the domain is indicated there as being optional, and I can't find any indication in the CPS of which certificate types will be domain-validated. Also, the only place I've found a description of your domain validation practices is at the bottom of CPS s3.2.2, which only mentions having information placed on a server. My reading of the e-mail communication option is for purposes other than domain validation. Can you confirm that is the case? CSP s3.2 concerns all type of certificates. Optional, relevant to the certificate type means that we don't ask for domain validation for e.g. the standard certificate. We do domain validation for all SSL certifcates. More details about process of validation during issuing certificates of all types you can find in CP. I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. That is not clear from the CPS. We reserve itself the right to downtime our OCSP, but it doesn't mean that we do it every week during normal working hours. What is acceptable level of service for you? We can adjust our technical downtime for OCSP. 100%. OCSP is a fundamental service for a publically-trusted CA to provide. Given
RE: KIR S.A. Root Inclusion Request
I think you should clarify what constitutes a document confirming rights to the domain. Is this authorization from the registrar or registrant? Who provides the document? -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Certificates Sent: Friday, September 26, 2014 6:42 AM To: dev-security-policy@lists.mozilla.org Subject: Re: KIR S.A. Root Inclusion Request Answers for Matt Palmer questions: I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). KIR's answer: To get a SSL certificate client has to provide(CSP s.3.2): -agreement, -order, -document confirming rights to the domain . Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4): 1. verification of agreement (we check if the company exist, who sign agreement, if it is entitled representative), 2. verification of order (we check who sign order, if it is entitled representative, if the data given in order are correct), 3. verification whether the client has granted the right to the domain (we check who is an owner of the domain); 4. verification whether the client controls the domain (we ask to place data indicated by KIR on server); 5. identity of person authorised to represent client (we meet face to face with that person). If it is still unclear in CSP we can make it more clarified. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. That is not clear from the CPS. KIR's answer: When issuing test certificate, we check the points 1 -4 listed above, and the validy of the renewed certifcate. Best regards Przemyslaw Rawa Od: Matt Palmer mpal...@hezmatt.org Do: dev-security-policy@lists.mozilla.org, Data: 2014-09-25 22:38 Temat: Re: KIR S.A. Root Inclusion Request Wysłane przez: dev-security-policy dev-security-policy-bounces+certificates=kir.com...@lists.mozilla.org On Thu, Sep 25, 2014 at 03:06:59PM +0200, Certificates wrote: Answers for Matt Palmer questions: On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircertifica...@gmail.com wrote: As you can see above in the same point of CPS: To receive a certificate it is necessary for the subscriber who is a natural person or an authorised representative of the recipient of certification services to present: 1) an identification card (or its photocopy depending on the type of certificate); 2) documents confirming rights to the domain (optionally, relative to the certificate type); 3) a file with the certificate request (if the pair of keys is generated individually by the subscriber). In case of test certificates according our CPS we can skip point 1 from the above list. It means that we do not force subscriber to visit our RA and show his identification card, as we do in case of another kinds of certificates. But still all other things like agreement, order and documents confirming rights to the domain are verified carefully. Rights to the domain is indicated there as being optional, and I can't find any indication in the CPS of which certificate types will be domain-validated. Also, the only place I've found a description of your domain validation practices is at the bottom of CPS s3.2.2, which only mentions having information placed on a server. My reading of the e-mail communication option is for purposes other than domain validation. Can you confirm that is the case? CSP s3.2 concerns all type of certificates. Optional, relevant to the certificate type means that we don't ask for domain validation for e.g. the standard certificate. We do domain validation for all SSL certifcates. More details about process of validation during issuing certificates of all types you can find in CP. I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not
Re: KIR S.A. Root Inclusion Request
On Fri, Sep 26, 2014 at 02:42:05PM +0200, Certificates wrote: I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). KIR's answer: To get a SSL certificate client has to provide(CSP s.3.2): That's presumably supposed to be CPS, not CSP (I noted that error frequently throughout the documents themselves; you might want to get that corrected). -agreement, -order, -document confirming rights to the domain . What valid forms can this document take? What steps are taken to verify or validate that information? Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4): 1. verification of agreement (we check if the company exist, who sign agreement, if it is entitled representative), 2. verification of order (we check who sign order, if it is entitled representative, if the data given in order are correct), 3. verification whether the client has granted the right to the domain (we check who is an owner of the domain); How is that ownership check performed? 4. verification whether the client controls the domain (we ask to place data indicated by KIR on server); 5. identity of person authorised to represent client (we meet face to face with that person). If it is still unclear in CSP we can make it more clarified. That would be appreciated. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. That is not clear from the CPS. KIR's answer: When issuing test certificate, we check the points 1 -4 listed above, and the validy of the renewed certifcate. That would be a good clarification to place in the CPS itself. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
