> From: owner-openssl-us...@openssl.org On Behalf Of Gayathri Sundar > Sent: Monday, 16 May, 2011 10:18
> You could hack ur client and server to use cipher null and see the > alert in clear..most,y should be digest failure. > If you mean MAC failure (actually MAC-or-decryption-failure, since they were combined to avoid possibly helping an attacker), that should *never* happen unless there is a bug at either peer or actual tampering in the communication channel. It could also be close-notify. That's the only alert that should normally occur after handshake. > On Monday, May 16, 2011, pradeepreddy > <pradeepreddy....@gmail.com> wrote: > > After lot of struggles, finally get rid of this error, but > I cant tell the > > reason, how was it rectified. > > We installed our libs on a new machine. > > > > Now a different error is seen. > > > > After client and server conection is established, TLSv1 > Encrypted Alert+21 > > is sent by the client. > > As shown by wireshark, I assume. Immediately after Finished (which wireshark is only able to shows as 'encrypted handshake message' 'contenttype:22')? Or after more data? Or a time delay (maybe timeout)? Yes, alerts are encrypted once handshake is completed. Aside from using a null cipher as suggested above, so the encrypted alert (and any other data) is readable: - does either your client or server or both log or display anything about the error? - if not, can you substitute s_server for the real server? It does display/log any error alert. But this will only work if the client is spontaneously sending the alert without waiting for or needing any data the real server sends. <snip rest> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
