Yeah, the "trust" in SSL, per your comments and others, is NOT to
trust them. Instead the user has to go investigate. Yep, wonderful
trust model there.
Yeah, the "trust" in SSL, per your comments and others, is NOT to
trust them. Instead the user has to go investigate. Yep, wonderful
trust model there.
"VanguardLH" <VanguardLH@mail.invalid> wrote:
> Yeah, the "trust" in SSL, per your comments and others, is NOT to
> trust them. Instead the user has to go investigate. Yep, wonderful
> trust model there.
You have to investigate errors and warnings in *ANY* trust model.
That's how trust is established. It's what a trust model *IS* you
ignorant SOB.
<SHEESH!>
>
Nomen Nescio wrote:
>You have to investigate errors and warnings in *ANY* trust model.
>That's how trust is established. It's what a trust model *IS* you
>ignorant SOB.
>
><SHEESH!>
You've managed to prove the axiom; "Arguing with anonymous ****wits on
Usenet is a sucker's game because they almost always turn out to be,
or to be indistinguishable from, self-righteous thirteen-year-olds
possessing infinite amounts of free time and less sense than a
weathered stump."
Andy Walker wrote:
> Nomen Nescio wrote:
>
>>You have to investigate errors and warnings in *ANY* trust model. That's
>>how trust is established. It's what a trust model *IS* you ignorant SOB.
>>
>><SHEESH!>
>
> You've managed to prove the axiom; "Arguing with anonymous ****wits on
> Usenet is a sucker's game because they almost always turn out to be, or
> to be indistinguishable from, self-righteous thirteen-year-olds
> possessing infinite amounts of free time and less sense than a weathered
> stump."
While most of what you say may be true the thirteen-year-old is
essentially correct in this instance. Trust doesn't exist in a vacuum.
Average Joe users trust that their software maintainers have only shipped
products with reliable authorities installed. That trust is warranted for
the most part. It's a bit of a self correcting situation because
authorities which are found to be unreliable are generally dropped very
quickly or the maintainer's own trustworthiness is in peril. There's
proper motivation to not ship installed certificates haphazardly.
But that's only one facet of trust. Users of certificate based
authentication schemes are routinely called upon to make decisions about
certificate holders that aren't familiar to them. There's nothing new or
mysterious in that. In fact it has to be that way or the entire system
breaks. Unreliable certificates are approved, or reliable certificates
discarded.
SSL certificates are impossible to forge by any practical definition of
the word. Cryptographically they're always going to be unique, and the
SSL protocol is very good at spotting near misses even when they are 'A-
list' certificates. So the problem in boiled down terms becomes one of
user education.
There are just a couple rules of thumb that will keep even the most
uneducated users safe. MITM attacks launched against users armed with
those tidbits of knowledge are destined to fail every time. So rather
than bickering over things that can never really happen in any real world
application I think the community is better served by solidifying those
ideals.
Would anyone disagree with that?
"Victor Garrison" <vrgarrison.R2M0V3@TH15.gmail.com> wrote in message
news:fg8u19$mc0$1@registered.motzarella.org...
> Andy Walker wrote:
>
>> Nomen Nescio wrote:
>>
>>>You have to investigate errors and warnings in *ANY* trust model.
>>>That's
>>>how trust is established. It's what a trust model *IS* you ignorant
>>>SOB.
>>>
>>><SHEESH!>
>>
>> You've managed to prove the axiom; "Arguing with anonymous ****wits
>> on
>> Usenet is a sucker's game because they almost always turn out to
>> be, or
>> to be indistinguishable from, self-righteous thirteen-year-olds
>> possessing infinite amounts of free time and less sense than a
>> weathered
>> stump."
>
> While most of what you say may be true the thirteen-year-old is
> essentially correct in this instance. Trust doesn't exist in a
> vacuum.
> Average Joe users trust that their software maintainers have only
> shipped
> products with reliable authorities installed. That trust is
> warranted for
> the most part. It's a bit of a self correcting situation because
> authorities which are found to be unreliable are generally dropped
> very
> quickly or the maintainer's own trustworthiness is in peril. There's
> proper motivation to not ship installed certificates haphazardly.
>
> But that's only one facet of trust. Users of certificate based
> authentication schemes are routinely called upon to make decisions
> about
> certificate holders that aren't familiar to them. There's nothing
> new or
> mysterious in that. In fact it has to be that way or the entire
> system
> breaks. Unreliable certificates are approved, or reliable
> certificates
> discarded.
>
> SSL certificates are impossible to forge by any practical definition
> of
> the word. Cryptographically they're always going to be unique, and
> the
> SSL protocol is very good at spotting near misses even when they are
> 'A-
> list' certificates. So the problem in boiled down terms becomes one
> of
> user education.
>
> There are just a couple rules of thumb that will keep even the most
> uneducated users safe. MITM attacks launched against users armed
> with
> those tidbits of knowledge are destined to fail every time. So
> rather
> than bickering over things that can never really happen in any real
> world
> application I think the community is better served by solidifying
> those
> ideals.
>
> Would anyone disagree with that?
So answer the question that has been ignored so far: How do users
validate a CA is trustworthy? Oh, wow, the user gets an alert as
though that is their savior. It tells the user that the user will
have to verify whether or not to trust the CA. It is obvious why it
can't do that verification itself or even suggest how to do it because
anyone can be a CA. Without policing or regulation as to who can be a
CA, the user has nigh resources to do that themself. Yeah, let's
trust a 3rd party (which might be the 2nd party, the one that issued
the cert) that we cannot validate is a legit and trustworthy CA.
On Wed, 31 Oct 2007 03:50:03 +0000 (UTC), Victor Garrison
<vrgarrison.R2M0V3@TH15.gmail.com> wrote:
<snip>
>
>There are just a couple rules of thumb that will keep even the most
>uneducated users safe. MITM attacks launched against users armed with
>those tidbits of knowledge are destined to fail every time. So rather
>than bickering over things that can never really happen in any real world
>application I think the community is better served by solidifying those
>ideals.
>
>Would anyone disagree with that?
Please help this uneducated n00b user and others like me by posting
these 'rules of thumb'.
later,
jake
jake wrote:
> On Wed, 31 Oct 2007 03:50:03 +0000 (UTC), Victor Garrison
> <vrgarrison.R2M0V3@TH15.gmail.com> wrote:
>
> <snip>
> >
> >There are just a couple rules of thumb that will keep even the most
> >uneducated users safe. MITM attacks launched against users armed
> >with those tidbits of knowledge are destined to fail every time. So
> >rather than bickering over things that can never really happen in
> >any real world application I think the community is better served by
> >solidifying those ideals.
> >
> >Would anyone disagree with that?
>
> Please help this uneducated n00b user and others like me by posting
> these 'rules of thumb'.
1. If you get a warning/error/popup when trying to visit some location
using SSL (HTTPS, POP3S, etc...), don't just blindly click 'OK'.
2. Read the text on your screen, if you don't understand it and/or
can't positively identify something that would innocuously generate the
error or warning, do not proceed.
3. If you can not safely proceed and it's something you absolutely have
to do, then start asking questions. Public forums, call your bank, etc.
Those things, the first two actually, will prevent 100% of all MITM
attacks against SSL (that don't also include a prior compromise of
either the remote host or your machine in other ways). It's a user
problem, not a software or encryption problem.
On Mon, 29 Oct 2007 12:21:03 +0100 (CET), Nomen Nescio wrote:
> > Fudge brownie? Did you say...LOL LOL
>
> Of course I didn't.
> Your own cites quite plainly reiterate those same facts and sentiments
> whether the disarray in your synaptic pathways allows you to assimilate
> the words properly or not. You're a fudge brownie too.
Fudge brownie? Did you say...LOL LOL
You win. How can any one keep up with such cannyness?
Fudge brownie?
LOL LOL
>
> Thanks for engaging in the sort of puerile silliness that proves beyond
> any doubt that even YOU know you're full of **** though.
>
> And here I sat thinking it would take a little longer to send you into
> a tail spin... My bad. <laugh>
Next, Cocomarsmellow with whipped creamies? Huh?
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote