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
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
Re: Indicators for high-security features
OK, 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 Palmer Sent: Tuesday, September 23, 2014 5:01 PM 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 right
Security Blog about SHA-1
I posted a security blog about SHA-1: https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ Kathleen ___ 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
Re: Indicators for high-security features
On Tue, Sep 23, 2014 at 11:08 AM, 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: Mixed content (was: Indicators for high-security features)
- Original Message - > From: "Anne van Kesteren" > To: fhw...@gmail.com > Cc: "Patrick McManus" , > mozilla-dev-security-pol...@lists.mozilla.org > Sent: Tuesday, 23 September, 2014 9:10:32 PM > Subject: Re: Mixed content (was: Indicators for high-security features) > > On Tue, Sep 23, 2014 at 8:08 PM, 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? > > I doubt there are holes by the way, but if you find any let us know. Firefox already had CVEs for jpeg handling, they are not unheard of. -- 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, 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
Mixed content (was: Indicators for high-security features)
I was hoping to learn that images too would get blocked. I'm not sure I can think of all the ways to exploit this hole in security but certainly a browser defect in image handling is one of them.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? I'm also curious how exhaustively the blocking rules get tested. With all the levels of nesting that occur and caching and redirects and live _javascript_ stuff that take place on most every page load, it seems like there certainly could be holes but I'd rather have hard facts. Anyone have data on that? Thank you! From: Patrick McManusSent: Monday, September 22, 2014 7:29 AMwrt http:// images from a https:// origin - the images do load but you get the !-in-a-triangle mixed content icon instead of a lock. ___ 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
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. Original Message From: Henri Sivonen Sent: Monday, September 22, 2014 7:56 AM On Wed, Sep 17, 2014 at 6:20 PM, Richard Barnes wrote: > There are a bunch of security features right now that I think we all agree > improve security over and above just using HTTPS: > -- HTTP Strict Transport Security Yes, but I think this requirement shouldn't apply to subresources for the page to qualify, since top-level HSTS together with the "No mixed content" requirement mean that there's no sslstrip risk for embedded resources even if they are served from a non-HSTS CDN. ___ 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 17/09/14 16:20, Richard Barnes wrote:
> There are a bunch of security features right now that I think we all
> agree improve security over and above just using HTTPS:
> -- HTTP Strict Transport Security
Check.
> -- HTTP Public Key Pinning
Others have made the point, which I agree with, that HPKP requires an
on-the-ball ops team to deploy right. If we make this part of the bar,
only a few sites will have the marker. Maybe that's what we want, maybe
not. But when the first site goes out of business because they literally
made their website inaccessible to every single existing customer,
because they were pursuing this icon and mis-deployed HPKP, then it will
not do much for the reputation of this program.
The incentive to deploy HPKP in particular should come from site owners
themselves. If other people push them into it, bad things could happen.
> -- TLS 1.2+
Are there any client-compat issues currently blocking sites from rolling
out TLS 1.2+?
> -- Certificate Transparency
I should make clear here that Mozilla currently has not committed to
support CT, although we are watching with interest. But Richard is only
sketching ideas, so that's fine ;-)
> -- Use of ciphersuites with forward secrecy
Check.
> -- No mixed content
Well yes, but you get a degraded UI experience at the moment if you have
mixed content.
> -- Content Security Policy (?)
As others have said, not sure how you could check for this actually
being used in a security-enhancing way.
> -- Sub-resource integrity (?)
What do you mean by that, exactly?
> It would be good if we could create incentives for sites to turn on
> these features. EFF has already seen some sites trying to turn
> things green on their "Encrypt the Web Report" [1]. Should we
> consider creating a suite of features that comprise a "high-security"
> web site, and create some UI to express that to the user?
I am tentatively optimistic about exploring this idea...
> We could invent new UI for this (e.g., a green lock icon), or we
> could overlay these requirements on the EV criteria.
but I think we should not mess with EV, which has a defined meaning
("the identity of the owner of this website is known with a high degree
of reliability") and therefore, we should also stay away from the colour
green. A little highlight or similar annotation on the lock might be a
good place to start. After all, we can change the UI presentation later
to be more or less visible.
But, like all security UI indicators, the question is: what do you
expect people to do when they see this (or the lack of it)? Do you
expect lack of this indicator to drive site choice decisions?
Gerv
___
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 > > 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: Indicators for high-security features
On Mon, Sep 22, 2014 at 9:36 PM, Chris Palmer wrote: > On Mon, Sep 22, 2014 at 5:56 AM, Henri Sivonen wrote: > >>> -- HTTP Strict Transport Security >> >> Yes, but I think this requirement shouldn't apply to subresources for >> the page to qualify, since top-level HSTS together with the "No mixed >> content" requirement mean that there's no sslstrip risk for embedded >> resources even if they are served from a non-HSTS CDN. > > These days we're blocking loads of active mixed content, but passive > mixed content is still a concern to me. E.g. an attacker can mangle a > web app's UI pretty badly, including to perform attacks, if the app > gets its icons and buttons via SSLstrip-able sources. My point was that if the HTML is served from HSTS-enabled https://hsts.example.com/ and in has , the image is not SSLstrip-able even if cdn.example.org doesn't support HSTS. I think it would be a mistake to make the bar for the new indicator needlessly high--especially in a way that would require pleading with an external CDN to resolve. > HPKP is indeed dangerous. > > I don't anticipate any additional UI for it, let alone additional UI > that would motivate a not-ready-yet ops team to turn it on. OK. >> It seems to me that it's at least currently impractical for small >> sites to get CAs to commit to issue future certs from a particular >> root or intermediate, so it seems to me that especially pinning an >> intermediate is hazardous unless you are big enough a customer of a CA >> to get commitments regarding future issuance practices. > > Intermediates move slowly, and roots even more slowly. It's fairly > safe to assume that, for the lifetime if your end-entity cert, the CA > will still be operating, and if that they can and will cross-sign in > cases where they re-key heavily-used issuing certs. The thing is that "fairly safe to assume" isn't really good enough if your site becomes unreachable for a year if the assumption is wrong. Current best practice with intermediates is to always re-download intermediates when renewing the end-entity cert, because the intermediate *might* have changed. As for roots, major CAs have numerous roots and at least if you are paying at the cheapest tiers, there doesn't seem to be any ahead-of-time commitment from CAs to use a particular root. Looking at Twitter's pre-pins in Chrome, it seems that even Twitter isn't counting on an ahead-of-time commitment for future issuance to happen from a particular root. (Moreover, I don't see Twitter actually serving hashes for the all the CA roots that are pre-pinned for them as HTTP headers. In fact, I don't see them serving any pinning headers at all. Especially in the CDN case, it might be a tough sell that you 1) have to research a large number of roots, just in case, and 2) stick the hashes of a large number of roots (amounting to a large number of bytes) in every response.) Maybe HKPK will lead to CAs making dependable statements about future issuance relative to intermediates and roots, but it's too early to rely on that sort of thing before it actually happens. > But, yeah, have a backup pin, and pin at various places in the > certificate chain. My point is that 1) I want the new indicator to improve the long tail, too, not just big sites, so I want the new indicator to be practically available to sites that are low-end customers from the CA perspective and 2) if you are a low-end customer for a CA, AFAICT, there's no *sure* way to have a backup pin. > I'd advise people to look at > net/http/transport_security_state_static.json and consider what > Dropbox, Google, Twitter, and Tor have done, and why. I've taken a look and, whoa, that's *complicated*! Again (I saw we already agreed; mainly talking to others who might be reading), requiring sites to deal with that sort of complication before they get the new badge would mean few sites would go for the new badge and the badge wouldn't have much impact. OTOH, if the story was that you copy and paste lines like ssl_ciphers ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_dhparam /etc/nginx/ssl/dh-2048.pem; ssl_stapling on; resolver a.b.c.d; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains"; in your server config and you get a new badge, chances are that the new badge would have a lot more impact. Getting admins to even copy and paste the above would be quite an improvement over the status quo. >> It's unclear to me if HPKP makes it safe and practical to use without >> actually forming a business relationship with two CAs in advance >> (which would be impractical for many small sites). It seems to me that >> HPKP makes it possible to generate a backup end-entity key pair in >> advance of having it certified. However, the spec itself discourages >> end-entity pinning altogether and it's pre
Re: Indicators for high-security features
On Mon, Sep 22, 2014 at 10:52 PM, Chris Palmer 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
