On Tue, Apr 1, 2014 at 6:04 PM, Philip Hands wrote: > I think the real problem here is the user interface asking one to trust > a site (forever, unless you're concentrating) at a point where you > really don't care because all you're interested in is seeing the cute > picture of an otter on someone's blog.
Indeed, the browser vendors basically fell for the NSA's social engineering and put up scary warnings for a situation that is approximately equivalent to plain unencrypted HTTP, which they treat as all fine and good. > If browsers treated all new certificates with suspicion, limiting the > things that could be done in javascript, and not allowing forms to be > filled in, say, and then when you decided that you wanted to offer the > site some trust (because you want to fill in your credit card on the > https://amazon-really-it-is.mafia.biz/ site) the browser could then > guide you toward some checks that you might want to perform before > continuing, and because you've got a credit card n your hand you might > be vaguely interested at that point. They don't even do that stuff for plain unencrypted HTTP so it is unlikely they would for self-signed or unknown-ca HTTPS connections. > Anyway, can we not just have a cacert-certificates package, and then > people like me, who use cacert, could decide to trust them easily on my > machines at least? If we instead do things that make it harder for even > Free Software enthusiasts to use something like CAcert, then the slim > chance that CAcert might eventually become properly useful gets even > slimmer. >From the discussion on #debian-security it sounds like what will happen is either a ca-certificates-cacert package or adding cacert.org to ca-certificates but disabled by default. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6et5cbxheabmfmw4fcv+mfkpto21oo6upm9yyk+br0...@mail.gmail.com
