You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Glen Mazza <gl...@verizon.net> on 2008/03/26 10:12:57 UTC
Reactivate the SSL certificate CN = https URL hostname check?
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)
Re: Reactivate the SSL certificate CN = https URL hostname check?
Posted by Daniel Kulp <dk...@apache.org>.
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
RE: Reactivate the SSL certificate CN = https URL hostname check?
Posted by Glen Mazza <gl...@verizon.net>.
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: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)
>
>
>
RE: Reactivate the SSL certificate CN = https URL hostname check?
Posted by "Arundel, Donal" <do...@iona.com>.
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
Re: Reactivate the SSL certificate CN = https URL hostname check?
Posted by Daniel Kulp <dk...@apache.org>.
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
Re: Reactivate the SSL certificate CN = https URL hostname check?
Posted by Glen Mazza <gl...@verizon.net>.
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.
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)
>
>