>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] Behalf Of David Schwartz
>Sent: Saturday, December 31, 2005 12:05 PM
>To: openssl-users@openssl.org
>Subject: RE: Chicken and egg issue
>
>
>
>> On 12/31/05, David Schwartz <[EMAIL
> On 12/31/05, David Schwartz <[EMAIL PROTECTED]> wrote:
> > Then I'll just reiterate to anyone reading this that
> > the advice you are
> > getting is specific to some special circumstance that we cannot even
> > evaluate. We only have your word that it even applies to your
> > situation, and
>
On 12/31/05, David Schwartz <[EMAIL PROTECTED]> wrote:
> Then I'll just reiterate to anyone reading this that the advice you
> are
> getting is specific to some special circumstance that we cannot even
> evaluate. We only have your word that it even applies to your situation, and
> it cert
> On 12/30/05, David Schwartz <[EMAIL PROTECTED]> wrote:
> >
> > > Actually, he did answer my question precisely.
> >
> > > I asked if there was a way to create an ephemerally (i.e.,
> > > unauthenticated) encrypted session, after which I could exchange
> > > certificates.
> >
> > Correct.
On 12/30/05, David Schwartz <[EMAIL PROTECTED]> wrote:
>
> > Actually, he did answer my question precisely.
>
> > I asked if there was a way to create an ephemerally (i.e.,
> > unauthenticated) encrypted session, after which I could exchange
> > certificates.
>
> Correct. But how would an e
> Actually, he did answer my question precisely.
> I asked if there was a way to create an ephemerally (i.e.,
> unauthenticated) encrypted session, after which I could exchange
> certificates.
Correct. But how would an encypted session with an adversary help you?
> My intent is to thw
On 12/30/05, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote:
> If you don't want the server's certificate to be eavesdroppable that's tricky
> because an attacker could simply connect to the server using (in this example)
> anon-DH and drop the connection after it has received the server's certifica
On Fri, Dec 30, 2005, Kyle Hamilton wrote:
>
> Now, I am aware that a "man-in-the-middle" attack exists, whereby a
> malicious third party (Mallory) could accept a connection and
> negotiate an unauthenticated-but-encrypted channel, and receive the
> certificate information that I don't want to b
On 12/30/05, David Schwartz <[EMAIL PROTECTED]> wrote:
>
> If you think disclosing public keys is an information leakage issue,
> you
> don't trust the encryption you are using. I'd be extremely suspect about the
> depth of your understanding of what actually goes on in an authentication.
Actually, he did answer my question precisely.
I asked if there was a way to create an ephemerally (i.e.,
unauthenticated) encrypted session, after which I could exchange
certificates.
My intent is to thwart Eve (the eavesdropper... i.e., the sysadmin who
is doing network monitoring, as an exampl
> Is there a way to do an ephemeral (i.e., unauthenticated) encryption
> channel before transmitting whatever certificates are to be used for
> authentication? I tend to look at certificate disclosure as an
> "information leakage" issue, that gives Eve more information than she
> really has any b
> On Fri, Dec 30, 2005, Kyle Hamilton wrote:
> Yes, you start with an unauthenticated ciphersuite (for example
> anon-DH) and
> then renegotiate the session. The initial handshake is sent in
> the clear, the
> second one would use the existing ciphersuite.
>
> That wont thwart a man in the middle
On Fri, Dec 30, 2005, Kyle Hamilton wrote:
> Is there a way to do an ephemeral (i.e., unauthenticated) encryption
> channel before transmitting whatever certificates are to be used for
> authentication? I tend to look at certificate disclosure as an
> "information leakage" issue, that gives Eve m
Is there a way to do an ephemeral (i.e., unauthenticated) encryption
channel before transmitting whatever certificates are to be used for
authentication? I tend to look at certificate disclosure as an
"information leakage" issue, that gives Eve more information than she
really has any business hav
> How can I make the new node (A) send an encrypted request to the
> already existing node (B) while node A does not have any public
> key/certificate information about the already existing node (B), and
> still make sure that I am actually talking to B, and not some
> Man-In-The-Middle ?
>
> Than
On Thu, Dec 29, 2005, WebSpider wrote:
> On 12/29/05, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote:
>
> > That leaves the possibility of a new node (A') impersonating an existing
> > node.
> > To avoid that you need to be able to identify nodes securely.
> >
> > How you do that varies. For HTTPS
On 12/29/05, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 29, 2005, WebSpider wrote:
>
> > The issue I'm running into is as follows: A new node (A) is about to
> > make it's first connection to an already existing node (B). The new
> > node knows the IP address and port number by use
On Thu, Dec 29, 2005, WebSpider wrote:
> Hi there!
>
> The issue I'm running into is as follows: A new node (A) is about to
> make it's first connection to an already existing node (B). The new
> node knows the IP address and port number by use of a configuration
> file.
>
> The already existing
WebSpider wrote:
How can I make the new node (A) send an encrypted request to the
already existing node (B) while node A does not have any public
key/certificate information about the already existing node (B), and
still make sure that I am actually talking to B, and not some
Man-In-The-Middle ?
Hi there!
First of all, happy holidays ;)
We're in the middle of the holiday season, so I do hope that there are
some people around that are still reading the list, maybe even while
being on holiday ;-)
I'm having a chicken-egg problem, that I'm hoping someone on this list
can help me with.
I'm
20 matches
Mail list logo
