Thanks for your answer.
But, the first question that was asked: I forget who asked it first?
Ok, so if it is not a problem if the certificate is intercepted, how
> to "prove that you are the party the certificate was issued to by
> demonstrating possession of the private key " ? Is it a special
> configuration the VPN ?
Didn't really get answered from how I understand the question to be.
My question on top of that was - "How could someone intercept an encrypted
message and get to the information inside the certificate without corrupting
the encryption that the data is wrapped in - since once the perpetrator
learned who you are - who cares that that data was encrypted or not at this
point. The whole point of encryption is to keep people out - correct?
My point of understanding on this is - that once the keys are broken, they
don't or won't work anymore and you are denied access on the VPN. Not to
mention that IPSec starts giving you problems at that point. That's what I
have experienced anyhow.
I am trying to understand someone else's writing "could not" be a problem
if someone intercepts a certificate. I have a problem with the first part
to start with. How can an encryption be intercepted, undone and the data
inside gotten to, then rewrapped in encryption and then passed on. I don't
understand encryption working like that. I totally agree with you and David
- in that you cannot cheat the encryption.
My experience with the users in the field is - that once a key gets
corrupted - IPSec kicks them off the VPN averaging in 3 to 5 minutes.
I'm trying to figure out "Who" said that it was "Okay" for "Certs" to get
intercepted and could be used to get into the perspective system?
If someone has figured out that it is "Okay" - I'd like to find out "Why"
and "How".
Sorry if I got a bit brash.
Thanks
Miles
-----Original Message-----
From: Vadym Fedyukovych [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 17, 2005 6:40 PM
To: openssl-users@openssl.org
Subject: Re: simple question again
Miles:
I second David Schwartz.
With properly designed VPN and properly issued certificates
and secure use of private key (no leaks)
of proper size (1024 bits for RSA)
there's no chance to cheat a party that follow the specifications.
One should beware:
- brand-new self-made VPNs. Use IPSec, HIP or maybe something
designed by smart people that did their PhD in crypto.
- top latest branded protocol extensions that were not analyzed
in public or have no published specifications.
- statements about protocols and certificates made by sales.
Never forget about the private key corresponding to public one certified.
If you still believe one could trick a host into thinking
it's talking to some random host over IPSec with certificate-based
authentication, without knowledge of private key:
you're welcome to describe exactly how it could be done
it terms of protocol specifications.
You should be prepared to produce a convincing demonstration,
in lab environment.
Maybe you'd prefer to just keep talking about that matters instead.
Please be sure that will damage your reputation
Miles Bradford wrote:
> isn't that just what i said
> seeing as how you seem only to be able to address me - don't! if fact -
go
> away
> if you were so smart - these people wouldn't keep asking the same
questions
> over and over and over
> because they would have gotten the answers from you - obviously you're
much
> too good or lazy for them so
>
> address those persons who seemingly can't read a thousand pages to get one
> page of understanding.
> Phd's write billions of words - but, with a single push of a button blow
the
> whole damn world up.
> If you people didn't write about your life stories in the documents no one
> would ever know you existed -
>
> maybe these people who don't know what you're talking about in Harvard
terms
> - wouldn't have to be explained in layman terms if you were backward
> compatible.
> Believe me - they understand exactly what it is I am saying
> I really don't need you on the other end barfing crap at me.
> Who put your XXs on the rock to walk anyway?
> Did you discover intelligence or something that no one else has been able
> to?
> Oh crap - go humble yourself - someone else created the internet. But, it
> wasn't you.
> So if you're not smart enough to be backward compatible - go away and only
> speak to those who understand - you. Don't try to piss on people with
some
> sort of holier than thou crap.
> SSL is broken on a daily basis with the Bluecoat and just as easy as I
said.
> Go away and quit bothering me with whatever.
>
> -----Original Message-----
> From: David Schwartz [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 17, 2005 4:22 PM
> To: openssl-users@openssl.org
> Subject: RE: Re: simple question again
>
>
>
>
>>This is why in my other replies to whomever - I made the
>>statement about how
>>fast all this can be done. It takes at least 3 good handshakes to get
>>onboard a SSL site - but, what matters the most is that
>>&*_*&)^&^)*_**;qwepqowifskljfas that surrounds the key - is intact and not
>>minus or plus one letter of symbol or corrupted in any way and what do the
>>placements of those objects matter. That's what is being looked
>>for in the
>>comparisons of the algorithms that do the checking. Of course
>>you want the
>>inside data to be left intact - but, can you really do that and
>>find it out
>>without corrupting it's wrapper? in the length of time shorter
>>than it takes
>>for the originator to establish a legitimate connection? NO - you cannot,
>>unless you are running a seamless proxy intercepting and passing
>>on before
>>you as you go. No impossible - but, usually done only outside the United
>>States where it's uncontrolled. Most objects (subjects or persons --
>>whatever) in the U.S. don't even have the education to go there - so why
>>bother worrying about it.
>
>
> I have no idea what you are talking about and strongly suspect that
> you
> don't either. Modern cryptographic algorithms are carefully designed to
> withstand attacks, even from atackers with full control over the data
> proxied and even from attackers with computing power that vastly exceeds
> that available at the endpoints. Designing or analyzing cryptographic
> schemes as sloppily as you suggest above would be inexcusable professional
> negligence.
>
> DS
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager [EMAIL PROTECTED]
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
