cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <glen.ma...@verizon.net>
Subject RE: Reactivate the SSL certificate CN = https URL hostname check?
Date Thu, 27 Mar 2008 11:48:13 GMT

Am Donnerstag, den 27.03.2008, 07:17 -0400 schrieb Arundel, Donal:
> Sounds good to me Glen :-)
> 
> Having a sensible default from a security viewpoint is best.
> especially when its common and good practice in other products.
> 
> This check protects against cryptographically valid  certificates being
> accepted for sites they were not issued for, and its probably
> particularly important since CXF defaults to accepting the JDK default
> set of CAs.
> 
> If we detected this exact error when somebody hit it we could have a log
> message which pointed out the relevant setting to bypass this for 
> Development testing only etc. 

Yes, I will add that in as feedback.  Only issue I see is that I will
need to change the XSD for cxf.xml to accomodate this additional
(optional) flag.  Will I need to use a new URL for the XSD, or would
that be overkill?

Glen

> 
> That way it shouldn't cause too much grief to those that are only
> kicking the wheels of CXF.
> Our demos would likely need to use this setting, but should be
> accompanied by a warning comment too.
> 
> Cheers,
>     Donal
> 
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org] 
> Sent: 27 March 2008 03:20
> To: cxf-dev@incubator.apache.org
> Cc: Glen Mazza
> Subject: Re: Reactivate the SSL certificate CN = https URL hostname
> check?
> 
> 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)
> 
> 
> 


Mime
View raw message