> From: owner-openssl-us...@openssl.org On Behalf Of Sharanagoud B D > 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. > Thanks, > Sharan > > > -----Original Message----- > From: owner-openssl-us...@openssl.org > [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson > Sent: Thursday, October 11, 2012 1:18 AM > To: openssl-users@openssl.org > Subject: RE: SSL Certificate cache > > > From: owner-openssl-us...@openssl.org On Behalf Of Sharanagoud B D > > Sent: Tuesday, 09 October, 2012 06:25 > > > How to check in Linux client device whether the certificate used is > > cached or it's from the server? I am using openssl s_client to > > establish http connection. > > > By "the certificate used" do you mean the server's cert? > That must always be sent by the server; even if the client > has a copy already, the client does not know which one it is. > (It is *not* required that the same server name, or address, > always use the same key+cert, and some don't.) > > If you mean chain certs above entity and below root: > - you can see what the server sends with -showcerts on s_client > - s_client uses openssl's standard truststore, a file and/or > directory in specified or default locations. You can look at > that file and/or directory to see what certs are in it. > - verification is the same either way; so it shouldn't > matter, unless there are multiple certs for the same CA > subject. Public CAs generally change subject for new > generation etc., but sometimes reuse subject to lengthen > validity of an existing subtree or provide an alternate (or > just changed) trust path to a subtree. > > If the server sends the root cert for its cert, openssl > client including s_client doesn't use it. openssl only trusts > roots in its local truststore. > > OTOH if you mean a *client* cert -- used for client auth, > which is rare -- s_client uses only a cert explicitly > specified on the command line, and you know what you specified. > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
