FYI: Chrome alignment with BSI's "Recommendations for Secure Web Browsers"
47 views
Skip to first unread message
Parisa Tabriz
Jun 12, 2014, 1:34:07 PM6/12/14
to Hillebrand, Florian, security-dev, Wieland Holfelder, Stephan Somogyi, secu...@chromium.org, securit...@chromium.org
FYI, the BSI have just published an English version of their, "Recommendations for Secure Web Browsers" at https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_downloads/anwender/software/BSI-CS_071E.pdf%3bjsessionid=7BE8B86AF631E89911DF5BD8DB1A84BF.2_cid369?https=1&__blob=publicationFile. Thanks Florian for the forward!
Needless to say, I'm very happy to see how well Chrome is aligned to their guidelines.
Victor Costan
Jun 13, 2014, 6:39:01 PM6/13/14
to Parisa Tabriz, Hillebrand, Florian, security-dev, Wieland Holfelder, Stephan Somogyi, secu...@chromium.org, securit...@chromium.org
It looks like we're missing a chrome://settings/content setting for
WebGL. (see 2.1) We have a flag instead, chrome://flags/#disable-webgl
If it's desirable, I could look into turning the flag into a content
settings. I've spent a bit of time in that area, and I know how most
of the code works.
Other than that, I think we only miss 1.6. I think achieving
verifiability would require reproducible builds, as well as relegating
all the closed-source code to libraries running under Native Client.
It'd be awesome to have these properties, but that seems like a
long-term effort.
Victor
> To unsubscribe from this group and stop receiving emails from it, send an
> email to security-dev...@chromium.org.
WebGL. (see 2.1) We have a flag instead, chrome://flags/#disable-webgl
If it's desirable, I could look into turning the flag into a content
settings. I've spent a bit of time in that area, and I know how most
of the code works.
Other than that, I think we only miss 1.6. I think achieving
verifiability would require reproducible builds, as well as relegating
all the closed-source code to libraries running under Native Client.
It'd be awesome to have these properties, but that seems like a
long-term effort.
Victor
> email to security-dev...@chromium.org.
Joel Weinberger
Jun 13, 2014, 6:57:00 PM6/13/14
to Victor Costan, Parisa Tabriz, Hillebrand, Florian, security-dev, Wieland Holfelder, Stephan Somogyi, secu...@chromium.org, securit...@chromium.org
6.1 also implies that a requirement is that we should be checking the CRL, which, if I'm not mistaken, we don't (because it's stupid). Or am I misreading that?
--
--
-----
secu...@chromium.org is for discussing vulnerabilities and fixes in Chromium code.
Please protect Chromium users: DO NOT FORWARD this email or disclose its contents to third parties.
http://groups.google.com/a/chromium.org/group/security
Ryan Sleevi
Jun 13, 2014, 6:58:59 PM6/13/14
to Joel Weinberger, Victor Costan, Parisa Tabriz, Hillebrand, Florian, security-dev, Wieland Holfelder, Stephan Somogyi, secu...@chromium.org, securit...@chromium.org
There's an enterprise flag to enable (soft-fail) revocation checking, for organizations that are enforcing these sorts of policies.
There is also an enterprise flag to enable hard-fail for non-publicly trusted CAs
Joel Weinberger
Jun 13, 2014, 7:07:24 PM6/13/14
to Ryan Sleevi, Victor Costan, Parisa Tabriz, Hillebrand, Florian, security-dev, Wieland Holfelder, Stephan Somogyi, secu...@chromium.org, securit...@chromium.org
And just to clarify, by "stupid" I really meant "doesn't do what most people think it does," a la https://www.imperialviolet.org/2014/04/29/revocationagain.html. My apologies for the strong and inappropriate language (I had to explain CRL stuff to a bunch of friends recently and got frustrated about it).
On Fri, Jun 13, 2014 at 3:58 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
There's an enterprise flag to enable (soft-fail) revocation checking, for organizations that are enforcing these sorts of policies.There is also an enterprise flag to enable hard-fail for non-publicly trusted CAs
Great. Glad to know that this covers the requirement.
Reply all
Reply to author
Forward
0 new messages