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
that
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 r
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
> th
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 21
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 a
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 Chri
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 B
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?
> Wha
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 don'
> 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
now quite confused,
Dan
> -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 som
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, t
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.
> Af
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:
&g
prevent 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 newc
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 Si
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 2
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 syste
om: "Richard Koenning" <[EMAIL PROTECTED]>
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,
> 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
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 protect
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 t
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 certif
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 netsc
> 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 tamper
> >>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
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 a
> >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 abu
> 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 mean
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 withou
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:
Si
> 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 them
> 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
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. Th
> 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
> 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.
T
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 for
> 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
> unti
> >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 Sal
> 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 inter
This will be my last post on this issue. I promise.
> > 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"
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 c
> 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
> intercep
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, Is
51 matches
Mail list logo
