RE: Spam

[Andrei Marinescu]

Same here, only 1-2 messages per week, and generally correctly tagged as
[SPAM]. Way less than the last discussion on this topic produced :)

 

From: Kobus Bensch [mailto:kobus.ben...@trustpayglobal.com] 
Sent: vineri, 19 iunie 2015 12:06
To: haproxy@formilux.org
Subject: Re: Spam

 

I dont get any.

On 19/06/2015 07:38, Roger Sikorski wrote:

Hello,

 

It is possibly to stop the spam which arrives here in the mailing list
often?

 

Greetings

Roger

 



Roger Sikorski


Auszubildender Fachinformatiker Systemintegration


R&R Ice Cream Deutschland GmbH 


Eduard Pestel Str. 15


49080 Osnabrück





 Fax: +49 541  301 



  www.rr-icecream.eu


roger.sikor...@de.rr-icecream.eu  

 

Handelsregister Amtsgericht Osnabrück HRB 17067 Sitz der Gesellschaft:
Osnabrück Ident Nr. DE 117657534 Geschäftsführer: Dr. Ibrahim Najafi, Dr.
Gotthard Kirchner

P Before you print think about the ENVIRONMENT 

 



This e-mail has been scanned for viruses by R&R Ice Cream.
The service is powered by MessageLabs.


 

-- 
Kobus Bensch
Senior Systems Administrator
Address:  22 & 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD
DDI:  0207 871 3958
Tel:  0207 871 3890
Email:  kobus.ben...@trustpayglobal.com
 


 

Trustpay Global Limited is an authorised Electronic Money Institution
regulated by the Financial Conduct Authority registration number 900043.
Company No 07427913 Registered in England and Wales with registered address
130 Wood Street, London, EC2V 6DL, United Kingdom.

For further details please visit our website at www.trustpayglobal.com
 .

The information in this email and any attachments are confidential and
remain the property of Trustpay Global Ltd unless agreed by contract. It is
intended solely for the person to whom or the entity to which it is
addressed. If you are not the intended recipient you may not use, disclose,
copy, distribute, print or rely on the content of this email or its
attachments. If this email has been received by you in error please advise
the sender and delete the email from your system. Trustpay Global Ltd does
not accept any liability for any personal view expressed in this message.

Re: email alerts

[Andrei Marinescu]

Hi everyone,

I know that this has been discussed on this list before. I'm using this 
hosted service, that works quite well for alerting when backends are 
down: https://aura.snapt.net/


Best,

Andrei

Maik Kulbe wrote:

Hi,

that patch is for an older version of HAProxy. I would suggest you to 
monitor the logs or the stats socket as mentioned in the article. With 
a monitoring system like Nagios plus the socket interface you could 
also send those mails in case something goes down or up.



Hi!
I use HA-Proxy version 1.5.6 2014/10/18/ . Red hat 6.

I want use alert via mail. I find informations about this:
---
Patch HAProxy
So this brings us on to option 3 patch HAProxy to send the alerts, after
all how hard can it be?
As I don’t really want to write my own SMTP client or use any other
library’s lets go with the easy option of using mailx from the
mailutils package as we know it works. The following was written for
HAProxy dev18. Now I’m no developer so take the code more of a proof
of concept instead of something to add to your production environment.

Most of the work is already done for us, as HAProxy has functions for
setting a server up or down and also has an array containing the server
name, server’s status etc. So all we need to do is add our own
function to send the email and parse the email address from the
configuration file.

This done in the following patch files:
cfgparse.c
checks.c
log.c
global.h

So in the configuration file I have added the option “email_alert”
to the global section with to and from address.
http://blog.loadbalancer.org/3-ways-to-send-haproxy-health-check-email-alerts/ 


-

I try add text from patch file in the end original file and make haproxy
file.
/opt/haproxy/global.h.diff >> /opt/haproxy/include/types/global.h

cat /opt/haproxy/cfgparse.diff
>>/opt/haproxy/haproxy-1.5.6/src/cfgparse.c

cat /opt/haproxy/log.diff >>/opt/haproxy/haproxy-1.5.6/src/log.c

