> Sent: Thursday, 11 October, 2012 07:38
> My setup is:
>
> Attacker Linux PC (Client)------ SSLFP-Firewall -------Victim
> Linux PC (Server)
>
> Here, Firewall supports SSL certificate caching, So just
> wanted to know whether certificate cached from firewall can
> be viewed in Client PC. This firewall is SSL Forward proxy.
What exactly is the firewall doing, and what do you mean by
"certificate caching"?
If it's just passthrough it can see initial handshake for each
session, and could save certs from them, but can't use those
certs for anything. In particular it can't modify any later
session's intial handshake, or even see a renegotiation
(unless negotiate eNULL then renegotiate, which is yucky).
If it's terminating SSL from the client and sending clear
to the server, it has whatever key+certs it's configured with,
or if it wants to fool the client by having the real server's
name(s?) in the cert -- I believe only for client using SNI,
which few if any do -- it must be generating those certs
(for a configured key or generated keys) on the fly
or have access to an online CA that does so.
Generated certs like that might be cached and re-used;
if so you can recognize when the client gets a server
(entity) cert it has seen before, or one it hasn't
(which doesn't prove it wasn't used elsewhere).
If it's terminating SSL from the client and initiating SSL
to the server, i.e. a real SSL-level (or higher) proxy,
it may be saving the server certs and related CA certs
somewhere, but your client can't see them, because the
cert and chain used to the client can't be the same.
If it's doing client-auth on the server side, similarly
it may have fixed or generated key+cert, but your client
can't see it. If it's accepting client-auth from your client,
which is rare, it may be saving that, but it can't use it
on the server side.
> I think "-showcerts" in openssl shows the certificate which
> is cached right?
>
-showcerts shows "additional" (chain) certs sent in the
handshake by the server. The protocol does not indicate
whether they were/are cached. Usually CA certs are static
and it doesn't matter where they came from. s_client always
shows the server=entity cert, if that's what you want.
In another message you ask about multiple connections.
To reduce traffic I am replying here.
I assume you mean from s_client because that was your question
earlier, although other clients are possible. If you mean serially,
i.e. connection 1 then connection 2 then connection 3, that's
trivial, so I assume that's not your question. If you mean
concurrently, yes, just run several instances of s_client
concurrently. It doesn't matter whether they are to the same
server or not, each process and SSL connection is separate.
You probably need to make their input interactive (thus each
on a separate pty, shell window, or similar) or piped from a
program that takes some time (like sleep 60) so you have time
to type multiple commands and look at the results.
If you want s_client connections to be in one SSL "session"
i.e. negotiated authentication and session keyset, which
nominally should be same client to same server, you can
do that with -sess_out and -sess_in . But that skips the only
usage of certs in the protocol, namely for authentication,
so it seems unlikely to be what you want.