Re: Intent to deprecate: Insecure HTTP
> 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 new http URL pattern http://video.vp9? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
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, you'll need to tell me *why* I need to make the effort. The only thing that I am going to care about is to get users closer to that magic green bar and padlock icon. You may hope that security is black and white, but in practice it isn't. There is always going to be a sliding scale. Do you show me a green bar and padlock if I go to www.google.com, but the certificate is issued by my intranet? Do you show me the same certificate error I'd get as if I was connecting to a clearly malicious certificate. What if I go to www.google.com, but the certificate has been issued incorrectly because Firefox ships with 500 equally trusted root certificates? So - yeah, you're going to need a rating system for your security: A, B, C, D, Fail. You're going to have to explain what situations get you into what group, how as a developer I can move to a higher group (e.g. add a certificate hash into DNS, get an EV certificate costing $10,000, implement DNSSEC, use PFS ciphersuites and you get an A rating). I'm sure that there'll be new security vulnerabilities and best practice in future, too. Then it is up to me as a developer to decide how much effort I can realistically put into this... ...for my web-site containing pictures of cats... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
> * 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 time I got an SSL certificate, they effectively bootstrapped the trust based on my DNS MX record... Hence IMO TLS should be: - DANE for everyone - DANE & Trusted Third Party CAs for the few - DANE & TTP & EV for sites that accept financial and medical details The Firefox opportunistic encryption feature is a good first step towards this goal. If they could just nslookup the TLSA certificate hash, we'd be a long way down the road. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
> 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 still using shorter 1024bit RSA key lengths (hmm... much like TLS then)" The trouble is: Just because something isn't perfect, doesn't make it a bad idea. Certificates are not perfect, but they are not a bad idea. Putting certificate thumbprints in DNS is not perfect, but it's not half a *good* idea. Think about it: if your completely clear-text, unauthenticated DNS connection is compromised, then your browser is going to go to the wrong server anyway. If it goes to the wrong server, so will your email, as will the identity verification messages from your CA. Your browser needs to retrieve A and addresses from DNS anyway, so why not pull TLSA certificate hashes at the same time? Even without DNSSEC, this could only improve things. Casepoint, *absolutely* due to the frankly incomprehensible refusal to do this: http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/ There is nothing you can do to fix this with traditional X509, or any single chain of trust. You need multiple, independent proofs of identity. A combination of X509 and a number of different signed DNS providers seem like a good way to approach this. Finally - you can audit DNSSEC/TLSA responses programmatically as the response records are cached publicly in globally dispersed DNS servers, it's really hard to do the equivalent of "send a different chain when IP address 1.2.3.4 connects". I have my own opinions why TLSA certificate pinning records are not being checked and, having written an implementation myself, I can guarantee you that it isn't due to any technical complexity. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
> 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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
> 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 luxury of being public on the Internet. Especially in discussions about default Internet encryption. The real decision makers won't be posting at all. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
> 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 existing certificate checks to a trusted CA root, then do a TLSA DNS look up for the certificate PIN and check that *as well*. If you did this (and Google publish their SHA512 hashes in DNS) you'd could have had lots of copies of Firefox ringing back "potential compromise" messages. Who knows how long those certificates were out there (or what other ones are currently out there that you could find just by implementing TLSA). The more routes to the trust the better. Trusted Root CA is "all eggs in one basket". DANE is "all eggs in one basket", DNSSEC is "all eggs in one basket". Put them all together and you have a pretty reliable basket :) This is what I mean by working a security rating A,B,C,D,Fail - not just a "yes/no" answer. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
> 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 exercise in marketing Mozilla's "Let's Encrypt" initiative. "Let's Encrypt" is a great idea and definitely has a place in the world, but it's very important to be impartial. In my mind there is no particular advantage in swapping lock in from one CA to another. Even if the Mozilla one is free. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
> > 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 first posted here. Now I'm not so sure. You do not seem interested in hearing about any other technical possibilities other than Let's Encrypt, which you seem to have already chosen. For example: - You say "there is only secure/not secure". Traditionally, we have things like defense in depth, and multiple levels of different sources of authentication. I am hearing: "You will either have a Let's Encrypt certificate or you don't". Heck, let's get rid of EV certificate validation too while we are at it: we don't want to have to do special vetting for banking and medical websites, because that doesn't fit in with Let's Encrypt's business model. - You don't want to hear about non-centralized security models. DANE provides me with control over certificate pinning for people visiting my websites. You seem to be saying: Mozilla's CA will have full control over all websites. I'm not sure why you'd want that level of responsibility. If you don't like DANE, explain why, and propose something else that is non-centralized and not under Mozilla's control. - Personally, I think that the move away from http:// is a good idea, and the opportunistic encryption features are an excellent start. I am not clear why you think that we *technically* need to go beyond this. Other than to force people to use a centralized identity system. Which is? Hmm... Let's Encrypt. I *really* hope I am misunderstanding this thread... I don't think of Mozilla as a company that would try to do this. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
> > 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 black helicopters! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
