> 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
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
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
> 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
> 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
Howdy,
I have looked a little on the web sites for the answer to this
question but don't see one redily available. I am building openssl
on a redhat 9 system. My question is, "why is /usr/local/bin
hardcoded througout the distribution?" RedHat installs perl it in
/usr/bin and I have to fool around
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
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.
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
I compiled and tried a simple server code listed for openssl server on http://www.metalshell.com/view/source/108/.
The test system is running Linux Fedora Core 2 with openssl 0.9.7a. The server code compiles and runs fine. However, when I created a test client that continuously connect to the
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
> 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, 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
13 matches
Mail list logo
