Sry finally found where I did wrong.
I should change the FQDN in the x509v3.cnf file
that where it take info to make the x509 cert
Thx to all anyway
On 3/13/06, Doug Frippon [EMAIL PROTECTED] wrote:
I've just figure out something,
with the openssl x509 -in mycert.crt -noout -text command, Isaw
I still don't understand where you're disagreeing with me.
Your attack includes things like hijacking and redirection, which is not
part of an MITM attack. Your postings also seem to come down on both
sides of succesful as to whether or not that is part of MITM.
If the MITM isn't
Hi David,
I'm going to exist myself from this discussion at the conclusion of this
mail - it's consumed enough list bandwidth without further eating into my
own limited resources.
Clipping;
On July 25, 2003 11:48 pm, David Schwartz wrote:
[snip]
Not at all. SSL with comparison of the
There is no law that says the MITM must pass any traffic to any particular
party.
Yes there is. The law of definition of MITM
If he can get plaintext out of A without sending anything ever to B,
then he has won and he's still a man in the middle. The key is that he can
intercept and
On Thu, Jul 24, 2003 at 03:43:43PM -0700, David Schwartz wrote:
Please check this url:
http://developer.netscape.com/docs/manuals/security/sslin/contents.htm
Server authentication, step 4
The only difference is that netscape just check domain name.
Does the domain name in the server's
On 2003-07-24 at 18:43, David Schwartz wrote:
Please check this url:
http://developer.netscape.com/docs/manuals/security/sslin/contents.htm
Server authentication, step 4
The only difference is that netscape just check domain name.
Does the domain name in the server's certificate match
On Fri, Jul 25, 2003 at 09:18:52AM -0400, Jue (Jacky) Shu wrote:
On 2003-07-24 at 18:43, David Schwartz wrote:
Please check this url:
http://developer.netscape.com/docs/manuals/security/sslin/contents.htm
Server authentication, step 4
The only difference is that netscape just check
This is what I'm trying to prevent. after shake-hand and authentication
by SSL, it is still not safe enough. because other poople and I share
some common secrets (key and certificate), but if secrets are comprised,
(I know that people don't like this idea of losing key, but it happened
David Schwartz wrote:
This is not a MITM. A Man-in-the-middle attack assumes a party on the
wire, witnessing all communication and able to insert arbitrary text.
Exactly. That's a MITM.
If I connect to 'www.amazon.com' through a MITM, that MITM can do one of
two things. He can
The case of connecting to a different party (hijacking) has nothing
whatsoever to do with MITM.
A MITM is a different party! No offense, but do you have any idea
what
you're talking about?
Back to school, David. MITM is used by cryptographers to refer to
an interposer who
Brian Hatch wrote:
Ahha! I know what we'll do, we'll require certificate authentication!
Ok, assuming I have a list of the major CAs and the the certificate
verified correctly
You're missing the point. A hijack or redirect is not a MITM
attack. These words have specific meaning, which you are
Ahha! I know what we'll do, we'll require certificate authentication!
Ok, assuming I have a list of the major CAs and the the certificate
verified correctly
You're missing the point. A hijack or redirect is not a MITM
attack. These words have specific meaning, which you are abusing.
Brian Hatch wrote:
Ahha! I know what we'll do, we'll require certificate authentication!
Ok, assuming I have a list of the major CAs and the the certificate
verified correctly
You're missing the point. A hijack or redirect is not a MITM
attack. These words have specific meaning,
Hi,
On July 25, 2003 01:45 pm, David Schwartz wrote:
Hijacks and redirects are all within the scope of what a MITM can do.
No, they only within the scope of what an attacker can do. The attacker
becomes a MITM if they can do it without you knowing anything's wrong.
Note doing it without
David Schwartz wrote:
Hijacks and redirects are all within the scope of what a MITM can do.
That's a Humpty-Dumpty argument, not the definition used by cryptographers.
You're simply confused, or are immune to education.
You want a simple definition of a MITM? Here it is -- you think you have:
No, they only within the scope of what an attacker can do. The attacker
becomes a MITM if they can do it without you knowing anything's wrong.
And SSL/TLS does not itself let you know anything is wrong.
SSL/TLS provides the *ability* for you to know something is wrong
*if* the developers
Sorry David, but your definition of MITM is wrong. Or, more accurately,
it is not aligned with how cryptographers and security analysts
generally conceive it.
In an MITM attack, the adversary sits between A and B and is able to
intercept and/or modify the communications between the two of
In an MITM attack, the adversary sits between A and B and is able to
intercept and/or modify the communications between the two of them
without their knowledge. Server certificates and the DN's CN must be
the FQDN (sic:) help prevent MITM.
Yes, they help. They do a damned good job of
Hi,
On July 25, 2003 03:13 pm, Brian Hatch wrote:
SSL/TLS provides the *ability* for you to know something is wrong
*if* the developers correctly used the tools available to them.
Without enforcing certificate authentication and/or CN matching,
the user will not know anything is wrong. This
And this is precisely the crux of why I think this thread is a waste of
bandwidth.
Agreed.
I'll end, promising to shut up after this, with the following summary
1) SSL/TLS has the capabilities to be immune to MITM attacks.
2) These capabilities may be used in any number
David Schwartz wrote:
Hijacks and redirects are all within the scope of what a
MITM can do.
That's a Humpty-Dumpty argument, not the definition used by
cryptographers.
You're simply confused, or are immune to education.
No, I am not at all confused. You are confused and
Hi,
On July 25, 2003 01:45 pm, David Schwartz wrote:
Hijacks and redirects are all within the scope of what a
MITM can do.
No, they only within the scope of what an attacker can do. The attacker
becomes a MITM if they can do it without you knowing anything's wrong.
The MITM
David Schwartz wrote:
No, I am not at all confused. You are confused and immune to education and
based on the number of emails I've gotten about this thread from
professional security people, I'm pretty sure I'm right
David, I am a security professional, and I have the greatest respect
Sorry David, but your definition of MITM is wrong. Or, more accurately,
it is not aligned with how cryptographers and security analysts
generally conceive it.
I don't see how. I just went to 35 sites that defined MITM and all of them
defined them the way I did.
In an MITM attack,
SSL/TLS plus good authentication methods is immune to MITM attacks.[1]
[1] Depending on everyone you trust being trustworthy. What if I'm
a verisign employee and can manage to generate a verisign-signed
cert for www.microsoft.com? I can MITM, and no alerts will occur
No, I am not at all confused. You are confused and immune to
education and
based on the number of emails I've gotten about this thread from
professional security people, I'm pretty sure I'm right
David, I am a security professional, and I have the greatest respect for
Rich Salz, and I
Please check this url:
http://developer.netscape.com/docs/manuals/security/sslin/contents.htm
Server authentication, step 4
The only difference is that netscape just check domain name.
Does the domain name in the server's certificate match the domain name of
the server itself? This step
David Schwartz wrote:
Does the domain name in the server's certificate match the domain name of
the server itself? This step confirms that the server is actually located at
the same network address specified by the domain name in the server
certificate. Although step 4 is not technically part of
David Schwartz wrote:
Does the domain name in the server's certificate match the
domain name of
the server itself? This step confirms that the server is
actually located at
the same network address specified by the domain name in the server
certificate. Although step 4 is not
David Schwartz wrote:
That's where your wrong. In the Internet trust model (anyone can get a
certificate signed by a trusted authority, all the certificate does it prove
they are who they say they are, not that they're someone I can trust), this
*is* the protection against a MITM.
This is
David Schwartz wrote:
That's where your wrong. In the Internet trust model
(anyone can get a
certificate signed by a trusted authority, all the certificate
does it prove
they are who they say they are, not that they're someone I can
trust), this
*is* the protection against a
-Original Message-
From: David Schwartz [mailto:[EMAIL PROTECTED]
Sent: 23 July 2003 02:55
To: [EMAIL PROTECTED]
Subject: RE: FQDN
Thank you, David and Steve.
Yes, it will be a big problem if someone spoof DNS,
but it can prevent man-in-the-middle to some extent
On Wed, Jul 23, 2003, Dan Kendall wrote:
Hi,
I'm a newcomer to this crypto business and maybe I'm a little confused... I
don't want to hijack this conversation but surely somebody from evil.bar.com
could provide a certificate signed by a trusted party for example.foo.com.
After all, the
On Wed, Jul 23, 2003 at 01:28:36PM +0100, Dan Kendall wrote:
I'm a newcomer to this crypto business and maybe I'm a little confused... I
don't want to hijack this conversation but surely somebody from evil.bar.com
could provide a certificate signed by a trusted party for example.foo.com.
After
Thank you, that makes more sense.
Regards,
Dan
-Original Message-
From: Lutz Jaenicke [mailto:[EMAIL PROTECTED]
Sent: 23 July 2003 13:44
To: [EMAIL PROTECTED]
Subject: Re: FQDN
On Wed, Jul 23, 2003 at 01:28:36PM +0100, Dan Kendall wrote:
I'm a newcomer to this crypto business
this to happen.
Jacky
- Original Message -
From: Lutz Jaenicke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 23, 2003 8:43 AM
Subject: Re: FQDN
On Wed, Jul 23, 2003 at 01:28:36PM +0100, Dan Kendall wrote:
I'm a newcomer to this crypto business and maybe I'm a little
confused
Jue (Jacky) Shu wrote:
Yes, Lutz. That's why I want to check peer's FQDN against which on its
certificate.
Look at Lutz' list. You get already in step 1 the FQDN from the *user*,
so there is no need for further actions to find out the peer's FQDN.
Ciao,
Richard
--
Dr. Richard W. Könning
Fujitsu
Sorry, Richard.
Maybe I didn't put it clearly.
There r two names, one is from the certificate, another one is from DNS.
They must match.
Jacky
- Original Message -
From: Richard Koenning [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 23, 2003 9:43 AM
Subject: Re: FQDN
Jue (Jacky) Shu wrote:
Sorry, Richard.
Maybe I didn't put it clearly.
There r two names, one is from the certificate, another one is from DNS.
They must match.
The other one is *not* from DNS, but from the *user* (step 1 from Lutz'
list). The user wants to connect to a specific site, and the
]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 23, 2003 10:20 AM
Subject: Re: FQDN
Jue (Jacky) Shu wrote:
Sorry, Richard.
Maybe I didn't put it clearly.
There r two names, one is from the certificate, another one is from DNS.
They must match.
The other one is *not* from DNS, but from
On Tue, Jul 22, 2003, Jue (Jacky) Shu wrote:
Thank you, David and Steve.
Yes, it will be a big problem if someone spoof DNS,
but it can prevent man-in-the-middle to some extent.
If an attacker can do MITM they can readily spoof DNS as well.
If the DNS is sabotaged, what can we do?
What
Yes, it will be a big problem if someone spoof DNS,
but it can prevent man-in-the-middle to some extent.
If the DNS is sabotaged, what can we do?
What should I believe? :-)
The point is that if you trust the user -- you should, after all you are
doing what they requested you to do -- than you
Thank you, David and Steve.
Yes, it will be a big problem if someone spoof DNS,
but it can prevent man-in-the-middle to some extent.
No, it cannot.
If the DNS is sabotaged, what can we do?
What should I believe? :-)
You should ignore the DNS entirely. If you receive a
There is no functino in OpenSSL I beleive that does such a thing.
What you need to do is get the sockaddr sin_addr data from the accept()
function. At that point you have a IP Address. Use gethostbyaddr() to convert
that IP into a FQDN. You can then verify that the FQDN of the host matches
On Mon, Jul 21, 2003 at 12:12:49PM -0400, Jue (Jacky) Shu wrote:
hi all,
maybe it is not a SSL question. I want to make post-connection assertion to
prevent man-in-the-middle attack. But I don't know how to get FQDN of the
peer side(Not from peer's certificate, it must be other side's real
On Mon, Jul 21, 2003 at 12:20:05PM -0400, Christopher Fowler wrote:
There is no functino in OpenSSL I beleive that does such a thing.
What you need to do is get the sockaddr sin_addr data from the accept()
function. At that point you have a IP Address. Use gethostbyaddr() to convert
that
In reading his orignal email, I made the assumption that he just
wanted to get the hostname + domain of the peer that conencted. To
mae the logical choice was to get the peers IP address from the socket
data and then do a lookup on that IP Address. Maybe another method will work?
On Mon, Jul
Thank you, Chris.
Yes, that's what I want to do. But I have to use SSL_accept instead of accept,
and peer's ip address is dynamic. Can I get peer's ip address from SSL
connection?
Thank you again.
Jacky
Quoting Christopher Fowler [EMAIL PROTECTED]:
In reading his orignal email, I made the
Jue (Jacky) Shu wrote:
Yes, that's what I want to do. But I have to use SSL_accept instead of accept,
and peer's ip address is dynamic. Can I get peer's ip address from SSL
connection?
Normally one makes first an accept and then an SSL_accept. After the
accept you can proceed as described by
On Mon, Jul 21, 2003, Jue (Jacky) Shu wrote:
Thank you, Chris.
Yes, that's what I want to do. But I have to use SSL_accept instead of accept,
and peer's ip address is dynamic. Can I get peer's ip address from SSL
connection?
You can get the underlying socket fd from the relevant socket BIOs
50 matches
Mail list logo
