Ulf Moeller wrote:
> On Wed, Dec 20, 2000, Gary Feldman wrote:
>
> > Let's be fair. As your example really points out, the problem in this
> > specific case (your example, not necessarily the "Accept this invalid
> > certificate case") is with the developers, not the users.
>
> Which browser wou
Funny question -- easy answer:
We should expect user interfaces to not provide such a question in such a fashion --
that's why "are you sure?" question boxes appear for formatting, etc. in most UIs,
including "alias rm 'rm -i'".
That said, its the UI that's the problem in the certificate case
Gary Feldman wrote:
>
> > From: [EMAIL PROTECTED]
> > On Behalf Of Sean Wieland
> ...
> > (with OK as the default -- stupid users always assume the defaults are
> > correct)
>
> Let's be fair. As your example really points out, the problem in this
> specific case (your example, not necessarily
On Wed, Dec 20, 2000, Gary Feldman wrote:
> Let's be fair. As your example really points out, the problem in this
> specific case (your example, not necessarily the "Accept this invalid
> certificate case") is with the developers, not the users.
Which browser would that be? Netscape has no defa
> From: [EMAIL PROTECTED]
> On Behalf Of Sean Wieland
...
> (with OK as the default -- stupid users always assume the defaults are
> correct)
Let's be fair. As your example really points out, the problem in this
specific case (your example, not necessarily the "Accept this invalid
certificate ca
Robert Sandilands wrote:
>
[SNIP]
>
> Until people start really demanding security, companies like Microsoft
> will be buzzword complaint but not really secure without a lot of extra
> work and tools. There will always be the message box that you can press
> that it is Ok to delete all your files
> >
> > Kurt Seifried, [EMAIL PROTECTED]
> > SecurityPortal - your focal point for security on the 'net
> >
> > - Original Message -
> > From: "Eric Rescorla" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> >
chols [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, December 19, 2000 1:56 PM
> > To: [EMAIL PROTECTED]
> > Subject:Re: Kurt Seifred's article on securityportal
> >
> > Also, there is no crypto-board.
> >
> > Erwann ABALEA wrote:
> >
Please stop writing such non-sense garbage... ;-)
The SSL request sent by the browser doesn't reach your server, it is
captured by the sniffer (if you want to understand how, then get the
dsniff package, reade the source, the docs, and try it). The sniffer sends
a self-signed certificate to the b
Jeffrey Altman wrote:
> Again, not an SSL problem since SSL does not require the use of PKI
> ciphers. Feel free to use a non-PKI cipher in your SSL
> implementation. This is a problem with the implementations found in
> Netscape and Microsoft browsers.
A non-PKI cipher leaves us with Anon DH.
>
> It is indeed an SSL problem -- the protocol and its components rely
> on PKI, but PKI isn't really there yet. A mutually authenticated
> channel, in which the server presents the DNs of trusted signing
> authorities as part of the handshake, offers a lot more protection
> even for the clien
2000 1:56 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Kurt Seifred's article on securityportal
>
> Also, there is no crypto-board.
>
> Erwann ABALEA wrote:
>
> > No. A MITM attack can also occur even if you're using a crypto
> > accelerator. The
Also, there is no crypto-board.
Erwann ABALEA wrote:
> No. A MITM attack can also occur even if you're using a crypto
> accelerator. The only way this attack cannot occur is if you ask for
> client authentication.
>
> - the sniffer generates a self-signed certificate with the same name as
>
This is competely wrong. You fail to see the network topology. The SSL request would
still have to go through MY SSL accelerator in order to reach the actual server.
There's no other route to take. Even if what you suggest would be attempted, or even
possible, the user's browser would get the cor
On 19 Dec 2000, Eric Rescorla wrote:
> Erwann ABALEA <[EMAIL PROTECTED]> writes:
> > Software could be written to help solve this problem, for example to not
> > allow any connection from untrusted host, instead of asking the customer
> > if he's knowledgeable enough to accept the risks of accept
On Tue, 19 Dec 2000, Kurt Seifried wrote:
> They help, and are certainly a bit better then
> plaintext alternatives like telnet but they aren't perfect either.
>
Actually, a whole heck of a lot better seems to be more apt than "a bit
better". With the right user knowledge it is almost foolpro
; SecurityPortal - your focal point for security on the 'net
>
> - Original Message -
> From: "Eric Rescorla" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, December 19, 2000 10:09 AM
> Subject: Re: Kurt Sei
"Kurt Seifried" <[EMAIL PROTECTED]> writes:
> The basic problem is that most people do not check the keys (and
> will accept keys with warnings like out of date, self signed, or
> pointing to the wrong site).
While I agree that this is a problem, I frankly found your article
on this topic extremel
Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, December 19, 2000 10:09 AM
> Subject: Re: Kurt Seifred's article on securityportal
>
>
> > "Greg Stark" <[EMAIL PROTECTED]> writes:
> > > Kurt Seifried has written an article (www.securityportal.com)
No. A MITM attack can also occur even if you're using a crypto
accelerator. The only way this attack cannot occur is if you ask for
client authentication.
- the sniffer generates a self-signed certificate with the same name as
your server cert (www.secure.site)
- the browser wants to connect
Michael Sierchio <[EMAIL PROTECTED]> writes:
> Eric Rescorla wrote:
>
> > A MITM attack WOULD be possible if the browser didn't check the
> > server's certificate against the expected identity.
>
> A check against the expected identity is only useful if the
> binding of the pubkey to the identi
inal Message -
From: "Eric Rescorla" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, December 19, 2000 10:09 AM
Subject: Re: Kurt Seifred's article on securityportal
> "Greg Stark" <[EMAIL PROTECTED]> writes:
Eric Rescorla says . <
> Anyway, I suspect what he's referring to is the well-known observation
> that people are stupid enough to click through the browser provided
> warnings. If so, this isn't a flaw in SSL. [0]
>
Perhaps that's it. He alludes to a similar warning in SSH.
> Asid
> Kurt Seifried has written an article (www.securityportal.com) in which
> he claims there are man-in-the-middle attacks against SSL. I think
> his article is wrong, but he has conveniently left off enough technical
> details of his attack so that he can always say he meant something else.
Point
Erwann ABALEA <[EMAIL PROTECTED]> writes:
> Software could be written to help solve this problem, for example to not
> allow any connection from untrusted host, instead of asking the customer
> if he's knowledgeable enough to accept the risks of accepting something
> that could be potentially inse
Eric Rescorla wrote:
> A MITM attack WOULD be possible if the browser didn't check the
> server's certificate against the expected identity.
A check against the expected identity is only useful if the
binding of the pubkey to the identity is trusted. A MITM can
generate a signed cert on the fly
Quite the contrary. There is no method available for an MIIM to replace the SSL
cert as it can only reside where it is and is linked to private IP servers behind
the accelerator.
Erwann ABALEA wrote:
> On Tue, 19 Dec 2000, Thomas Nichols wrote:
>
> > The best method is to not have the SSL certifi
Michael Sierchio <[EMAIL PROTECTED]> writes:
> Eric Rescorla wrote:
>
> > This isn't a MITM attack, however.
>
> Sorry, Eric -- if you don't know or trust the signer, then you only
> know that the presenter (could be a MITM) has the private key associated
> with the pubkey in the cert. This
On Tue, 19 Dec 2000, Jeffrey Altman wrote:
> > Eric Rescorla wrote:
> >
> > > This isn't a MITM attack, however.
> >
> > Sorry, Eric -- if you don't know or trust the signer, then you only
> > know that the presenter (could be a MITM) has the private key associated
> > with the pubkey in the
On Tue, 19 Dec 2000, Thomas Nichols wrote:
> The best method is to not have the SSL certificate and key on the server to
> begin with. I use a non-ip based ssl accelerator.
This not a protection against this attack.
This attack doesn't steal the private key of the host, it only relies on
the "d
Michael Sierchio <[EMAIL PROTECTED]> writes:
> Eric Rescorla wrote:
>
> > This isn't a MITM attack, however.
>
> Sorry, Eric -- if you don't know or trust the signer, then you only
> know that the presenter (could be a MITM) has the private key associated
> with the pubkey in the cert. This
> Eric Rescorla wrote:
>
> > This isn't a MITM attack, however.
>
> Sorry, Eric -- if you don't know or trust the signer, then you only
> know that the presenter (could be a MITM) has the private key associated
> with the pubkey in the cert. This means that a MITM attack is entirely
> possibl
The best method is to not have the SSL certificate and key on the server to
begin with. I use a non-ip based ssl accelerator.
Michael Sierchio wrote:
> Eric Rescorla wrote:
>
> > This isn't a MITM attack, however.
>
> Sorry, Eric -- if you don't know or trust the signer, then you only
> know th
Goetz Babin-Ebell wrote:
>
> Greg Stark wrote:
> That the biggest problem in security is between keyboard and chair.
> The user has to know what he is doing.
> Normal user don't.
> So all computer security is faulty...
As is all cars, airoplanes, etc when a human subroutine is added :-)
/D
_
Eric Rescorla wrote:
> This isn't a MITM attack, however.
Sorry, Eric -- if you don't know or trust the signer, then you only
know that the presenter (could be a MITM) has the private key associated
with the pubkey in the cert. This means that a MITM attack is entirely
possible. Trust in the
> That the biggest problem in security is between keyboard and chair.
> The user has to know what he is doing.
> Normal user don't.
> So all computer security is faulty...
> Goetz
This is what makes all of our lives hell.
I would love to strangle 50% of the people I develop security solutions
"Fabro, Loic" <[EMAIL PROTECTED]> writes:
> As far as I know, the lastest SSL protocol is MITM-aware. That means that
> the protocol has mechanisms to avoid this issue.
> Before this last versionn, if I remember correctly (and I MAY be wrong!),
> the MITM attack could have worked if the user didn'
Greg Stark wrote:
>
> Kurt Seifried has written an article (www.securityportal.com) in which
> he claims there are man-in-the-middle attacks against SSL. I think
> his article is wrong, but he has conveniently left off enough technical
> details of his attack so that he can always say he meant s
"Greg Stark" <[EMAIL PROTECTED]> writes:
> Kurt Seifried has written an article (www.securityportal.com) in which
> he claims there are man-in-the-middle attacks against SSL. I think
> his article is wrong, but he has conveniently left off enough technical
> details of his attack so that he can a
/
Suite 1400
Vienna, VA 22182
http://www.microstrategy.com/
-Original Message-
From: Greg Stark [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 19, 2000 11:40 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Kurt Seifred's article on securityportal
Kurt S
eg Stark <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Kurt Seifred's article on securityportal
>
> Kurt Seifried has written an article (www.securityportal.com) in which
> he claims there are man-in-the-
Kurt Seifried has written an article (www.securityportal.com) in which
he claims there are man-in-the-middle attacks against SSL. I think
his article is wrong, but he has conveniently left off enough technical
details of his attack so that he can always say he meant something else.
The problem i
42 matches
Mail list logo
