[EMAIL PROTECTED] wrote:
>
> Please don't send separate posts with the same question to multiple
> lists. Response copied form openssl-dev
My appologies. I sent it to the dev list first, then realized that such
a question was probably more appropriate in the users list. If it were
possible to
> I'm a bit of a newbie and am trying to get some clarification and better
> understanding on an issue (spurred by Seifred's controversial article):
>
> How does using Stanford SRP solve (or does it?) verification, the MITM
> problem, and need for a CA?
> http://www-cs-students.stanford.edu/~tjw/
I'm a bit of a newbie and am trying to get some clarification and better
understanding on an issue (spurred by Seifred's controversial article):
How does using Stanford SRP solve (or does it?) verification, the MITM
problem, and need for a CA?
http://www-cs-students.stanford.edu/~tjw/srp/project.
You're right, but I don't think I'll have the patience to explain this to
Thomas by myself, and honestly, I thought someone could help me explaining
this, maybe using a different vocabulary (maybe I should try to write in
French? :-)
On Tue, 19 Dec 2000, Jeff Cornett wrote:
> We have had 30 emai
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
We have had 30 emails in the last hour on this same subject including
numerous one-liners. Maybe you should take this chatroom discussion offline
until you all agree on something worth announcing to the rest of us?
Jeff Cornett
Optio Software, Inc.
225 S. Westmonte Avenue, Suite 3000, Altamonte
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
Well, with all the warnings about identity theft, etc, from all forms of media, you
would think people would be somewhat more attentive
about what is presented (I didn't say READ) on a computer screen. Especially if they
intend to put their hard-earned cash out in the
E-commerce world.
Kurt Se
"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
Kurt,
You know I agree with you, but only when it is clarified that this
is relevant to SSL implemented via HTTP. Other protocols that do not rely
on http, but rather are stateful and do not require the input of a user to
decide if the cert is bad or not are not affected. This is the onl
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
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). This wasn't such an issue until Dug Song released a
nicely packages click and compile tool. Most people
seem to think that SSH/SSL make t
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
Hey Greg,
I may be wrong because I haven't "practice" this kind of question for a
while now and I am too lazy to check if what I am saying is wrong! ;-) [Bad
guy.]
The MITM attack is an attack that takes place at connection time. The
cracker is smart enough to insert his system between the u
reading the aritcle he is pointing out that many people (especially for
SSH) do not have a way to verify the signature on the server cert so if
you are a bit careless and don't check the cert you connect to is valid
then someone can present you with a fake cert and (as you didn't bother to
check i
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
In fact, I had problem with X509v1 server cert. I didn't have problem with
v3 cert when I generate the ca cert. When I signed a csr wih a ca cert (got
v1 cert), I got the format problem.
Xiaohua
- Original Message -
From: Michael Ströder <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent:
Xiaohua Cheng wrote:
>
> So, now keytool can recognize the certificate your OpenSSL generates?
Yes. keytool of JDK 1.3, X509v3 server cert with some extensions.
> It always returns
> "unrecognized format" when I was trying to import certificate generated
> with OpenSSL into the keystore.
Try
So, now keytool can recognize the certificate your OpenSSL generates? I was
having problem with keytool several weeks ago. It always returns
"unrecognized format" when I was trying to import certificate generated with
OpenSSL into the keystore. I sent the message to user group and nobody
replie
On Tue, Dec 19, 2000 at 02:37:08PM +0100, Hampus S?derstr?m wrote:
> I have a working SSL installation on a HP machine.
>
> When I try to install the perl module Net::SSLeay i get the following error:
>
> ld: (Warning) At least one PA 2.0 object file (SSLeay.o) was detected. The linked
>output
I have a working SSL installation on a HP
machine.
When I try to install the perl module Net::SSLeay i get the
following error:
ld: (Warning) At least one PA 2.0 object file (SSLeay.o) was
detected. The linked output may not run on a PA 1.x system.ld: Invalid
loader fixup in text space n
I've written some ATL COM classes using OpenSSL (not a complete COM wrapper for
OpenSSL!) and want to share the following recomendations:
1) Use ATL if possible. MFC COM objects require a lot of tweaking for working
correctly with ASP. If you want to use ATL, choose the Simple Object, not the AS
Dr S N Henson wrote:
>
> making sure there's no summary info before BEGIN CERTIFICATE
> and seeing if you can find what format keytool wants.
Uuumpf! Yes, my fault (turning red): I did not remove the text
before BEGIN CERTIFICATE line. Sorry.
Ciao, Michael.
_
45 matches
Mail list logo