-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OpenSSL 0.9.7j on OpenBSD 4.0
1. Created a cert for host.domain1.tld (a mail server that houses
multiple virtual domains, but its real hostname is host.domain1.tld)
using the commands and config file listed below
2. Installed the root CA cert and ser
Hi all,
I'm using openssl with my application; I'd like to add the 5th optional
step (to avoid man-in-the-middle-attack) in my tls negotiation by
ensuring the FQDN presents in the certificate with the actual fqdn of
the sender.
1) Please suggest me a way to extract subject na
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 -no
I've just figure out something,
with the openssl x509 -in mycert.crt -noout -text command, Isaw that
there is the same subjectAltName in my two cert. I'm sure that I
diodn't wrote the same in both of them, but seems like if some one
have modify it. =-)
BTW I've add the subjectAltNmae by writting d
Hi all,
How can a self signed certificate in X509 format be distinguished from a
bought one?
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.12/75 - Release Date: 17/08/2005
___
Hi,
> when typing https://ipaddress:443/index.html into a browser
> it cannot find the page and goes back to
>
> https://ipaddress
port 443 *IS* https. the browser sees the one and same.
alan
__
OpenSSL Project
(sec)
Verify return code: 7 (certificate signature failure)
any ideas?
tia,
dk
-Original Message-
From: [EMAIL PROTECTED]
Sent: Aug 10, 2005 11:28 AM
To: openssl-users@openssl.org
Subject: Re: Can SSL work with IP Address instead of FQDN?
Try:
Group nobody
Of course, you need
Invalid argument: setgid:
> unable to set group id to Group 4294967295
>
>
> tia,
> dk
>
>
>
>
> -Original Message-
> From: Jorey Bump <[EMAIL PROTECTED]>
> Sent: Aug 10, 2005 11:07 AM
> To: openssl-users@openssl.org
> Subject: Re: Can SSL
a,
dk
-Original Message-
From: Jorey Bump <[EMAIL PROTECTED]>
Sent: Aug 10, 2005 11:07 AM
To: openssl-users@openssl.org
Subject: Re: Can SSL work with IP Address instead of FQDN?
[EMAIL PROTECTED] wrote:
>>also looking into (22)Invalid argument: setgid: unable to set group
> Thanks very much for your response. Any idea what the Group
> setting needs to
> be in httpd.conf?
>
> this is how it looks now
>
> User nobody
> Group #-1
>
> tia,
> dk
It depends what group you want apache to run under. If you have a
"nobody"
group, that's probably what you want.
[EMAIL PROTECTED] wrote:
also looking into (22)Invalid argument: setgid: unable to set group id to
Group 4294967295
This is your real problem. Check your Group setting in your apache
configuration. You probably just need to get your permissions and
ownerships correct.
Thanks very much for
t; [EMAIL PROTECTED] wrote:
> > Trying to set up ssl for an intranet. There is no FQDN, just an IP address.
> >
> > Is this possible?
>
> Yes. The only important thing is that the hostname used by clients to
> find your machine must match the Common Name in the certifica
dea what the Group setting needs to
be in httpd.conf?
this is how it looks now
User nobody
Group #-1
tia,
dk
-Original Message-
From: Jorey Bump <[EMAIL PROTECTED]>
Sent: Aug 10, 2005 10:51 AM
To: openssl-users@openssl.org
Subject: Re: Can SSL work with IP Address instea
[EMAIL PROTECTED] wrote:
Trying to set up ssl for an intranet. There is no FQDN, just an IP address.
Is this possible?
Yes. The only important thing is that the hostname used by clients to
find your machine must match the Common Name in the certificate. So, if
your other machines use https
Trying to set up ssl for an intranet. There is no FQDN, just an IP address.
Is this possible?
I've create the certificate keys as X.X.X.X.key
instead of www.example.com.key
I'm able to run the startssl command (see below)
It asks for the pass phrase, and says it logs in, but 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
> intercep
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
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"
> 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
> >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
> 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
data,
the MITM attack fails. If the MITM can obtain some plaintext before you
could detect him, he wins.
> Server certificates and "the DN's CN must be
> the FQDN" (sic:) help prevent MITM. (No, it doesn't happen
> automatically -- you have to check the trust chain,
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
> 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:
> > 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 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
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
> 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 h
them
without their knowledge. Server certificates and "the DN's CN must be
the FQDN" (sic:) help prevent MITM. (No, it doesn't happen
automatically -- you have to check the trust chain, certificate keyUsage
and nameConstraints, and all that other stuff -- but it is possible
> 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
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
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
> 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
> >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 meaning, which you are a
> >>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
othing to do with MITM, nothing to do with SSL, etc.
It happens to be a very practical thing that browsers do, and
is the correct default behavior, to raise an alert when the cert
presented doesn't match the FQDN. But it's your choice at that
point.
How am I protected against a MITM
> 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
>
aged, it won't lead you to the
> machine you want to connect. Yes, you will say that you still need to
> check DN, But even DNs match, it is still not enough for security.
>
> What's the difference between DN and FQDN? It is applciation related. If
> I'm sure that m
in the certificate.
Well, if there is no DNS, how can you connect to a machine on the
internet? If the DNS has been sabotaged, it won't lead you to the
machine you want to connect. Yes, you will say that you still need to
check DN, But even DNs match, it is still not enough for security.
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
> 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
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:
> > "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:
"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
> 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
Hi Richard,
In your case, it is the client want to check server.
I know it is common to check server's location.
But now I want to check client as well.
The server doesn't know where the client comes from,
so the server needs to get client's ip address and then its FQDN.
I think
e, and the system has
to ensure that it does, what the *user* wants. Therefore, get the FQDN
from the *user* and ensure that the name from the certificate agrees
with the FQDN from the *user*.
Ciao,
Richard
--
Dr. Richard W. Könning
Fujitsu Siemens Computers GmbH, E
3, 2003 9:43 AM
Subject: Re: FQDN
> 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
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. Richar
Yes, Lutz. That's why I want to check peer's FQDN against which on its
certificate.
Actually, just like what Steve said before, even the hacker can spoof DNS,
he still needs peer's certificates and key to masquerade the owner of that
key.
Checking of the FQDN is an extra step to
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
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
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
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
> 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
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'
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
fd from the relevant socket BIOs using the
appropriate calls, see BIO_s_socket() docs for more info.
Which side (client, server) do you want the FQDN for BTW?
One thing to be careful of is that DNS spoofing can't be used to fool
any checks you make.
Steve.
--
Dr Stephen N. Henson.
Core de
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
r 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 in the certificate.
> >
> > I doubt
gt; > 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 in the certificate.
>
> I doubt this.
> Yes, DNS is used for lookup from "reverse" zone.
>
) to convert
> that IP into a FQDN. You can then verify that the FQDN of the host matches
> that in the certificate.
I doubt this.
Yes, DNS is used for lookup from "reverse" zone.
However, FQDN was intended to check whether client manage to connect
to the server he originally intended.
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
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
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 address).
Is there any socket fucntion to get peer&#x
66 matches
Mail list logo
