Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: cxf-dev@incubator.apache.org
Subject: Re: Reactivate the SSL certificate CN = https URL hostname check?
Date: Wed, 26 Mar 2008 23:20:20 -0400
User-Agent: KMail/1.9.7
Cc: Glen Mazza <glen.mazza@verizon.net>
References: <1206522777.11634.3.camel@gmazza-desktop>
 <1206586878.32725.7.camel@gmazza-desktop>
In-Reply-To: <1206586878.32725.7.camel@gmazza-desktop>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200803262320.20500.dkulp@apache.org>

On Wednesday 26 March 2008, Glen Mazza wrote:
> If no objections, I'll be proceeding on adding a client parameter to
> turn off the CN checking, and reactivating the CN check as the
> default.

That all makes sense to me, but I won't even pretent to understand all 
the security implications and stuff of the https settings.   :-)

Dan


>
> Glen
>
> Am Mittwoch, den 26.03.2008, 05:12 -0400 schrieb Glen Mazza:
> > Team,
> >
> > There is apparently a default check in Java to make sure that the
> > SSL certificate Common Name (CN) matches that of the https:// URL
> > hostname when making an SSL-based web call.  Metro does not disable
> > that check[1], instead it provides its users a standard workaround
> > during development, etc., should they wish to use "localhost" or
> > similar temporarily within the https:// URL.  That same
> > documentation section also emphasizes removing that workaround once
> > you are in production.
> >
> > AFAICT Apache CXF *is* shutting off that check[2] and supposedly
> > deferring it to MessageTrustDecider[3] (where it can be subsequently
> > attached in the cxf.xml file), but if the user does not implement a
> > MessageTrustDecider and manually check this value himself it will
> > never end up being made[4].  Even assuming a user is aware of this
> > check being disabled, most of them probably have never heard of the
> > CXF-only MessageTrustDecider, and so IMO it would be a bit too much
> > to ask them to create this object in order to reactivate that check.
> >
> > If I'm correct here, I think we should reinstate the CN check by
> > default, but provide users a cxf.xml client configuration setting
> > that disables that check if desired.  I wouldn't have a problem with
> > us using "disabled by default" if that were the Java language
> > default, but it isn't, and so I think it should be reinstated for
> > the benefit of newbies as well as more advanced users who might not
> > be aware that we disabled this check to begin with.
> >
> > Thoughts?
> >
> > Regards,
> > Glen
> >
> >
> > [1]
> > https://metro.dev.java.net/guide/Security_Mechanisms.html#Transport_
> >Security__SSL__Workaround [2] http://tinyurl.com/2el54h (line
> > 155-177, 215)
> > [3] http://tinyurl.com/yt54uq
> > [4] http://tinyurl.com/2h3a4r (lines 637-645)


-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog