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 s
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 ssl
> 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) C>S
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) C>S SSLv2 compatible client hello
Ver
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... ssldum
