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.
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
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
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 may
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
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 to
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:
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
"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 always
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
"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't not
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.
RANT
I would love to strangle 50% of the people I develop security solutions
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
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
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 that the
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.
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 means
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
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 cert. This
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 means
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
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
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
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.
Pointing
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.
Aside from that
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
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 identity is
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
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
"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 extremely
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
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
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 accepting
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
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
your
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,
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 client.
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. I
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
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
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?
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?
[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
43 matches
Mail list logo
