Re: Indicators for high-security features
On Mon, Sep 22, 2014 at 10:52 PM, Chris Palmer pal...@google.com wrote: Quite so. My point in this thread was: If we are going to change the definition of what an origin is, the most security-meaningful change would be to tie cryptographic identities to origins, rather than anything else; and, OMG that is incredibly hard to do. So, maybe we should just leave origins alone. What if we offered some new type of certificate. And if you downgraded from that certificate to a normal certificate, you would have some guarantees about cookie and localStorage data. And perhaps it automatically gives you HSTS. Or is that too problematic to roll out? -- https://annevankesteren.nl/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Indicators for high-security features
- Original Message - From: s...@gmx.ch To: dev-security-policy@lists.mozilla.org Sent: Monday, 22 September, 2014 9:28:39 PM Subject: Re: Indicators for high-security features Am 22.09.2014 um 14:56 schrieb Henri Sivonen: On Wed, Sep 17, 2014 at 6:20 PM, Richard Barnes rbar...@mozilla.com wrote: -- Use of ciphersuites with forward secrecy Yes, but I think it makes sense to go further with ciphersuites. At minimum, RC4 should not qualify, but given how easy it is to enable AES-GCM if you can enable TLS 1.2 per the earlier point, why not require an AEAD suite (i.e. AES-GCM or an upcoming ChaCha20 suite) and set aside all perceived or actual CBC problems while at it? I think 3DES should not qualify, too. It's just the less worse alternative of RC4 to support IE 8. If we accept sha-1 signed certs, then 3DES is less of a concern. If we clean up everything and require 128 bit security through and through for high-sec indication, then yes, 3DES needs to get cut. -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mixed content (was: Indicators for high-security features)
On Tue, Sep 23, 2014 at 8:08 PM, fhw...@gmail.com wrote: I'm sure blocking such http requests would break some sites but has anyone performed research or analysis into how big the problem is? Is there a user option to force them to be blocked? Download Firefox Nightly, browse the web, and look for a broken lock. As far as I can tell a bunch of sites would break, though the breakage is probably not severe. E.g. mail.google.com, newsblur.com, indiewebcamp.com. I doubt there are holes by the way, but if you find any let us know. -- https://annevankesteren.nl/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Indicators for high-security features
On Tue, Sep 23, 2014 at 11:08 AM, fhw...@gmail.com wrote: So what is the reason to use HSTS over a server initiated redirect? Seems to me the latter would provide greater security whereas the former is easy to bypass. You have it backwards. http://www.thoughtcrime.org/software/sslstrip/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Indicators for high-security features
On Tue, Sep 23, 2014 at 01:08:13PM -0500, fhw...@gmail.com wrote: So what is the reason to use HSTS over a server initiated redirect? Seems to me the latter would provide greater security whereas the former is easy to bypass. On the contrary, HSTS is much harder to bypass, because the browser remembers the HSTS setting for an extended period of time. While first use is still vulnerable to a downgrade attack under HSTS, it's only *one* use, whereas the browser is vulnerable to redirect filtering on *every* use. If an attacker has enough access to the network to be able to strip the HSTS header, they also have enough access to be able to block the server-initiated redirect to HTTPS. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
KIR S.A. Root Inclusion Request
Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the “SZAFIR ROOT CA” root certificate and enable all three trust bits. KIR S.A. is a private corporation in Poland which currently mainly issues qualified certificates for general public and plans to issue non-qualified certificates (e.g. SSL certificates). KIR S.A. is an automated clearing house in Poland and its core business is clearings, and has built numerous business relationships within banking sector. Therefore, KIR S.A. is aiming to expand its sales in services such as SSL and VPN certificates. KIR S.A. has another line of products called PayByNet, and has created a vast network of relationships within online stores that KIR S.A. can leverage to create customer base for trusted non-qualified certificates. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=817994 And in the pending certificates list: http://www.mozilla.org/projects/security/certs/pending/ Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8441701 Noteworthy points: * The primary documents, the CP and CPS, are provided in both English and Polish. Document Repository: http://elektronicznypodpis.pl/en/information/documents-and-agreements CPS: http://www.elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf CP: http://elektronicznypodpis.pl/files/doc/certification_policy.pdf * CA Hierarchy: There is currently one internally-operated subordinate-CA which issues 6 types of end-user certificates: - Standard certificate - For protection of information sent electronically, using mainly e-mail, for authorizing access to systems, customer authentication in SSL connections. It allows signing and encrypting data in an electronic form and authenticating subscribers. - Code signing certificate - VPN certificate - SSL certificate - Test certificate - For testing co-operation of the certificate with solutions used or developed by a recipient of certification services or a subscriber. - ELIXIR certificate - For protecting information sending within ELIXIR and EuroELIXIR systems. This kind of certificates are issued only for Participants of ELIXIR and EuroELIXIR systems. * The request is to enable all three trust bits. ** CPS section 3.2, Initial Identity Validation: Depending on the type of certificate the procedure of certificate issuance may be different and is relative to a specific certification policy. 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). KIR S.A. may expect presentation of other documents, in case entering data other than the subscriber's first name and surname and the PESEL or NIP number into the certificate is requested. ** CPS section 3.2.2: Identification and authentication of entities other than a natural person is the case when data of such entity is included in the data for the certificate for the issuance of which it applies to KIR S.A., or data included in the certificate contains information about such entity, e.g. the name of the Internet domain. Depending on the type of certificate, identification shall be performed on the basis of documents sent by the recipient of certification services or data disclosed in the Agreement and in the order. The manner of confirming such data depends on the type of certificate. For this purpose KIR S.A. may request sending additional documents, check the data of the recipient of certification services in commonly accessible registers and services, obtain a card of signatures of persons authorised to represent the recipient of certification services. Issuance of the certificate may also require a personal meeting of a person authorised to represent a specific entity with an authorised representative of KIR S.A. Wishing to authenticate other data recording which in the certificate a specific entity requests, KIR S.A. may ask for: 1) placing data indicated by KIR S.A. in a target server by the subscriber acting to order of a legal person, which is to verify the rights to the Internet domain; 2) providing answer to a query sent by KIR S.A. to an e-mail address placing of which in the certificate a legal person demands. ** CPS section 3.2.5. Checking Rights to Receive Certificate The recipient of certification services signs an agreement with KIR S.A. for the provision of certification services. Authorised representatives also sign data for the certificate included in the order for a specific subscriber. Thus, pursuant to an agreement they confirm the subscriber's
Re: KIR S.A. Root Inclusion Request
One thing leaps out at me immediately: these test certificates. They appear to be issued from the same CA as the regular certificates, but s3.2 states, In case of test certificates they may be issued remotely *without the necessity to verify the subscriber's identity. That seems... bad. *Really* bad. I'm also a little concerned about the last sentence of s4.9.9 (dealing with OCSP responders) -- at least, I'm assuming that italics sentence in the header of 4.9.10 isn't supposed to be a header. I don't think that being able to take down your OCSP service for fours hours every week really constitutes an acceptable level of service. - Matt On Tue, Sep 23, 2014 at 05:49:17PM -0700, Kathleen Wilson wrote: Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the “SZAFIR ROOT CA” root certificate and enable all three trust bits. KIR S.A. is a private corporation in Poland which currently mainly issues qualified certificates for general public and plans to issue non-qualified certificates (e.g. SSL certificates). KIR S.A. is an automated clearing house in Poland and its core business is clearings, and has built numerous business relationships within banking sector. Therefore, KIR S.A. is aiming to expand its sales in services such as SSL and VPN certificates. KIR S.A. has another line of products called PayByNet, and has created a vast network of relationships within online stores that KIR S.A. can leverage to create customer base for trusted non-qualified certificates. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=817994 And in the pending certificates list: http://www.mozilla.org/projects/security/certs/pending/ Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8441701 Noteworthy points: * The primary documents, the CP and CPS, are provided in both English and Polish. Document Repository: http://elektronicznypodpis.pl/en/information/documents-and-agreements CPS: http://www.elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf CP: http://elektronicznypodpis.pl/files/doc/certification_policy.pdf * CA Hierarchy: There is currently one internally-operated subordinate-CA which issues 6 types of end-user certificates: - Standard certificate - For protection of information sent electronically, using mainly e-mail, for authorizing access to systems, customer authentication in SSL connections. It allows signing and encrypting data in an electronic form and authenticating subscribers. - Code signing certificate - VPN certificate - SSL certificate - Test certificate - For testing co-operation of the certificate with solutions used or developed by a recipient of certification services or a subscriber. - ELIXIR certificate - For protecting information sending within ELIXIR and EuroELIXIR systems. This kind of certificates are issued only for Participants of ELIXIR and EuroELIXIR systems. * The request is to enable all three trust bits. ** CPS section 3.2, Initial Identity Validation: Depending on the type of certificate the procedure of certificate issuance may be different and is relative to a specific certification policy. 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). KIR S.A. may expect presentation of other documents, in case entering data other than the subscriber's first name and surname and the PESEL or NIP number into the certificate is requested. ** CPS section 3.2.2: Identification and authentication of entities other than a natural person is the case when data of such entity is included in the data for the certificate for the issuance of which it applies to KIR S.A., or data included in the certificate contains information about such entity, e.g. the name of the Internet domain. Depending on the type of certificate, identification shall be performed on the basis of documents sent by the recipient of certification services or data disclosed in the Agreement and in the order. The manner of confirming such data depends on the type of certificate. For this purpose KIR S.A. may request sending additional documents, check the data of the recipient of certification services in commonly accessible registers and services, obtain a card of signatures of persons authorised to represent the recipient of certification services. Issuance of the certificate may also require a personal meeting of a person authorised to represent a specific entity with an authorised representative of KIR S.A. Wishing to
HSTS (was: Indicators for high-security features)
So I read through RFC 6797 and see that some of my concerns are addressed there. Still, I would like to have a better understanding of Mozilla's implementation since there is user agent flexibility that's open to interpretation. One other thing that isn't clear to me is how complete the Mozilla implementation is. Is there more work to do or is it all in there and now we're just waiting for websites to deploy it?The shortcoming of HSTS is on the deployment side, where on the one hand it purports to help web app developers and deployment teams who falter at security and on the other hand gives those same people all-new ways to falter at security. It's your classic bait-and-switch except this time your site could become unusable.For example, how do I pick a suitable max-age? Suppose I mistake the units for days instead of seconds (seriously? seconds?!?) and set the value to 10. What are the practical effects of that? What happens when I use a value of 0x? If my settings mean I've DoS-ed myself, what can I do to the browser to restore service?The most ambitious of web sites and services will be up for the challenge of doing a proper HSTS implementation but the rest...I don't know. Any thoughts on how widely this will be adopted?From: fhw...@gmail.comSent: Tuesday, September 23, 2014 8:10 PMOK, thanks Matt. So the security improvement is because it's a server config plus persistent memory on the client side.What is the thinking in Firefox (assume Thunderbird will be similar?) for handling of all the different cases that arise with it? I'm thinking of how persistent is the HSTS knowledge, can it be cleared, what errors/warnings might appear, will users be allowed to bypass them, and so forth. Original Message From: Matt PalmerSent: Tuesday, September 23, 2014 5:01 PMOn Tue, Sep 23, 2014 at 01:08:13PM -0500, fhw...@gmail.com wrote: So what is the reason to use HSTS over a server initiated redirect? Seems to me the latter would provide greater security whereas the former is easy to bypass.On the contrary, HSTS is much harder to bypass, because the browserremembers the HSTS setting for an extended period of time. While first useis still vulnerable to a downgrade attack under HSTS, it's only *one* use,whereas the browser is vulnerable to redirect filtering on *every* use. Ifan attacker has enough access to the network to be able to strip the HSTSheader, they also have enough access to be able to block theserver-initiated redirect to HTTPS.- Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
