[liberationtech] verifying SSL certs (was Re: In defense of client-side encryption)

[Tom O]

re this has anyone had a look at Tack.io?


On Tue, Aug 20, 2013 at 12:42 PM, Darlene Scott
<darlenescott673 at yahoo.com>wrote:

>
> Has anyone here looked into "Namecoin" at all? I must admit I've only seen
> a two line reference about it and meant to follow up but haven't had the
> time.
>
> https://en.wikipedia.org/Namecoin
>
> Do you think the same distributed approach could be applied to certifying
> SSL-like connections?
>
> Sorry if this question seem naive. I have no deep knowledge of internet
> protocol structure or function.
>
>
> --------------------------------------------
> On Mon, 8/19/13, Ben Laurie <ben at links.org> wrote:
>
>  Subject: Re: [liberationtech] verifying SSL certs (was Re: In defense of
> client-side encryption)
>  To: "liberationtech" <liberationtech at lists.stanford.edu>
>  Date: Monday, August 19, 2013, 3:41 AM
>
>
>
>
>  On 14 August 2013
>  10:46, Guido Witmond <guido at witmond.nl>
>  wrote:
>
>  On
>  08/14/13 15:18, Ben Laurie wrote:
>
>  > On 14 August 2013 08:54, Guido Witmond <guido at witmond.nl
>
>  > <mailto:guido at witmond.nl>>
>  wrote:
>
>  >
>
>  >     On 08/13/13 19:42, Andy Isaacson wrote:
>
>  >     > On Mon, Aug 12, 2013 at 11:10:39AM +0200,
>  Guido Witmond wrote:
>
>  >     >> There is another problem. You rely on
>  HTTPS. Here is the 64000
>
>  >     >> dollar question:
>
>  >     >>
>
>  >     >> Q._"What is the CA-certificate for
>  your banks' website?"_
>
>  >     >>>
>
>
>
>  [snip]
>
>
>
>  >     I too have given up on expecting security from
>  the global CA's. That's
>
>  >     why I want to see DNSSEC succeed.
>
>  >
>
>  >
>
>  > DNSSEC merely transfers the problem to registries and
>  registrars, who
>
>  > are no more reliable than CAs. You need to solve the
>  problem of having
>
>  > to trust third parties before DNSSEC will work (which
>  is the same
>
>  > problem you need to solve for CAs),
>
>
>
>  Yes, there is trust involved, but there is a difference.
>
>
>
>  With CA's anyone can sign a certificate for any site.
>  It's a race to the
>
>  bottom with no winners. Not even the CA's as they
>  can't differentiate
>
>  between themselves. The consequence is that no one trusts
>  any of them.
>
>  And who likes to do business with a party he doesn't
>  trust but needs anyway?
>
>
>
>  With DNSSEC, I have the choice of registrar. If there is a
>  bad apple, I
>
>  choose another who I find better worth my money.
>
>
>
>
>
>  > And, sorry to bang on about it, but
>
>  > the answer is Certificate Transparency. BTW, my team is
>  about to start
>
>  > looking at DNSSEC Transparency, too.
>
>
>
>  Don't bang to hard: DNSSEC and CT solve the same
>  problem.
>
>  This is not
>  correct.
>
>
>
>  The problem is that there is no registry that specifies
>  which of the
>
>  Global Certificate authorities is the one you should trust
>  to validate a
>
>  server-certificate. The mess we have right now is that each
>  of the
>
>  Global CA's can sign a server certificate. Hence my
>  64000 dollar question.
>
>
>
>  Both DNSSEC and CT solve the problem. Albeit in different
>  ways with
>
>  different pros and cons.
>
>
>
>  With DNSSEC and DANE, the site operator specifies *a priori*
>  which CA he
>
>  uses to sign the server certificates. It can be a self
>  signed certificate.
>
>
>
>  With CT, you register which CA has signed a certificate for
>  a web site
>
>  *after the fact*.
>
>  Not really. The registration occurs before the
>  cert can be used.
>
>
>
>  We need them both! To keep the CA's and registrars
>  honest. I really
>
>  appreciate your work on CT.
>
>  CT does not keep registrars honest. This is why
>  you need DNSSEC transparency.
>
>
>
>  Guido.
>
>
>
>
>
>  --
>
>  Liberationtech is a public list whose archives are
>  searchable on Google. Violations of list guidelines will get
>  you moderated:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech.
>  Unsubscribe, change to digest, or change password by
>  emailing moderator at companys at stanford.edu.
>
>
>
>
>
>  -----Inline Attachment Follows-----
>
>  --
>  Liberationtech is a public list whose archives are
>  searchable on Google. Violations of list guidelines will get
>  you moderated:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech.
>  Unsubscribe, change to digest, or change password by
>  emailing moderator at companys at stanford.edu.
> --
> Liberationtech is a public list whose archives are searchable on Google.
> Violations of list guidelines will get you moderated:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech.
> Unsubscribe, change to digest, or change password by emailing moderator at
> companys at stanford.edu.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130820/90c0a455/attachment.html>