cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Http-conduit disableCNCheck
Date Thu, 13 Nov 2008 01:26:26 GMT
On Wednesday 12 November 2008 2:11:22 pm wonderingWV wrote:
> If it helps,  we use JDK 5 and the problem with the disableCNCheck(false)
> first appeared after we updated from CXF 2.0.* to CXF 2.1.*

I just committed some changes that install a better HostnameVerifier to check 
the certs.   It would be great if you could checkout the 2.1.x branch, build 
it, and give it a whirl.    I'll try and upload new snapshots tomorrow if 
doing a build is too much.

Dan


>
> John
>
> Glen Mazza wrote:
> > The Metro guide seems to suggest the default verifier is a little bit
> > more intelligent than that:
> > https://metro.dev.java.net/guide/Security_Mechanisms.html#Transport_Secur
> >ity__SSL__Workaround
> >
> > But perhaps this is a result of switching from JDK 5 to 6?  Anyway, the
> > workaround they have above probably would take care of the user
> > configurability functionality you mention in your last sentence below.
> >
> > Glen
> >
> > dkulp wrote:
> >> On Tuesday 11 November 2008 4:11:45 pm Glen Mazza wrote:
> >>> Hmmm...I'm sure I had tested that.  I wonder if my 2.0.x change was
> >>> *not*
> >>> ported to the 2.1 branch?
> >>
> >> Looking back at the change history, your changes seem to add the
> >> "AlwaysTrue"
> >> verifier only if DisableCNCheck flag is true.   Previous to your change,
> >> the
> >> AlwaysTrue verifier was always added.
> >>
> >> With your change, if the flag is false, it now delegates to the JDK
> >> built in
> >> default verifier which seems to be very stupid and just does "return
> >> false".
> >> Pretty much useless.   :-(     Looks to me like we need to find a good
> >> HostNameVerifier if the flag is false.   Additionally, we probably
> >> should allow the user to configure in their own HostNameVerifier
> >> somehow.
> >>
> >> Dan
> >>
> >>> Glen
> >>>
> >>> dkulp wrote:
> >>> > Looking at the decompiled source for the "DefaultHostnameVerifier",
> >>> > it literally just does a "return false;".   Thus, I don't see how
> >>> > it's possible
> >>> > to do any SSL things with host bound certs right now without the
> >>> > DisableCNCheck thing.    It looks like we need to write a new
> >>> > HostNameVerifier thing that would actually do some level of
> >>>
> >>> verification.
> >>>
> >>> > We might be able to grab the one synapse has:
> >>>
> >>> http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/s
> >>>rc
> >>>
> >>> >/main/java/org/apache/synapse/transport/nhttp/HostnameVerifier.java
> >>> >
> >>> > and use that.  Someone would need to check that though.  That looks
> >>>
> >>> like
> >>>
> >>> > it
> >>> > came from the not-yet-commons-ssl project at
> >>> > http://juliusdavies.ca/commons-ssl/
> >>> >
> >>> > There's probably some others floating around if we dig more.
> >>> >
> >>> > Dan
> >>> >
> >>> > On Tuesday 11 November 2008 1:10:13 pm Glen Mazza wrote:
> >>> >> If you can check the CXF source code (I don't have it with me
> >>> >> immediately,
> >>> >> but search the source code for the error message you're getting
to
> >>> >> determine the class) -- you can place debugging statements on what
> >>>
> >>> CXF
> >>>
> >>> >> thinks the hostname URL and the CN is to determine why it is failing
> >>>
> >>> on
> >>>
> >>> >> you.  Perhaps I made a mistake in my logic someplace--but as no
one
> >>>
> >>> else
> >>>
> >>> >> has complained about this yet, I would suspect, for some reason,
> >>> >> your
> >>>
> >>> CN
> >>>
> >>> >> actually isn't matching the hostname URL.
> >>> >>
> >>> >> Glen
> >>> >>
> >>> >> wonderingWV wrote:
> >>> >> > I understand why it was done, but the problem is I cannot
get ssl
> >>>
> >>> with
> >>>
> >>> >> > cxf to work unless the flag is set to true, which I do not
want to
> >>>
> >>> do
> >>>
> >>> >> in
> >>> >>
> >>> >> > a production environment.
> >>> >> >
> >>> >> > Glen Mazza wrote:
> >>> >> >> I'm unsure what the problem is.  I had done that last
March[1]
> >>>
> >>> after
> >>>
> >>> >> >> agreement with the team.
> >>> >> >>
> >>> >> >> Glen
> >>> >> >>
> >>> >> >> [1] http://www.jroller.com/gmazza/date/20080329
> >>> >> >>
> >>> >> >> wonderingWV wrote:
> >>> >> >>> The common name on the cert and the hostName of the
url match up
> >>>
> >>> so
> >>>
> >>> >> >>> I not sure why I continue to receive this error. 
Any advise
> >>>
> >>> would
> >>>
> >>> >> >>> be greatly appreciated.
> >>> >
> >>> > --
> >>> > Daniel Kulp
> >>> > dkulp@apache.org
> >>> > http://dankulp.com/blog
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org
> >> http://dankulp.com/blog



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message