Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Another CA Compromise: TurkTrust

Ruben Bloemgarten ruben at abubble.nl
Thu Jan 3 18:28:05 PST 2013


On 01/04/2013 02:41 AM, Collin Anderson wrote:
> On Thu, Jan 3, 2013 at 5:26 PM, Ruben Bloemgarten <ruben at abubble.nl
> <mailto:ruben at abubble.nl>> wrote:
> 
>     "you don´t know who I am, but only we know what we´re telling each
>     other."
> 
> 
> So essentially you and Nadim are arguing that, since CAs fail some of
> the time, we should get rid of the whole system and end up in the same
> position -- where there is no trust in validating that the person
> talking to you is actually who they say they are? 
> 
> Does anyone believe that users will actually understand the difference?


Not quite. I´m arguing that the current system is inherently flawed,
irrespective of technical failure, that it would be a great improvement
if there is no default trust as to whom is "spoken" to in the context of
"cloudy" services.

Is the basic concept of having a form of verification as to the data
exchange partner good ? Of course it is. But if that verification is not
intuitively verifiable how does it do more than instill a false sense of
security ? That can not be better than having an understandable model of
default distrust.

I´m not even sure whether the concept of combining certification with
encryption is such a brilliant idea to begin with, why would this even
be required ? Confirmation of a data exchange partner (publicly
accredited certification) does not ipso facto require encrypted data
exchange, and vice versa.

Furthermore I´m arguing that users already don´t understand the
difference between http and https in the browser bar, and that for as
far as knowing who is being spoken to, there exists merely that
unfortunate false sense of security. In the current scheme
confidentiality is being combined with trustworthiness based on a
willingness and ability to pay, which makes confidentiality
prohibitively expensive and trustworthiness sketchy at best.

my apologies for the less than comfortable sentence structuring.

> 
> 
> On Thu, Jan 3, 2013 at 5:26 PM, Ruben Bloemgarten <ruben at abubble.nl
> <mailto:ruben at abubble.nl>> wrote:
> 
>     Nadim,
> 
>     I think its about time to have CA´s be peer accredited institutes
>     (EFF/tor/access now/my brother´s sister´s cousin/ whoever) issuing free
>     or at least at cost certs. That being said, I don´t think certs are very
>     good at preventing mitm anyway, that might be the case if a majority of
>     users would have the wherewithal for a more realistic reaction than "ooh
>     red/green is bad/good", and even then. Love ssl, don´t really care about
>     certs. So yes, lets dump "trust me, I´ve been certified" in favor of
>     "you don´t know who I am, but only we know what we´re telling each
>     other."
> 
>     - Ruben
> 
>     On 01/04/2013 02:09 AM, Nadim Kobeissi wrote:
>     > Another CA has been found issuing SSL certificates for Google
>     services.
>     > Mozilla has acted on the
>     > issue:
>     https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/
>     >
>     > The weird thing is that it's starting to appear less and less crazy to
>     > just get rid of the CA system and replace it with… nothing. What
>     do you
>     > guys think?
>     >
>     > NK
>     >
>     >
>     > --
>     > Unsubscribe, change to digest, or change password at:
>     https://mailman.stanford.edu/mailman/listinfo/liberationtech
>     >
> 
>     --
>     Unsubscribe, change to digest, or change password at:
>     https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 
> 
> 
> 
> -- 
> *Collin David Anderson*
> averysmallbird.com <http://averysmallbird.com> | @cda | Washington, D.C.
> 
> 
> --
> Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 




More information about the liberationtech mailing list