[openssl-users] openssl s_server stops on some client connections
Lists@vpnadmin
lists at vpnadmin.com.ua
Thu Jan 29 16:17:49 UTC 2015
Hello all!
Please help me to understand, what is the problem with openssl s_server.
It stops after some connections: LAN clients connect well, but most of
WAN ones kill the s_server (not only SSL/TLS clients, but telnet to same
port too).
Same versions OS and openssl on different servers (different providers)
work well or don't work.
The problem is found for openssl "1.0.1e-2+deb7u14" on Debian Wheezy
and for openssl "1.0.1f 6 Jan 2014" on Ubuntu 12.04.
The task is to create TLS connection to SIP provider with asterisk.
Outgoing TLS-connection to provider have been established. Problem is
appearing when provider attempts to connect to my host: asterisk is
working, but TLS connections are refused:
$ openssl s_client -connect 1.2.3.4:5061
connect: Connection refused
connect:errno=111
So, port is open on the server, but there is no a service, which listen
on this port.
Let try to emmulate the SSL/TLS server with the script:
# openssl s_server -tls1 -accept 443 -cert
/etc/ssl/certs/ssl-cert-snakeoil.pem -key
/etc/ssl/private/ssl-cert-snakeoil.key -www
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
< ... server is waiting for connections ...>
Let attempt to connect to this server again:
$ openssl s_client -connect 1.2.3.4:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
$
On the server side:
...
gethostbyname failure
0 items in the session cache
0 client connects (SSL_connect())
0 client renegotiates (SSL_connect())
0 client connects that finished
0 server accepts (SSL_accept())
0 server renegotiates (SSL_accept())
0 server accepts that finished
0 session cache hits
0 session cache misses
0 session cache timeouts
0 callback cache hits
0 cache full overflows
#
<... here s_server stops ...>
Let restart s_server and try to connect with browser: "https://1.2.3.4/"
or with Telnet: "telnet 1.2.3.4 443" - result is same.
I think, this is the time to tell about versions:
# uname -a
Linux server 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux
# openssl version
OpenSSL 1.0.1e 11 Feb 2013
# dpkg-query -l | grep openssl
ii openssl 1.0.1e-2+deb7u14 amd64 Secure
Socket Layer (SSL) binary and related cryptographic tools
Firewall is open for all outgoing connections and for incoming
connections to "s_client" hosts.
All servers have direct ethernet connection to providers without NATs, PPPs.
Let try to connect from LAN to same server: connection is established.
Let try to use "TLS Dump" service from http://paranoidsecurity.nl/ :
connection is established.
Also I see successful connections from Google and other bots.
Let try to create s_server on another server with another provider and
the same OS version: connection is established.
Let try to create one more s_server on the one more host (the third
provider, Ubuntu): there is the same error - "openssl s_server" stops.
About this host:
# uname -a
Linux serv 3.2.0-43-generic-pae #68-Ubuntu SMP Wed May 15 03:55:10 UTC
2013 i686 i686 i686 GNU/Linux
# openssl version
OpenSSL 1.0.1f 6 Jan 2014
I think, there are external conditions when openssl s_server sometimes
stops on connections to it. If it is so, then there is a
Denial-of-Service vulnerability into openssl !
Some more information we can get by ssldump-ing working connection with
comparison to non-working:
*Working connection:**
*
# ssldump -A -e -H -T port 5069
TCP: srv-2.local(5069) -> srv-1.local(37926) Seq 471176930.(0) ACK
1183615929 FIN
TCP: srv-1.local(37926) -> srv-2.local(5069) Seq 1183615929.(29) ACK
471176931 PUSH
TCP: srv-2.local(5069) -> srv-1.local(37926) Seq 471176931.(0) RST
TCP: srv-1.local(37926) -> srv-2.local(5069) Seq 1183615958.(0) ACK
471176931 FIN
TCP: srv-2.local(5069) -> srv-1.local(37926) Seq 471176931.(0) RST
TCP: srv-1.local(37927) -> srv-2.local(5069) Seq 2566830925.(0) SYN
TCP: srv-2.local(5069) -> srv-1.local(37927) Seq 3381252077.(0) ACK
2566830926 SYN
TCP: srv-1.local(37927) -> srv-2.local(5069) Seq 2566830926.(0) ACK
3381252078
New TCP connection #1: srv-1.local(37927) <-> srv-2.local(5069)
TCP: srv-1.local(37927) -> srv-2.local(5069) Seq 2566830926.(213) ACK
3381252078 PUSH
1 1 1422527436.6006 (0.0032) C>SV3.1(208) Handshake
ClientHello
Version 3.1
random[32]=
51 f1 5c 7e 16 d6 05 73 19 21 5d 30 e6 a9 10 8a
cd 43 cd f8 45 5b f9 3d 7f 3b d8 b7 80 d0 40 cc
cipher suites
Unknown value 0xc014
Unknown value 0xc00a
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Unknown value 0x88
...
Unknown value 0xc002
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
...
Unknown value 0xff
compression methods
NULL
TCP: srv-2.local(5069) -> srv-1.local(37927) Seq 3381252078.(0) ACK
2566831139
*[b]TCP: srv-2.local(5069) -> srv-1.local(37927) Seq 3381252078.(1448)
ACK 2566831139 [/b]**
**1 2 1422527441.6032 (5.0026) S>CV3.1(58) Handshake*
ServerHello
Version 3.1
...
*Non-working connection:*
# ssldump -i eth1 -A -e -H -T port 5069
TCP: mypc.domain.com(40539) -> 1.2.3.4(5069) Seq 2748453215.(0) SYN
TCP: 1.2.3.4(5069) -> mypc.domain.com(40539) Seq 221407102.(0) ACK
2748453216 SYN
TCP: mypc.domain.com(40539) -> 1.2.3.4(5069) Seq 2748453216.(0) ACK
221407103
New TCP connection #1: mypc.domain.com(40539) <-> 1.2.3.4(5069)
TCP: mypc.domain.com(40539) -> 1.2.3.4(5069) Seq 2748453216.(308) ACK
221407103 PUSH
1 1 1422527941.2773 (0.0203) C>SV3.1(303) Handshake
ClientHello
Version 3.3
random[32]=
54 ca 0d c5 e6 ea 2f a6 7b 8f 3f e2 07 88 ae 1d
80 71 14 7f 49 98 70 f3 23 2d 0a 54 c0 c1 1d 0d
cipher suites
Unknown value 0xc030
...
Unknown value 0x6a
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Unknown value 0x88
...
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
Unknown value 0xff
compression methods
unknown value
NULL
TCP: 1.2.3.4(5069) -> mypc.domain.com(40539) Seq 221407103.(0) ACK
2748453524
*TCP: 1.2.3.4(5069) -> mypc.domain.com(40539) Seq 221407103.(0) ACK
2748453524 RST **
**1 1422527941.2783 (0.0010) S>C TCP RST*
So, after first handshake stage s_server sends RST TCP-packet and stops.
Here my knowledge and fantasy is over as to decision of this problem.
Give me advice please, how to force the openssl s_server to work.
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150129/46d5e12b/attachment-0001.html>
More information about the openssl-users
mailing list