cat /opt/haproxy/checks.diff >>/opt/haproxy/haproxy-1.5.6/src/checks.c


And while compiling I have error:

[webadmin@srv-lb-qa haproxy-1.5.6_with_diff]$ make TARGET=linux2628
CPU=generic
gcc -Iinclude -Iebtree -Wall  -O2 -g -fno-strict-aliasing
-DCONFIG_HAP_LINUX_SPLICE -DTPROXY -DCONFIG_HAP_LINUX_TPROXY
-DCONFIG_HAP_CRYPT -DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY
-DASSUME_SPLICE_WORKS -DUSE_ACCEPT4 -DNETFILTER -DUSE_GETSOCKNAME
-DCONFIG_HAPROXY_VERSION=\"1.5.6\" -DCONFIG_HAPROXY_DATE=\"2014/10/18\"
\
  -DBUILD_TARGET='"linux2628"' \
  -DBUILD_ARCH='""' \
  -DBUILD_CPU='"generic"' \
  -DBUILD_CC='"gcc"' \
  -DBUILD_CFLAGS='"-O2 -g -fno-strict-aliasing"' \
  -DBUILD_OPTIONS='""' \
   -c -o src/haproxy.o src/haproxy.c
In file included from include/proto/proxy.h:28,
 from include/common/cfgparse.h:30,
 from src/haproxy.c:61:
