On 12/11/06, Marek Marcola [EMAIL PROTECTED] wrote:
It almost seems like the server is accepted SSL3 msgs, but sending out
another protocol type. Any suggestions?
If you using Linux, can you send ssldump or wireshark dump
of this session.
Here is an ssldump of s_client connecting to my
On 12/11/06, chris busbey [EMAIL PROTECTED] wrote:
On 12/11/06, Marek Marcola [EMAIL PROTECTED] wrote:
It almost seems like the server is accepted SSL3 msgs, but sending out
another protocol type. Any suggestions?
If you using Linux, can you send ssldump or wireshark dump
of this session
Another trial forcing tls1 on both sides of the connection did not
result in the above Length Mismatch error. Here is the output of
that trial's ssl dump. Any thoughts?
New TCP connection #67: localhost.localdomain(42489) -
localhost.localdomain(5758)
67 1 0.0032 (0.0032) CSV3.1(95)
On 12/11/06, Marek Marcola [EMAIL PROTECTED] wrote:
Can you send ssldump with -aAdN options ?
Certainly. (Certificate details have been obfuscated)
New TCP connection #8: localhost.localdomain(48429) -
localhost.localdomain(5758)
8 1 0.0028 (0.0028) CS SSLv2 compatible client hello
Version
On 12/11/06, Marek Marcola [EMAIL PROTECTED] wrote:
This TLS1 looks good, but sorry I've forget xX options,
so output from ssldump -aAdNxX should give more information
(SSL packet dump) with ending error.
Hrm... ssldump fails during the handshake with a 'Length Mismatch
error with the xX
A quick update on this issue. After digging through some untouched
code, I discovered that the server was writing data directly to the
port instead of the SSL_SOCK_Stream. Problem solved. Thanks for all
of your help.
On 12/11/06, Marek Marcola [EMAIL PROTECTED] wrote:
Hello,
Hrm... ssldump
