> 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
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
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 H
> 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 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
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)
> *
> 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
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
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 resol
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
signe
> 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 cli
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 wrote:
> There's some confusion here.
>
> For the sake of clarity, please, for the time bein
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
ssl-default-bind-op
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 co
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: Ap
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
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
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: UNTRU
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 yo
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
Hi,
I've modified the subject so that people with SSL skills notice it.
On Sat, Feb 21, 2015 at 02:06:51AM +0100, Baptiste wrote:
> On Sat, Feb 21, 2015 at 12:39 AM, NuSkooler wrote:
> > Some additional gritty details:
> > * socat 'show errors' shows 0 errors
> > * The same bad clients fail to c
22 matches
Mail list logo