Miles Bradford wrote:
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.
It's very protocol-specific.
For SSL, client sign handshake messages.
Decryption could be used instead.
Better proofs (zero-knowledge) are known but not implemented yet
for practical protocols..or maybe I miss something.
Generally, signing creates a proof of transaction did take place,
verifiable by anyone, as a by-side effect.
This means, a client might be prsented with a list of, say,
5 different sessions verifiable with his certificate
and asked for comments.
For first handshake of SSL, both client cert and signature
goes in clear.
This enables traffic analysis (who talks to whom) and not everyone
might be happy with it.
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?
Traffic analysis is not always on security requirements list.
Not every protocol (or not every mode, ciphersuite etc) prevent it.
This is why I was pointing to specifications: one better read that.
Traffic analysis is not always very damaging. For internet banking,
maybe someone go there to get current exchange rates..
For SSL/TLS, requesting client certificate while re-negotiation
but not initial handshake would make client certificate sent encrypted,
as well as the signature that prove the knowledge of private key.
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.
"Broken" might be not the best word here and "VPN" is not specific enough.
A party using wrong private key with IPSec would not pass
IKE authentication.
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.
Data confidentiality, integrity and avoiding traffic analysis are
very different requirements. Yes, someone would like all the 3.
However, some protocols pass identifying information in clear.
There might be more (somewhat fuzzy) requirements.
No protocol is trying to hide data size or timing.
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.
This means IKE was setup to expire security associations established
in 3 to 5 minutes and AH/ESP level just use associations available.
Why not read specifications for details?
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".
Protocol (or specific mode) could be designed to pass certificate
in clear. Specification is the best document to learn from.
Certificates might be visible but could not be used to "get into"
because of private keys.
Sorry if I got a bit brash.
Thanks
Miles
Regards,
Vadym
-----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]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
