On Tue, Feb 24, 2015 at 01:33:32PM -0700, NuSkooler wrote:
Thanks, this has all been very helpful.
Unfortunately it seems that some of the pieces to create a debuggable
version of these old clients are currently missing here. If I can get
that together I'll debug and hopefully find
Thanks, this has all been very helpful.
Unfortunately it seems that some of the pieces to create a debuggable
version of these old clients are currently missing here. If I can get
that together I'll debug and hopefully find something. Until then,
we'll be attempting to route their traffic around
Attached are two captures:
1) ha_lukas-allow-allow.pcap: This is a capture of the bind line you provided:
bind *:443 ssl crt /home/bashby/Lukas/TEST_cert_and_key.pem ciphers \
AES128-SHA verify optional ca-ignore-err all crt-ignore-err all ca-file \
/etc/ssl/certs/cw_client_ca.pem
2)
Hi,
On Tue, Feb 24, 2015 at 01:33:32PM -0700, NuSkooler wrote:
Thanks, this has all been very helpful.
Unfortunately it seems that some of the pieces to create a debuggable
version of these old clients are currently missing here. If I can get
that together I'll debug and hopefully find
I'm not currently sure on the JRE version. These are Android clients
written with a old Android SDK. All new clients are C++ / OpenSSL
based.
I have set the DH param size to 1024 with the same results.
Additionally, I set up a bind statement that reflects that of the
backward compatibility link
I have since set DH to 1024 in my configuration. Here is the results
from cipherscan:
Target: 10.3.2.74:443
prio ciphersuite protocols pfs_keysize
1 AES128-SHA TLSv1,TLSv1.1,TLSv1.2
2 DHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
Certificate:
Thanks for updating the subject -- this does seem to be SSL/handshake
related. I'm pretty confident that these are just bad clients that
were getting away with whatever they're doing on the old Mochiweb SSL
setup. As a last resort we're coming up with a backup plan on routing
them to the old setup
Attached is a pcap with the bind line cut+paste from your link.
In this case I see Encrypted Alert, but I'm struggling to decrypt it
in WS with this setup.
Ok, so as expected, this didn't really change anything, but at least
we have a config/capture consistency.
Now, it looks like the client
The TLS handshake is working fine. The issue is that HAProxy is trying
to speak SPDY
with your clients, and they most likely don't support it.
In the Haproxy_1 capture, look at packet #61 send by haproxy to the
client. The application
data protocol is set to SPDY. Is this the expected behavior
We do not expect SPDY to be used, no. The expected behavior is HTTP on
TLS with JSON-RPC payloads (POST/response body).
Perhaps I'm not reading something right here: Looking at #61 in
Wireshark, I see the following:
61 16.127749 10.3.2.74 10.1.1.93 TLSv1 279 Application Data
TLSv1 Record Layer:
Hi,
I'm not currently sure on the JRE version. These are Android clients
written with a old Android SDK. All new clients are C++ / OpenSSL
based.
I have set the DH param size to 1024 with the same results.
Additionally, I set up a bind statement that reflects that of the
backward
Do you use any reqrep/resprep rules? I'm asking because I had the same kind
of problem, also with java apps.
First I changed the global section to:
tune.ssl.default-dh-param 1024
ssl-default-bind-ciphers
EECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL
Attached is a pcap with the bind line cut+paste from your link.
In this case I see Encrypted Alert, but I'm struggling to decrypt it
in WS with this setup.
On Mon, Feb 23, 2015 at 11:36 AM, Lukas Tribus luky...@hotmail.com wrote:
There's some confusion here.
For the sake of clarity, please,
A bit late to this discussion but the issues sound familiar.
I've seen this type of issue in the past between openssl and java's ssl
implementation, primarily in java 6 and java 7. I don't remember the
full details but from what I recall avoiding the EC based ciphers from
the supported list
On 23/02/2015 10:55 μμ, NuSkooler wrote:
Attached is the information you requested -- and hopefully performed
correctly :)
* no_haproxy.pcap: This is a successful connection + POST to the
original Mochiweb server. Note that here the port is 8443 not 443
(IP=10.3.3.3)
* ha_self_signed.pcap:
Attached is the information you requested -- and hopefully performed
correctly :)
* no_haproxy.pcap: This is a successful connection + POST to the
original Mochiweb server. Note that here the port is 8443 not 443
(IP=10.3.3.3)
* ha_self_signed.pcap: Failed attempt against HAProxy with a self
Hi all,
I'm only reposting below Lukas' mail without mixed text/plain
Content-Type and html inside, in case someone couldn't read it ;-)
Le 24/02/2015 01:04, Lukas Tribus a écrit :
Attached is the information you requested -- and hopefully performed
correctly :)
* no_haproxy.pcap: This is a
gt; Attached is the information you requested -- and hopefully
performedbrgt; correctly :)brgt;brgt; * no_haproxy.pcap: This is a
successful connection + POST to thebrgt; original Mochiweb server. Note that
here the port is 8443 not 443brgt; (IP=10.3.3.3)brgt; *
ha_self_signed.pcap: Failed
I apologize, the email was destroyed by the mailer...
Attached is the information you requested -- and hopefully performed
correctly :)
* no_haproxy.pcap: This is a successful connection + POST to the
original Mochiweb server. Note that here the port is 8443 not 443
(IP=10.3.3.3)
*
On 2015-02-21 05:15, Lukas Tribus wrote:
Out of the blue, I would suggest to make sure DH params for DHE
ciphers
are fixed to 1024 bit (known Java limitation to only support 1024 bit
with
DHE ciphers in the older releases) - this can be either in the
certificate
file or generated by haproxy at
Hi,
Since we can't even properly connect to s_server, that may be the end
of the road for those clients. However, I'm hoping there may be
something that could be configured to allow them through HAProxy.
Below is a s_server log. Note the read failure at the end. A similar
capture in the view
21 matches
Mail list logo
