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:[EMAIL PROTECTED] > > Sent: 27 March 2008 03:20 > > To: [email protected] > > 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 [EMAIL PROTECTED] http://www.dankulp.com/blog
