> 2) Protected by subresource integrity from a secure host
>
> This would allow website operators to securely serve static assets from
> non-HTTPS servers without MITM risk, and without breaking transparent caching
> proxies.
Is that a complicated word for SHA512 HASH? :) You could envisage a
I would politely ask you how many users you think are
> both interested in, able to understand, and willing to take decisions
> based on _six_ different security states in a browser?
I think this thread is about deprecating things and moving developers onto more
secure platforms. To do that, yo
> * If we have to rely, cost of certificates must be zero. These for the simple
> reason than not everyone is living in a rich industrialized country.
Certificates (and paying for them) is an artificial economy. If I register a
DNS address, I should get a certificate to go with it. Heck, last
> http://sockpuppet.org/blog/2015/01/15/against-dnssec/
> http://sockpuppet.org/stuff/dnssec-qa.html
> https://www.imperialviolet.org/2015/01/17/notdane.html
Yawn - those were all terrible articles. To summarise their points: "NSA is
bad, some DNS servers are out of date, DNSSEC may be sti
> realistic idea. Meanwhile, HTTPS exists, is widely deployed, works,
> and is the focus of this thread.
http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/
Sure it works :)
___
dev-platform mailing list
dev-
> Something entirely off-topic: I'd like to inform people that your replies to
> popular threads like this unsigned, with only a notion of identity in an
> obscure email address, makes me - and I'm sure others too - skip your message
> or worse; not take it seriously.
Not everyone has the lux
> Yep. That's the system working. CA does something they shouldn't, we
> find out, CA is no longer trusted (perhaps for a time).
>
> Or do you have an alternative system design where no-one ever makes a
> mistake and all the actors are trustworthy?
>
> Gerv
Yes - as I said previously. Do the ex
> There are already multiple sources of free publicly-trusted certificates,
> with more on the way.
> https://www.startssl.com/
> https://buy.wosign.com/free/
> https://blog.cloudflare.com/introducing-universal-ssl/
> https://letsencrypt.org/
>
I think that you should avoid making this an exerci
> > I think that you should avoid making this an exercise in marketing
> > Mozilla's "Let's Encrypt" initiative.
>
> Perhaps that's why Richard took the time to make a comprehensive list of
> all known sources of free certs, rather than just mentioning LE?
Yeah, that's what I thought when I firs
>
> You're pretty far off in the weeds here. I'll try to help you with some
> of your misconceptions.
>
I pretty much knew I was. Good luck with the project, I'm looking forward to
at least no-passive attack encryption being on-by-default... I hope that you
don't get abducted by people in
10 matches
Mail list logo