include/types/global.h:207: error: expected identifier or ‘(’ before
‘--’ token
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:213: error: expected identifier or ‘(’ before
‘+’ token
include/types/global.h:215: error: expected identifier or ‘(’ before
‘+’ token
include/types/global.h:216: error: expected identifier or ‘(’ before
‘+’ token
In file included from src/haproxy.c:76:
include/types/global.h:207: error: expected identifier or ‘(’ before
‘--’ token
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:213: error: expected identifier or ‘(’ before
‘+’ token
include/types/global.h:215: error: expected identifier or ‘(’ before
‘+’ token
include/types/global.h:216: error: expected identifier or ‘(’ before
‘+’ token
In file included from include/proto/channel.h:35,
 from src/haproxy.c:85:
include/types/global.h:207: error: expected identifier or ‘(’ before
‘--’ token
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:209: error: stray ‘@’ in program
include/types/global.h:213: error: expected identifier or ‘(’ before
‘+’ token
include/types/global.h:215: error: expected identifier or ‘(’ before
‘+’ token
include/types/global.h:216: error: expected identifier or ‘(’ before
‘+’ token
make: *** [src/haproxy.o] Error 1



Pls help me! I don't know how use patch(

Re: HAProxy Next?

[Andrei Marinescu]

Hi everyone,

Sorry if it's not my place to do this, but I just wanted to upvote 
Annika's idea about latency metrics in the stats interface. Also, if 
there's a workaround already available for easily measuring these 
metrics, I would love to know more.

Best regards to everyone!

Andrei

   	   
   	Annika Wickert  
  17 Dec 2013 11:01
  Hi

Hi!



- sflow output
Can't log-format already do this?
Sure, but it might be a better integration in the rest of networking infrastructure if sflow is supported.
FYI, Neil Mckee has a fork available with sflow support:

http://marc.info/?t=13673552702&r=1&w=2
http://blog.sflow.com/2013/05/haproxy.html
https://github.com/sflow/haproxy

I know ;). So it would be nice to merge to code in the official release :).


Regards,

Lukas 		 	   		  

Regards,
Annika

   	   
   	Lukas Tribus  
  17 Dec 2013 10:50
  Hi!FYI,
 Neil Mckee has a fork available with sflow support:http://marc.info/?t=13673552702&r=1&w=2http://blog.sflow.com/2013/05/haproxy.htmlhttps://github.com/sflow/haproxyRegards,Lukas
 		 	   		  
   	   
   	Annika Wickert  
  17 Dec 2013 10:14
  



Hi all,


we did some thinking about how to improve haproxy and which 
features we’d like to see in next versions.


We came up with the following list and would like to discuss if 
they can be done/should be done or not.
- One global statssocket which can be switched through to see stats
 of every bind process. And also an overall overview summed up from all 
backends and frontends.
- One global control socket to control every backend server and set
 them inactive or active on the fly.
- In general better nbproc > 1 support
- Include possibility in configfile to maintain one configfile for 
each backend / frontend pair
- CPU pinning in haproxy without manually using taskset/cpuset
- sflow output
- latency metrics at stats interface (frontend and backend, avg, 
95%, 90%, max, min)
- accesslist for statssocket or ldap authentication for stats 
socket


Are there any others things which would be cool? I hope we can have
 a nice discussion about a “fancy” feature set which could be provided 
by lovely haproxy.


Best regards,
Annika
 



---
Systemadministration


Travian Games GmbH
Wilhelm-Wagenfeld-Str. 22
80807 München
Germany


a.wick...@traviangames.com
www.traviangames.de


Sitz der Gesellschaft München
AG München HRB: 173511
Geschäftsführer: Siegfried Müller
USt-IdNr.: DE246258085


Diese Email einschließlich ihrer 
Anlagen ist vertraulich und nur für den
Adressaten bestimmt. Wenn Sie nicht
 der vorgesehene Empfänger sind,
bitten wir Sie, diese Email mit 
Anlagen unverzüglich und vollständig zu
löschen und uns umgehend zu 
benachrichtigen.


This email and its attachments are 
strictly confidential and are
intended solely for the attention 
of the person to whom it is addressed.
If you are not the intended 
recipient of this email, please delete it
including its attachments 
immediately and inform us accordingly.




  

Using HAProxy with ZeroMQ

[Andrei Marinescu]

Hello everyone,

I was wondering if anyone here has experience running 0MQ traffic 
through HAProxy in TCP mode? I'm trying to balance traffic for PUB & 
ROUTER sockets on the backend, frontend will connect through SUB & 
DEALER sockets.


I was thinking about something like this for the listener:
mode tcp
balance source

Does anyone have any caveats / best practice for this use case?

Thanks,

Andrei

Re: SSL Handshake errors

[Andrei Marinescu]

I finally managed to track
 down the issue, the cause was much simpler than I had thought.

 As I've mentioned before, the service exposed through this
HAProxy instance is mainly accessed by mobile devices. The errors
appeared when apps where closed (either manually or because of a crash) 
when a HTTPS connection was being
established (we're doing a final API call when the app is being closed, 
for
example). I've managed to replicate this behavior reliably.
This also triggered some BADREQ errors, if the SSL connection was 
established but no data was ever sent.
The reason that we didn't detect this earlier was that AWS ELB 
didn't
offer any logging, and the CloudWatch metrics where for HTTP return
statuses (2XX, 4XX&5XX). Of course, these cases didn't  trigger any 
of
those. 
  
  
Thanks again to everyone for your support!
  
Best,
  
Andrei


   	   
   	Emeric Brun  
  July 8, 2013 
12:29 PM
  On 07/08/2013 11:06 AM, Andrei 
Marinescu wrote:
Hi Lukas,

Unfortunately I'm not able to reproduce this on any of the devices I
have access to, I'm just seeing these erros in the logs and I'm 
trying
to track down the issue. I guess I'll try to find an easy to 
reproduce
scenario and return with a cap file at that time.

Just so that I can delete one possibility from my list, is it 
possible
that some devices reject the certificate I'm using? I'm thinking of 
this
because I ran into an issue with this CA on another server (a 
payment
gateway wouldn't connect over HTTPS, problem solved by changing the
cert). 99% of the devices connecting to this endpoint are Android 
and
iOS devices, and given the fragmentation that Android is suffering 
of
this wouldn't suprise me.

Thanks everyone!

Best,

Andrei
Lukas Tribus 

July 8, 2013 11:46 AM
Hi Andrei,


I only see a single session of that IP in the cap file.

What we can see from the dump is:
- the client provides both a TLS session ticket and a session ID
- the server acknowledges the session ID
- the server sends a "Change Cipher Spec" message [1]
- the client disconnects

I don't think this is enough information to draw a conclusion. A 
wild
guess could be that the client gets upset about the Change Cipher 
Spec
message, but that is really a very wild guess.

We would need to see the session before and after this one, to be 
able to
put them in context. Any additional informations about the 
User-Agent
would
certainly also help.

Btw, can you clearly reproduce this, or is this a random session 
failed on
your prodution box?



Regards,

Lukas

[1]
http://de.wikipedia.org/wiki/Transport_Layer_Security#TLS_Change_Cipher_Spec_Protocol

Willy Tarreau 
July 8, 2013 9:40 AM
Hello Andrei,

That would definitely help, in order to pass it via ssldump. Or you 
can
do it yourself as well. What I'm seeing anyway (-q wasn't the most 
helpful
option here :-)) is that the client closes first. The sequence looks
 like
this :

client SYN server
port 58713 ---> :443
SYN/ACK
<---
ACK
--->
PSH: TLSv1 client hello with SNI
--->
PSH: TLSv1 server hello
<---
FIN: client decides to close
--->
FIN: server acknowledges and closes
<---
RST: client had already closed
--->

So in short, the client disagrees with what the server proposed. 
Either
it's because of the algorithms in use, or because something is 
missing.
For example, I'm not seeing any certificate presented by the server,
 so
it looks like session resumption.

Ssldump would tell us what algorithms were negociated in each 
direction.
You can also try with tshark/wireshark I think.

Best regards,
Willy

Andrei Marinescu 
July 8, 2013 9:16 AM
Hello Willy,

Thank you for your answer! I've attached a dump with two requests 
from
the same ip. First one failed with Connection closed during SSL
handshake, the second one failed with Timeout during SSL handshake.

I've translated the .cap file with tcpdump -qns 0 -X -r file.cap 
>
translated.cap in order to make the dump readable and extract the 
two
requests. If the original dump is needed, let me know and I'll 
attach
it a.s.a.p.


Willy Tarreau 
July 7, 2013 10:02 PM
Hello Andrei,

It's very hard to suggest anything unfortunately, since most SSL/TLS
errors
can be very cryptic. It would be nice if you could take a pcap 
capture of
one such faulty connection so that we can see the whole handshake 
and try
to find what the issue is. Many things can be involved, including
versions,
algorithms, key sizes, etc...

In order to take this capture, please use "tcpdump -s0 -npi eth0 -w
file.cap"
to ensure that packets are not truncated. If you'd prefer not to
reveal your
public IP address on the list, then please send me the capture in 
private.
But I must say that p

Re: SSL problem with old browsers

[Andrei Marinescu]

Jürgen,
  
I can confirm the same issue you're having in the case of older versions
 of Android 2.3. It seems this is related to SNI support (you can check a
 full list of platforms supporting SNI here: 
http://en.wikipedia.org/wiki/Server_Name_Indication).
  
Unfortunately the only workaround I found for now was using two separate
 HAProxy instances for the front-ends. If you can assign two public IP's
 to your server, you could bind to each of them and separate access this
 way.
  


   	   
   	Jürgen Haas  
  July 8, 2013 7:50
 PM
  This is a follow-up 
question to the other thread "SSL Problem -Untrusted Connection" 
which has meanwhile been resolved, thanks to Lukasand Duncan. My PEM
 files are now working properly.Here is what I have in the 
config file:frontend https-in  bind :443 ssl crt 
/var/proxy/certs/fallback.pem crt /var/proxy/certs/domain1.pem crt 
/var/proxy/certs/domain2.pem  use_backend ssl_backendNow, 
when calling https://domain1 this works from all modern platformsand
 browsers. But a lot customers with older equipment (i.e. most ofthem
 from within banking networks - no kidding) are reporting that theirbrowser
 (IE8 on XP as an example) is warning them when visiting domain1on 
SSL. As I couldn't reproduce that problem from elsewhere, I justinstalled
 XP and IE8 and bang, yes I get the same warning.What happens is
 that HAProxy is using the fallback certificate.When I remove 
that and only have this config:frontend https-in  bind :443 
ssl crt /var/proxy/certs/domain1.pem  use_backend ssl_backendThen
 everything works also on older systems.I think, from that we 
can assume that the certificates are just fine.But something with 
HAProxy seems not quite right for all circumstancesif there are more
 than one CRTs in one bind statement.If anyone needed an 
environment for testing and reproduction, please letme know. I can 
provide more infos or even access to our system if that'snecessary.ThanksJürgen


-- Andrei Marinescu -- co-founder
Appscend - The Mobile Experience Igniter

Calea Plevnei 46-48, Bucharest, Romania
phone: +4 0742 896 394
email: and...@appscend.com 

Re: SSL Handshake errors

[Andrei Marinescu]

Hi Lukas,

Unfortunately I'm not able to reproduce this on any of the devices I 
have access to, I'm just seeing these erros in the logs and I'm trying 
to track down the issue. I guess I'll try to find an easy to reproduce 
scenario and return with a cap file at that time.

Just so that I can delete one possibility from my list, is it possible 
that some devices reject the certificate I'm using? I'm thinking of this
 because I ran into an issue with this CA on another server (a payment 
gateway wouldn't connect over HTTPS, problem solved by changing the 
cert). 99% of the devices connecting to this endpoint are Android and 
iOS devices, and given the fragmentation that Android is suffering of 
this wouldn't suprise me.

Thanks everyone!

Best,

Andrei

   	   
   	Lukas Tribus  
  July 8, 2013 
11:46 AM
  Hi Andrei,I
 only see a single session of that IP in the cap file.What we 
can see from the dump is:- the client provides both a TLS session 
ticket and a session ID- the server acknowledges the session ID-
 the server sends a "Change Cipher Spec" message [1]- the client 
disconnectsI don't think this is enough information to draw a 
conclusion. A wildguess could be that the client gets upset about 
the Change Cipher Specmessage, but that is really a very wild guess.We
 would need to see the session before and after this one, to be able toput
 them in context. Any additional informations about the User-Agent wouldcertainly
 also help.Btw, can you clearly reproduce this, or is this a 
random session failed onyour prodution box?Regards,Lukas[1]
 
http://de.wikipedia.org/wiki/Transport_Layer_Security#TLS_Change_Cipher_Spec_Protocol
 		 	   		  
   	   
   	Willy Tarreau  
  July 8, 2013 9:40
 AM
  Hello Andrei,That
 would definitely help, in order to pass it via ssldump. Or you cando
 it yourself as well. What I'm seeing anyway (-q wasn't the most helpfuloption
 here :-)) is that the client closes first. The sequence looks likethis
 : client SYN server  port 58713
   ---> :443  SYN/ACK
  <---ACK
  --->  PSH: TLSv1 client
 hello with SNI  --->
   PSH: TLSv1 server hello  
<---FIN: client decides to close
  --->FIN: server 
acknowledges and closes  <---
RST: client had already closed  
--->So in short, the client disagrees 
with what the server proposed. Eitherit's because of the algorithms 
in use, or because something is missing.For example, I'm not seeing 
any certificate presented by the server, soit looks like session 
resumption.Ssldump would tell us what algorithms were negociated
 in each direction.You can also try with tshark/wireshark I think.Best
 regards,Willy
   	   
   	Andrei Marinescu  
  July 8, 2013 9:16
 AM
  

Hello Willy,

Thank you for your answer! I've attached a dump with two requests from 
the same ip. First one failed with Connection closed during SSL 
handshake, the second one failed with Timeout during SSL handshake.

I've translated the .cap file with tcpdump -qns 0 -X -r file.cap > 
translated.cap in order to make the dump readable and extract the two 
requests. If the original dump is needed, let me know and I'll attach it
 a.s.a.p.




  
   	   
   	Willy Tarreau  
  July 7, 2013 
10:02 PM
  Hello Andrei,It's
 very hard to suggest anything unfortunately, since most SSL/TLS errorscan
 be very cryptic. It would be nice if you could take a pcap capture ofone
 such faulty connection so that we can see the whole handshake and tryto
 find what the issue is. Many things can be involved, including 
versions,algorithms, key sizes, etc...In order to take this 
capture, please use "tcpdump -s0 -npi eth0 -w file.cap"to ensure 
that packets are not truncated. If you'd prefer not to reveal your public
 IP address on the list, then please send me the capture in private.But
 I must say that people here on the list tend to read SSL traces fasterthan
 me :-)Regards,Willy
   	   
   	Andrei Marinescu  
  July 7, 2013 6:08
 PM
  

Hello everyone!
  
I've moved off AWS ELB today to HAProxy 1.5dev18. I'm doing SSL 
termination at the LB and I'm encountering a rather large number of 
messages such as:
- SSL Handshake failure
- Timeout during SSL handshake
- Connection closed during SSL handshake
  
The problem is similar to the one I've found in the archives about 2 
weeks ago (http://marc.info/?l=haproxy&m=137158875803495&w=2),
 
but unfortunately I'm unable to debug this. I'm trying to clarify if 
these are errors that are normal and I 

Re: SSL Handshake errors

[Andrei Marinescu]

Hello Willy,

Thank you for your answer! I've attached a dump with two requests from 
the same ip. First one failed with Connection closed during SSL 
handshake, the second one failed with Timeout during SSL handshake.

I've translated the .cap file with tcpdump -qns 0 -X -r file.cap > 
translated.cap in order to make the dump readable and extract the two 
requests. If the original dump is needed, let me know and I'll attach it
 a.s.a.p.


   	   
   	Willy Tarreau  
  July 7, 2013 
10:02 PM
  Hello Andrei,It's
 very hard to suggest anything unfortunately, since most SSL/TLS errorscan
 be very cryptic. It would be nice if you could take a pcap capture ofone
 such faulty connection so that we can see the whole handshake and tryto
 find what the issue is. Many things can be involved, including 
versions,algorithms, key sizes, etc...In order to take this 
capture, please use "tcpdump -s0 -npi eth0 -w file.cap"to ensure 
that packets are not truncated. If you'd prefer not to reveal your public
 IP address on the list, then please send me the capture in private.But
 I must say that people here on the list tend to read SSL traces fasterthan
 me :-)Regards,Willy


-- Andrei Marinescu -- co-founder
Appscend - The Mobile Experience Igniter

Calea Plevnei 46-48, Bucharest, Romania
phone: +4 0742 896 394
email: and...@appscend.com 




05:54:30.410434 IP 109.166.130.140.58713 > 10.36.226.198.443: tcp 0
0x:  4508 0034 5342 4000 2d06 1d5d 6da6 828c  E..4SB@.-..]m...
0x0010:  0a24 e2c6 e559 01bb 07e7 7788    .$...Yw.
0x0020:  8002 3908 f2a6  0204 0578 0402 0101  ..9x
0x0030:  0103 0304
05:54:30.410486 IP 10.36.226.198.443 > 109.166.130.140.58713: tcp 0
0x:  4500 0034  4000 4006 5da7 0a24 e2c6  E..4..@.@.]..$..
0x0010:  6da6 828c 01bb e559 5a0f 20ff 07e7 7789  m..YZ.w.
0x0020:  8012 3908 dd43  0204 05b4 0101 0402  ..9..C..
0x0030:  0103 0304
05:54:30.518562 IP 109.166.130.140.58713 > 10.36.226.198.443: tcp 0
0x:  4508 0028 5343 4000 2d06 1d68 6da6 828c  E..(s...@.-..hm...
0x0010:  0a24 e2c6 e559 01bb 07e7 7789 5a0f 2100  .$...Yw.Z.!.
0x0020:  5010 0391 ed91   P...
05:54:30.543877 IP 109.166.130.140.58713 > 10.36.226.198.443: tcp 442
0x:  4508 01e2 5344 4000 2d06 1bad 6da6 828c  E...SD@.-...m...
0x0010:  0a24 e2c6 e559 01bb 07e7 7789 5a0f 2100  .$...Yw.Z.!.
0x0020:  5018 07d0 237d  1603 0101 b501 0001  P...#}..
0x0030:  b103 0151 da54 1f34 b1f1 9c47 bd5f 7c91  ...Q.T.4...G._|.
0x0040:  54d2 010e 933e 8104 3dee d19d ca5f 6cdf  T>..=_l.
0x0050:  4044 4520 52b5 30f4 c316 bfb1 d217 f224  @DE.R.0$
0x0060:  675f c495 f3e3 b69e 3937 e706 d6ab 7b9e  g_..97{.
0x0070:  319f 4477 0046 0004 0005 002f 0035 c002  1.Dw.F./.5..
0x0080:  c004 c005 c00c c00e c00f c007 c009 c00a  
0x0090:  c011 c013 c014 0033 0039 0032 0038 000a  ...3.9.2.8..
0x00a0:  c003 c00d c008 c012 0016 0013 0009 0015  
0x00b0:  0012 0003 0008 0014 0011 00ff 0100 0122  ..."
0x00c0:   001a 0018  1569 6e74 6572 6661  .CERTNAM
0x00d0:  6365 2e61 7070 6365 6e64 2e63 6f6d 000b  EREDACTED...
0x00e0:  0004 0300 0102 000a 0034 0032 000e 000d  .4.2
0x00f0:  0019 000b 000c 0018 0009 000a 0016 0017  
0x0100:  0008 0006 0007 0014 0015 0004 0005 0012  
0x0110:  0013 0001 0002 0003 000f 0010 0011 0023  ...#
0x0120:  00c0 1274 21e9 1971 b5fe 682e acfd f820  ...t!..q..h.
0x0130:  bfd3 3d05 5b42 3a22 0104 1638 200e 1abd  ..=.[B:"...8
0x0140:  e601 36b5 7d4d 8c4f 815d b259 95b3 1e92  ..6.}M.O.].Y
0x0150:  f433 eeeb 1131 64b6 9b99 23c6 364d 660e  .3...1d...#.6Mf.
0x0160:  c21c 20c8 4daa 4059 5291 3cd4 0986 ff4c  M.@YR.<L
0x0170:  591e 3ed4 fde3 623f 048c 1947 082d ddc3  Y.>...b?...G.-..
0x0180:  49ce 201e 115a 6d08 817e 4ded 32d0 2d83  IZm..~M.2.-.
0x0190:  f9b9 838e 78e8 c66a 652b 51f3 bfb9 a749  x..je+QI
0x01a0:  a64c b8d3 16a5 134d 8d19 3548 50b3 1c30  .L.M..5HP..0
0x01b0:  d068 2de2 b5a5 ad69 3239 96f4 b10b 7ba1  .h-i29{.
0x01c0:  cb98 8801 3b9e 96b3 93e2 9889 f918 075e  ;..^
0x01d0:  6df8 75cb 1f36 01c7 772d 54b1 040c 1e73  m.u..6..w-Ts
0x01e0:  2fe0 /.
05:54:30.544355 IP 10.36.226.198.443 > 109.166.130.140.58713: tcp 145
0x:  4500 00b9 d904 4000 4006 841d 0a24 e2c6  E.@.@$..
0x0010:  6da6 828c 01bb e559 5a0f 2100 07

SSL Handshake errors

[Andrei Marinescu]

Hello everyone!

I've moved off AWS ELB today to HAProxy 1.5dev18. I'm doing SSL 
termination at the LB and I'm encountering a rather large number of 
messages such as:

- SSL Handshake failure
- Timeout during SSL handshake
- Connection closed during SSL handshake

The problem is similar to the one I've found in the archives about 2 
weeks ago (http://marc.info/?l=haproxy&m=137158875803495&w=2), but 
unfortunately I'm unable to debug this. I'm trying to clarify if these 
are errors that are normal and I just didn't see on ELB, or if there's 
anything to do to better configure HAProxy. As far as I can see in the 
logs, some hosts are able to connect successfully sometimes, and with 
errors other times. Hosts that have errors tend to have more errors than 
successful requests. Also, almost of the devices accessing this service 
are Android and iOS devices.


I'm using a free StartSSL certificate.

I've posted the relevant haproxy.cfg lines below. Any ideas are extremly 
welcome!


defaults
option accept-invalid-http-request
option httplog
log global
mode http
option http-server-close
option redispatch
timeout connect 6ms
timeout client 6ms
timeout server 6ms
frontend www_secure
mode http
bind 0.0.0.0:443 ssl crt CERTNAME1.pem crt CERTNAME2.pem
(acl's directing traffic to 2 backends)

--
Andrei Marinescu