Re: [W3C Web Security IG] developers security check list

On Tue, September 6, 2016 7:07 am, Melvin Carvalho wrote:
>  On 6 September 2016 at 15:41, GALINDO Virginie
>  <Virginie.Galindo@gemalto.com
> > wrote:
>
> > Melvin,
> > Cant Let's encrypt help on this matter ?
> >
>  Lets encrypt is awesome, but it still doesnt do wildcard certificates.

These aren't necessary for a secure infrastructure, and you will find
plenty of Web Security folks who would argue they're counter to it.

> >From a security POV it's useful to have control over different origins,
>  because tends to be a security boundary.
>
>  For my use case, I would like to provision users with cloud storage.  The
>  ideal way to do this, at present time, is to have one user per domain
>  because of the behaviour of javascript in most browsers.

Can you elaborate on this? You've specified an ambiguous concern that's
inconsistent with the rest of your response.

If your goal is security origin isolation, then the mere existence of
subdomains is not a sufficient security safeguard, due to both
document.domain and cookie handling. So I assume you can't be talking
about those, because you wouldn't actually be getting security.

If you did mean that, and did mean actual security, then presumably your
service is adding these domains to the public suffix list. If you are on
the public suffix list, then the rate limits you allude to don't apply.

That is, your complaint is internally inconsistent as presented, and
there's likely more details you need to share with the community,
otherwise, it suggests a misunderstanding or insecure deployment.

> It's still hard
>  because you have to type in a subdomain for each user and then update your
>  cert (shutting down all traffic) when a new user is added, then there are
>  also limits on how often you can do this.

This does seem like a bit of a localized problem. That is, Let's Encrypt
does solve the problem, but you've chosen a server software stack that's
suboptimal. This would be akin to arguing against CSP because your server
required you to restart it every time you changed headers. The solution
isn't to say CSP is insufficient, it's to say any server software in 2016
that requires a full offline shutdown-restart to reconfigure a TLS
certificate is simply an antiquated piece of junk, and for which many
market alternatives exist.

Received on Tuesday, 6 September 2016 16:43:01 UTC