cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arundel, Donal" <donal.arun...@iona.com>
Subject RE: Reactivate the SSL certificate CN = https URL hostname check?
Date Thu, 27 Mar 2008 11:17:19 GMT
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. 

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)



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

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
View raw message