Bug 1356178

Summary:	s_client hangs connecting to some hosts with XMPP STARTTLS
Product:	Red Hat Enterprise Linux 7	Reporter:	Alois Mahdal <amahdal>
Component:	openssl	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED ERRATA	QA Contact:	Stefan Dordevic <sdordevi>
Severity:	medium	Docs Contact:
Priority:	low
Version:	7.3	CC:	amahdal, extras-qa, hkario, sdordevi, szidek, tmraz
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1356176	Environment:
Last Closed:	2017-08-01 18:16:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1356176
Bug Blocks:

Description Alois Mahdal 2016-07-13 15:04:40 UTC

+++ This bug was initially created as a clone of Bug #1356176 +++

Description of problem
======================

When s_client is used to connect to some XMPP hosts vira STARTTLS,
it will hang forever.  For example:

    openssl s_client -connect hektar.jabbim.cz:5222 -starttls xmpp

Turns out this has been already fixed in upstream some time ago:

    https://rt.openssl.org/Ticket/Display.html?id=2860

This ticket is to backport that change to Fedora/RHEL.


Version-Release number of selected component
============================================

openssl-1.0.1e-58.el7


How reproducible
================

Always (with certain host configurations)


Steps to Reproduce
==================

 1. for example:

        openssl s_client -connect hektar.jabbim.cz:5222 -starttls xmpp </dev/null


Actual results
==============

Client loops forever even though server tried to close the connection
(explanation from Hubert Kario).


Expected results
================

Client quits after server closes the connection.

Comment 1 Tomas Mraz 2017-04-03 14:27:56 UTC

I cannot reproduce it with openssl-1.0.2. So this seems to be handled by the rebase.

*** This bug has been marked as a duplicate of bug 1276310 ***

Comment 2 Alois Mahdal 2017-04-03 23:47:51 UTC

(In reply to Tomas Mraz from comment #1)
> I cannot reproduce it with openssl-1.0.2. So this seems to be handled by the
> rebase.

Just note that my steps above rely on server configuration which may have changed; I don't know details but I was not able to reproduce it with just any server, hektar.jabbim.cz was the only one I knew about, and it seems to be dead now:

    [0 root@qeos-184 ~]# rpm -q openssl
    openssl-1.0.1e-60.el7.x86_64
    [0 root@qeos-184 ~]# openssl s_client -connect hektar.jabbim.cz:5222 -starttls xmpp
    socket: Connection refused
    connect:errno=111
    [0 root@qeos-184 ~]# 

Newer openssl just gives different error:

    [0 root@qeos-180 ~]# rpm -q openssl
    openssl-1.0.2k-4.el7.x86_64
    [0 root@qeos-180 ~]# openssl s_client -connect hektar.jabbim.cz:5222 -starttls xmpp
    socket: Bad file descriptor
    connect:errno=9
    [0 root@qeos-180 ~]# 

Do you have alternate reproduction steps that leave the dead server out of the equation?

Comment 3 Alois Mahdal 2017-04-03 23:53:46 UTC

Forget it, I just found out that the bug is still reproducible with a new server Jabbim uses these days:

    [0 root@qeos-184 ~]# time timeout 10 openssl s_client -connect lb.jabb.im:5222 -starttls xmpp <.; echo $?
    CONNECTED(00000003)

    real	0m10.003s
    user	0m1.994s
    sys	0m7.798s
    124
    [0 root@qeos-184 ~]# 

...aaand the new openssl:

    [0 root@qeos-180 ~]# time timeout 10 openssl s_client -connect lb.jabb.im:5222 -starttls xmpp <.; echo $?
    CONNECTED(00000003)
    ---
    no peer certificate available
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 298 bytes and written 115 bytes
    ---
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    ---

    real	0m0.241s
    user	0m0.010s
    sys	0m0.002s
    1
    [0 root@qeos-180 ~]#

Comment 11 errata-xmlrpc 2017-08-01 18:16:10 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1929