Open databeille opened 9 years ago
Server side log :
(dbg) [2551] received handle on ipc (dbg) [2551] client 0x23835d0 on backend connecting to 127.0.0.1:81 (dbg) [2551] client 0x23835d0 on frontend new (dbg) [2551] client 0x23835d0 on frontend after read_cb() => 74 (dbg) [2551] client 0x23835d0 on frontend SSL_read() => -1 (dbg) [2551] client 0x23835d0 on frontend uv_write(5240) iovcnt: 1 (dbg) [2551] client 0x23835d0 on frontend immediate write (dbg) [2551] client 0x23835d0 on frontend write_cb => 5240 (dbg) [2551] client 0x23835d0 on frontend recycle (dbg) [2551] client 0x23835d0 on frontend SSL_read() => -1 (dbg) [2551] client 0x23835d0 on backend connect 0 (dbg) [2551] client 0x23835d0 on frontend SSL_read() => -1 (dbg) [2551] client 0x23835d0 on frontend after read_cb() => -104 (dbg) [2551] client 0x23835d0 on frontend SSL_read() => -1 (ntc) [2551] client 0x23835d0 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer) (dbg) [2551] client 0x23835d0 on frontend force closing (and waiting for other) (dbg) [2551] client 0x23835d0 on backend force closing (and waiting for other) (dbg) [2551] client 0x23835d0 on frontend close_cb
@databeille it seems that CyaSSL doesn't like something about ServerHello packet that OpenSSL sends. Will look into it.
Could you please help me by providing some instructions on how to build cyassl and reproduce the problem?
@indutny, I used stud (https://github.com/bumptech/stud) before switching to bud-tls. It seems to me stud is built with openSSL libs. The -weird- fact is cyaSSL works with stud.
To build cyaSSL and have some tools for testing, you could refer to my first post ("Steps to reproduce").
Let me know if you need special instructions for a particular system (I can testbuild on [Fedora 20|Centos 6.6] x86_64, Lubuntu 14.04 x86, and cross-compile for openWRT BB arch:ar71xx).
Oh gosh, sorry! I missed Steps to reproduce
@databeille may I ask you to paste your bud configuration? I'm failing to reproduce this locally...
Sure !
{ "workers": 3, "restart_timeout": 250, "log": { "level": "debug", "facility": "user", "stdio": true, "syslog": true }, "availability": { "max_retries": 5, "retry_interval": 250, "death_timeout": 1000, "revive_interval": 2500 }, "frontend": { "port": 443, "host": "0.0.0.0", "keepalive": 600, "proxyline": false, "security": "ssl23", "server_preference": true, "ssl3": false, "ciphers": "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:DES-CBC3-SHA", "ecdh": "prime256v1", "dh": "/etc/ssl/certs/whatever.databeille.com/dh.key", "ticket_key": "BbWNdEp/LWaOiCbnVjX/KfFk28EAJO3TZfBh97BOhvYK+bhZONZ0wG9Y0Qz7r2rA", "ticket_timeout": 300, "npn": [ "http/1.1", "http/1.0" ], "cert": "/etc/ssl/certs/whatever.databeille.com/array3.pem", "key": "/etc/ssl/certs/whatever.databeille.com/whatever.databeille.com.key", "passphrase": null, "reneg_window": 300, "reneg_limit": 3, "max_send_fragment": 1400, "allow_half_open": false, "request_cert": false, "ca": "/etc/ssl/certs/whatever.databeille.com/array3.pem" }, "backend": [ { "port": 81, "host": "127.0.0.1", "keepalive": 360, "x-forward": true } ], "sni": { "enabled": false, "port": 9000, "host": "127.0.0.1", "query": "/bud/sni/%s" }, "stapling": { "enabled": false, "port": 9000, "host": "127.0.0.1", "query": "/bud/stapling/%s" } }
When using cyaSSL (https://github.com/cyassl/cyassl) as a client, I get an error code returned, saying "INCOMPLETE_DATA". Any way, bud-tls works as expected. It is the first time I encounter such a problem.
In cyaSSL, the "INCOMPLETE_DATA" error is related to :
in src/internal.c.