> From: [email protected] On Behalf Of Kurt Roeckx
> Sent: Tuesday, 18 June, 2013 18:50
> On Tue, Jun 18, 2013 at 05:25:06PM -0400, Dave Thompson wrote:
> > > My conclussions:
> > > - One of the 2 sides doesn't implement
> > > DES-CBC-SHA/DES-CBC3-SHA properly
> >
> > ... I think you're right and I suspect the other side because
> > openssl interoperates with lots of folks -- unless there's
> > something badly off in your build of openssl. Can you
> > connect with DES-CBC3-SHA to usual suspects like google?
>
> With google I get:
> Protocol : TLSv1.2
> Cipher : DES-CBC3-SHA
>
> (Or by default)
> Protocol : TLSv1.2
> Cipher : ECDHE-RSA-AES128-GCM-SHA256
>
> Both of course work as expected.
>
And is able to send and receive data? I forgot to ask that.
For an https server send "GET / HTTP/1.0\r\n\r\n" (I feed
from a file or echo| since it's hard to type that in) and
look for HTTP headers (followed by something HTMLish).
If so, your openssl is doing DES-CBC3 right; see below.
> > I think commandline nowadays picks up engines from openssl.cnf
> > even if you don't explicitly ask -- do you have any configured?
>
> There are no engines configured.
>
(That was just in case you got the cipher implementation
from someplace other than openssl itself.)
> > If you didn't build from source, can you try that?
>
> Enable engines? Which ones?
>
I didn't mean engines, I meant build from source, to be sure
you're running as-distributed code for the affected cipher.
But if you can communicate with e.g. google that's enough.
> PS: Are you unable to reproduce this? I can reproduce this with
> various sites including things like smtp.live.com.
>
I can't reproduce any starttls smtp; I suspecvt our provider
has done something to port 25 probably on the theory they're
fighting spam. I get banner which is clearly masked and
EHLO/250 response which is clearly altered, and STARTTLS
is rejected with various 5xx. If you have a server that
handles clear+STARTTLS on a different port I can try it.
I can do *https* 443 DES-CBC3 fine in 1.0.1e, and others.
One logical but unpleasant theory is that s_client starttls
code clobbers something that screws up DES-CBC3 but not RC4.
That would be quite a pain to debug. It's a little work, but
what I would try first is a simplified replacement for s_client,
without the bells and whistles especially nonblocking, like:
// add error checking to taste
ctx=SSL_CTX_new()
// set verify_locations, ciphers, etc, as desired
ssl=SSL_new(ctx)
ipaddr=gethostaddr("whatever")
s=socket()
connect(s,iapddr_and_port)
bio=push bufferBIO on socketBIO for s // easier to manage
BIO_gets for 220
BIO_puts "EHLO...\r\n"
BIO_gets until 250-no-hyphen looking for STARTTLS
BIO_puts "STARTTLS\r\n"
BIO_gets for 220
SSL_set_bio(ssl,bio,bio)
SSL_connect
SSL_write "AUTH...\r\n" // or whatever
SSL_read and look for valid lines
// continue until done
If that works, the problem is pretty definitely s_client.
If that fails, and on more than one or a few servers,
I don't know what to think.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
