> 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 thwart Eve (the eavesdropper... i.e., the sysadmin who
> is doing network monitoring, as an example). I am aware that Mallory
> (the malicious peer who wants to be the MITM) could obtain the
> credentials on the renegotiation; however, that requires an active
> attempt to violate the security of the connection [and thus the
> 'secrecy' of the contents of the certificates].
Exactly, so it doesn't help you.
> My issue is that user certificates from standard CAs tend to include a
> lot more information about individuals (CN="This User", CI="Cityname",
> ST="Statename", C="countrycode") than any eavesdropper needs to know,
> thus making identity theft attacks much easier when someone's spying
> on the line. So, I would like to make it explicit that someone
> maliciously obtaining the information from the certificate is doing so
> with no "but it was on the network in the clear!" defense... and thus,
> is provably attempting to access a data stream in an unauthorized
> fashion.
What you really want is two rounds of identification. One with a
certificate that doesn't contain any information you don't want to make
public, just for authentication. Once you have authenticated, you can then
present the certificate that contains the information you want to control.
I strongly caution you against adopting any threat model that involves
treating eavesdroppers differently from MITMs. It's easy enough with today's
technology to provide the same protection, so it's usually foolish not to.
YMMV.
> I do not want an eavesdropper to see the certificate exchange, and
> thus obtain the clear-text information. So, I want to create an
> unauthenticated-but-encrypted channel before exchanging the
> certificates.
You are still volunteering the information to any unauthenticated entity
that requests it. If the issue is really "it passed over my network
unencrypted" how is "you give it to anyone indiscriminately" any different?
I guess I don't know what your threat model is. If it is impossible to
authenticate with any other method, because you really do want to give the
certificate to anyone, but only if they explicitly ask or use subterfuge to
get it, maybe it could make sense.
Just understand that you have no actual security, just a legal argument.
It's like a sign that says "locked" rather than a lock.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
