cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Reactivate the SSL certificate CN = https URL hostname check?
Date Thu, 27 Mar 2008 13:40:34 GMT
On Thursday 27 March 2008, Glen Mazza wrote:
> 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?

Overkill at this point.   As long as its optional so exising xml will 
validate fine with the new schema, I wouldn't worry about it.

Dan


>
> 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#Transp
> > > >ort_ 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

Mime
View raw message