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:[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#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) > > >
