Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 608239 - s_client starttls support for XMPP does not recognise valid starttls information in server stream
s_client starttls support for XMPP does not recognise valid starttls informat...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openssl (Show other bugs)
rawhide
All All
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-26 05:47 EDT by J.H.M. Dassen (Ray)
Modified: 2013-07-03 00:06 EDT (History)
2 users (show)

See Also:
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 08:27:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch (664 bytes, patch)
2011-07-17 15:58 EDT, J.H.M. Dassen (Ray)
no flags Details | Diff

  None (edit)
Description J.H.M. Dassen (Ray) 2010-06-26 05:47:57 EDT
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 08:14:58 EDT
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 15:58:14 EDT
Created attachment 513537 [details]
Proposed patch
Comment 3 J.H.M. Dassen (Ray) 2011-07-17 16:01:41 EDT
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 04:29:56 EDT
Yes, that seems correct. I'll add it to the current rawhide and submit it to upstream tracker.

Note You need to log in before you can comment on or make changes to this bug.