Hello,
Le 08-déc.-06 à 14:48, Victor Duchovni a écrit :
Yes, the security of unauthenticated TLS is rather questionable.
I, the guy who asked an innocent question at first in this long
thread, have well understood this point from the very first two
answers I got in this thread and passed
On 12/8/06, David Schwartz <[EMAIL PROTECTED]> wrote:
I think that's kind of a crazy thing to say. For what possible reason would
Microsoft want my credit card information to leak to a cracker? For what
possible reason would Microsoft want my computer to be hijacked?
It's unlikely that MS woul
On Fri, Dec 08, 2006 at 04:15:15AM -0800, David Schwartz wrote:
>
> > Actually, David, the truth is that your really not getting these
> > guarentees that
> > your looking for.
>
> Correct. In a technical sense, *you* do not get the guarantees, your end of
> the HTTPS connection does. Whether yo
> Actually, David, the truth is that your really not getting these
> guarentees that
> your looking for.
Correct. In a technical sense, *you* do not get the guarantees, your end of
the HTTPS connection does. Whether you choose to trust your end or not is a
separate issue.
> The problem is that t
- Original Message -
From: "David Schwartz" <[EMAIL PROTECTED]>
To:
Sent: Thursday, December 07, 2006 6:49 PM
Subject: RE: HTTPS security model
>
> > OK, I'm going to take a humourous punch at what you just said; if
> > authentication and authorizat
> OK, I'm going to take a humourous punch at what you just said; if
> authentication and authorization are the same thing, why are both
> required? Isn't one enough? Please make up your mind...
If A and B are the same thing, either neither is required or both are
required. Everything true about
> Proponents of the requested change believe that it is much
> likelier to have
> your communications observed by a passive attacker, than to have an active
> attacker in the path that masquerades as e.g. "amazon.com". Not that the
> later is impossible - just less probable and less frequent.
Exc
"I have seen this certificate before, and I assert that I want to
allow it for limited purposes -- if only because I want to make sure
that third-parties can't see what URLs I'm looking at. I do NOT want
to post my credit card or other sites' login information to this site,
so warn me if I do so.
In message <[EMAIL PROTECTED]> on Tue, 5 Dec 2006 13:45:13 -0800, "David
Schwartz" <[EMAIL PROTECTED]> said:
davids> Authentication and authorization are the same thing.
Generally speaking, that's incorrect, even if you might have a
specific case where your statement applies.
To take an example
> > There are security paradigms such as SSH where you use "leap of
> > faith": strictly you haven't authenticated the remote end, but you
> > "know" that your peer is the other box next to you, you
> > verified its PK fingerprint visually, so you approve ("authorize")
> > that peer from now on.
> > A secure connection to an unauthenticated source is of
> > no value because the unauthenticated source could be
> > the one person who the connection is supposed to be
> > secured from. If there's nobody the connection is
> > supposed to be secured from, why would you care
> > that the connect
On Wed, Dec 06, 2006 at 07:16:32PM +, [EMAIL PROTECTED] wrote:
[ Authentication vs. Authorization ]
Yes, the real issue is that encryption without authentication does
not necessarily provide confidentiality, the party on the other end of
the encrypted connection could be the same attacker tha
> I don't understand this argument at all. The two questions you > seem to
> think are being confused are the *same* question.I don't think so.> When I
> type in "https://www.amazon.com";, what I want> to know is - do I have a
> secure connection to Amazon?This is an authentication question.> A
> The difficulty for the end user here is that the little lock icon is
> overloaded: it is taken to mean both "session is secured against
> spying" AND "session is with a trusted partner". One could argue that
> this confounds authentication (verifying the cert.) and authorization
> (asserting tr
The difficulty for the end user here is that the little lock icon is
overloaded: it is taken to mean both "session is secured against
spying" AND "session is with a trusted partner". One could argue that
this confounds authentication (verifying the cert.) and authorization
(asserting trust of the
Dear,
Le 04-déc.-06 à 19:15, Victor Duchovni a écrit :
TLS includes anonymous cipher-suites (ADH) that do not require or use
server certificates. Postfix 2.3 clients using opportunistic TLS with
Postfix 2.3 (SMTP+STARTTLS) servers will use anonymous ciphers by
default, because SMTP server authe
> This will probably look like a dumb question, but anyway. Is there
> any provision and way, in SSL and/or HTTP, to establish a SSL link
> without trying to assert anything about the server identity? Such
> that a client (a web browser) would happily use the encrypted tunnel
> while obviously n
17 matches
Mail list logo
