Bug 608239

Summary: s_client starttls support for XMPP does not recognise valid starttls information in server stream
Product: [Fedora] Fedora Reporter: J.H.M. Dassen (Ray) <rdassen>
Component: opensslAssignee: Tomas Mraz <tmraz>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: rbinkhor, tmraz
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: openssl-1.0.0d-7.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-26 12:27:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Proposed patch none

Description J.H.M. Dassen (Ray) 2010-06-26 09:47:57 UTC
Description of problem:

The openssl starttls support for XMPP only recognises the starttls
information in XML data stream from the XMPP server by scanning for the
string
	<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'
but in XML attribute values are contained within either single quotes or
double quotes. The current code does not pick up on
	<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"
and thus incorrectly reports "no peer certificate available" if the server
happens to be using double quotes.

Version-Release number of selected component (if applicable):

openssl-1.0.0a-1.fc14.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Identify an XMPP server that supports starttls and that uses double
   quotes around the attribute value urn:ietf:params:xml:ns:xmpp-tls ,
   say chat.corp.redhat.com
2. Use openssl s_client to connect to it:
	$ openssl s_client -starttls xmpp -connect chat.corp.redhat.com:5222

Actual results:

	$ openssl s_client -starttls xmpp -connect chat.corp.redhat.com:5222
	CONNECTED(00000003)
	---
	no peer certificate available
	---
	No client certificate CA names sent
	---
	SSL handshake has read 413 bytes and written 125 bytes
	---
	New, (NONE), Cipher is (NONE)
	Secure Renegotiation IS NOT supported
	Compression: NONE
	Expansion: NONE
	---

A network trace of this, decoded:
	<stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' to='chat.corp.redhat.com' version='1.0'><?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="redhat.com" id="8f3ea6aa" xml:lang="en" version="1.0"><stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>GSSAPI</mechanism><mechanism>PLAIN</mechanism></mechanisms></stream:features>
i.e. ending with a "</stream:features>" from the server.

Expected results:

	openssl s_client -starttls xmpp -connect chat.corp.redhat.com:5222
	CONNECTED(00000003)
without a "no peer certificate available" message. A network trace of this,
decoded:
	<stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' to='chat.corp.redhat.com' version='1.0'><?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="redhat.com" id="2e0418a9" xml:lang="en" version="1.0"><stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>GSSAPI</mechanism><mechanism>PLAIN</mechanism></mechanisms></stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>...........
i.e. the client responds with a "<starttls" after receiving
"</stream:features>" from the server.

Additional info: -

Comment 1 Bug Zapper 2010-07-30 12:14:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 2 J.H.M. Dassen (Ray) 2011-07-17 19:58:14 UTC
Created attachment 513537 [details]
Proposed patch

Comment 3 J.H.M. Dassen (Ray) 2011-07-17 20:01:41 UTC
This issue is still reproducible with current rawhide (openssl-1.0.0d-5.fc16.x86_64). I have attached a patch that fixes it in my testing. If you agree with it, please propose it for upstream inclusion.

Comment 4 Tomas Mraz 2011-07-18 08:29:56 UTC
Yes, that seems correct. I'll add it to the current rawhide and submit it to upstream tracker.