Hello Lukas,
Thanks for your update.
>
>> Currently, I start haproxy manually with this command (in the same shell I
>> edit the config file, thus I have to stop haproxy with CTRL-C for changes):
>> —
>> haproxy -d -f /etc/haproxy/haproxy.cfg
>> —
>
>
> I see. Can you run it through strace -tt, Not that I expect to see why the TLS
> handshake fails, just to confirm that its indeed haproxy that accepts the
> connection (just prepend your command above with strace -tt). Attach the
> strace output to a txt file to the mail, as it will be long.
I will send the entire strace output separately to you as it very long but the
short form for the mailing list:
—
00:15:55.786195 gettimeofday({1413584155, 786244}, NULL) = 0
00:15:55.786280 accept4(4, {sa_family=AF_INET, sin_port=htons(57248),
sin_addr=inet_addr(„<MY IPV4 ADDRESS ON INTERNET>")}, [16], SOCK_NONBLOCK) = 6
00:15:55.786548 accept4(4, 0x7fff2fbe9880, [128], SOCK_NONBLOCK) = -1 EAGAIN
(Resource temporarily unavailable)
00:15:55.786629 gettimeofday({1413584155, 786643}, NULL) = 0
00:15:55.786772 read(6, 0x119b343, 5) = -1 EAGAIN (Resource temporarily
unavailable)
00:15:55.786890 epoll_ctl(3, EPOLL_CTL_ADD, 6, {EPOLLIN|0x2000, {u32=6,
u64=6}}) = 0
00:15:55.786943 gettimeofday({1413584155, 786956}, NULL) = 0
00:15:55.786983 epoll_wait(3, {{EPOLLIN, {u32=6, u64=6}}}, 200, 1000) = 1
00:15:55.815985 gettimeofday({1413584155, 816008}, NULL) = 0
00:15:55.816038 gettimeofday({1413584155, 816051}, NULL) = 0
00:15:55.816092 read(6, "\200\217\1\3\3", 5) = 5
00:15:55.816154 recvfrom(6, NULL, 2147483647,
MSG_TRUNC|MSG_DONTWAIT|MSG_NOSIGNAL, NULL, NULL) = 140
00:15:55.816208 recvfrom(6, 0, 2147483647, 16480, 0, 0) = -1 EAGAIN (Resource
temporarily unavailable)
00:15:55.816312 sendto(5, "<150>Oct 18 00:15:55 haproxy[100"..., 116,
MSG_DONTWAIT|MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(514),
sin_addr=inet_addr("127.0.0.1")}, 16) = 116
00:15:55.816565 close(6) = 0
—
This is the connect to haproxy where the web socket upgrade shall take place.
> Also, please try the bind keywords no-tlsv12, no-tlsv11 and
> "ciphers TLS_RSA_WITH_RC4_128_SHA". If this makes it work, please apply
> the attached debug patch and just run it with force-tlsv10, I would like
> to know if that call fails.
I added the parameters except TLS_RSA_WITH_RC4_128_SHA as it is not available
in openssl. This one seems to be the equivalent here: RC4-SHA
Thus, my bind looks like this:
bind *:443 ssl crt /etc/pki/tls/certs/domain-haproxy.pem force-tlsv10 no-tlsv12
no-tlsv11 ciphers RC4-SHA
But again, the web socket upgrade does not take place. haproxy log still says:
Connection closed during SSL handshake.
Am I right that the patch is only useful for you on a positive result?
>
> Anyway, I still think we don't see the whole picture. You don't have
> any SSL/TLS intercepting middleboxes between your client and your
> server, correct?
>
All my tests were established this way:
Java client <-> Internet router doing SNAT to Internet IP <-> INTERNET <->
Company firewall doing DNAT to internal, private IP <-> haproxy server
I always re-checked the company firewall but this connection is not logged in
any way.
Best regards,
Heiko
