You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "KARR, DAVID" <dk...@att.com> on 2017/04/11 20:14:29 UTC
Curious behavior with "hostnameVerifier" property on ClientBuilder
So, I got my little client prototype working in "happy path", and I managed to accidentally discover a way to make the server response barf and give me back a fatal HTML response (which will be rare, but I have to know when it happens), so I added a catch clause for ResponseProcessingException so I could get the HTML text.
Now I wanted to try to understand what I accidentally discovered, which made the service call fail.
In my client initialization code, I have a block like this:
-------------------
builder.hostnameVerifier((host, session) -> {
try {
Certificate[] certs = session.getPeerCertificates();
return certs != null && certs[0] instanceof X509Certificate;
}
catch (SSLException ex) {
return false;
}
});
---------------
When I comment this out, I get HTML that essentially says "An attempt to authenticate with a client certificate failed." Ok, so I was just a little curious to see when or how that "host name verifier" is called. So I ran the test in debug, setting breakpoints in the try and catch block. No breakpoints were hit. I then added print statements in the lambda, both at the top and in the catch clause. Nothing comes out. I then added a flag to the parent instance and set it in the body of the lambda, and then printed out the value after I got the response, and the flag was not set.
From the evidence I'm seeing, it almost seems like just the presence of ANY host name verifier allows the verification to succeed, without even executing it. That can't be right.
Re: Curious behavior with "hostnameVerifier" property on ClientBuilder
Posted by Colm O hEigeartaigh <co...@apache.org>.
You could just adapt one of the existing CXF system tests that tests client
authentication? For example:
https://github.com/apache/cxf/tree/master/systests/transports/src/test/java/org/apache/cxf/systest/https/clientauth
Colm.
On Wed, Apr 12, 2017 at 4:52 PM, KARR, DAVID <dk...@att.com> wrote:
> > -----Original Message-----
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 12, 2017 2:38 AM
> > To: users@cxf.apache.org
> > Subject: Re: Curious behavior with "hostnameVerifier" property on
> > ClientBuilder
> >
> > Could you create a test-case to reproduce the problem?
>
> I would think that would be pretty complicated, as I'd have to be able to
> connect to a location that requires 2-way auth.
> >
> > Colm.
> >
> > On Tue, Apr 11, 2017 at 9:14 PM, KARR, DAVID <dk...@att.com> wrote:
> >
> > > So, I got my little client prototype working in "happy path", and I
> > > managed to accidentally discover a way to make the server response
> > > barf and give me back a fatal HTML response (which will be rare, but I
> > > have to know when it happens), so I added a catch clause for
> > > ResponseProcessingException so I could get the HTML text.
> > >
> > > Now I wanted to try to understand what I accidentally discovered,
> > > which made the service call fail.
> > >
> > > In my client initialization code, I have a block like this:
> > > -------------------
> > > builder.hostnameVerifier((host, session) -> {
> > > try {
> > > Certificate[] certs =
> > > session.getPeerCertificates();
> > > return certs != null && certs[0]
> > > instanceof X509Certificate;
> > > }
> > > catch (SSLException ex) {
> > > return false;
> > > }
> > > });
> > > ---------------
> > >
> > > When I comment this out, I get HTML that essentially says "An attempt
> > > to authenticate with a client certificate failed." Ok, so I was just
> > > a little curious to see when or how that "host name verifier" is
> > > called. So I ran the test in debug, setting breakpoints in the try
> > > and catch block. No breakpoints were hit. I then added print
> > > statements in the lambda, both at the top and in the catch clause.
> > > Nothing comes out. I then added a flag to the parent instance and set
> > > it in the body of the lambda, and then printed out the value after I
> > got the response, and the flag was not set.
> > >
> > > From the evidence I'm seeing, it almost seems like just the presence
> > > of ANY host name verifier allows the verification to succeed, without
> > > even executing it. That can't be right.
> > >
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__coders.talend.com&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > xy2uk0vYF_EA&m=Bk8D8FFnMY0pimrTXW80hdKsTlbA5iJIxTynAw1FEu0&s=Nd69tMZG9rU
> > aAObE5TSH9-MYSrm7Sj9_7n0kxXV1hLI&e=
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Curious behavior with "hostnameVerifier" property on
ClientBuilder
Posted by "KARR, DAVID" <dk...@att.com>.
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 12, 2017 2:38 AM
> To: users@cxf.apache.org
> Subject: Re: Curious behavior with "hostnameVerifier" property on
> ClientBuilder
>
> Could you create a test-case to reproduce the problem?
I would think that would be pretty complicated, as I'd have to be able to connect to a location that requires 2-way auth.
>
> Colm.
>
> On Tue, Apr 11, 2017 at 9:14 PM, KARR, DAVID <dk...@att.com> wrote:
>
> > So, I got my little client prototype working in "happy path", and I
> > managed to accidentally discover a way to make the server response
> > barf and give me back a fatal HTML response (which will be rare, but I
> > have to know when it happens), so I added a catch clause for
> > ResponseProcessingException so I could get the HTML text.
> >
> > Now I wanted to try to understand what I accidentally discovered,
> > which made the service call fail.
> >
> > In my client initialization code, I have a block like this:
> > -------------------
> > builder.hostnameVerifier((host, session) -> {
> > try {
> > Certificate[] certs =
> > session.getPeerCertificates();
> > return certs != null && certs[0]
> > instanceof X509Certificate;
> > }
> > catch (SSLException ex) {
> > return false;
> > }
> > });
> > ---------------
> >
> > When I comment this out, I get HTML that essentially says "An attempt
> > to authenticate with a client certificate failed." Ok, so I was just
> > a little curious to see when or how that "host name verifier" is
> > called. So I ran the test in debug, setting breakpoints in the try
> > and catch block. No breakpoints were hit. I then added print
> > statements in the lambda, both at the top and in the catch clause.
> > Nothing comes out. I then added a flag to the parent instance and set
> > it in the body of the lambda, and then printed out the value after I
> got the response, and the flag was not set.
> >
> > From the evidence I'm seeing, it almost seems like just the presence
> > of ANY host name verifier allows the verification to succeed, without
> > even executing it. That can't be right.
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__coders.talend.com&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=Bk8D8FFnMY0pimrTXW80hdKsTlbA5iJIxTynAw1FEu0&s=Nd69tMZG9rU
> aAObE5TSH9-MYSrm7Sj9_7n0kxXV1hLI&e=
Re: Curious behavior with "hostnameVerifier" property on ClientBuilder
Posted by Colm O hEigeartaigh <co...@apache.org>.
Could you create a test-case to reproduce the problem?
Colm.
On Tue, Apr 11, 2017 at 9:14 PM, KARR, DAVID <dk...@att.com> wrote:
> So, I got my little client prototype working in "happy path", and I
> managed to accidentally discover a way to make the server response barf and
> give me back a fatal HTML response (which will be rare, but I have to know
> when it happens), so I added a catch clause for ResponseProcessingException
> so I could get the HTML text.
>
> Now I wanted to try to understand what I accidentally discovered, which
> made the service call fail.
>
> In my client initialization code, I have a block like this:
> -------------------
> builder.hostnameVerifier((host, session) -> {
> try {
> Certificate[] certs =
> session.getPeerCertificates();
> return certs != null && certs[0]
> instanceof X509Certificate;
> }
> catch (SSLException ex) {
> return false;
> }
> });
> ---------------
>
> When I comment this out, I get HTML that essentially says "An attempt to
> authenticate with a client certificate failed." Ok, so I was just a little
> curious to see when or how that "host name verifier" is called. So I ran
> the test in debug, setting breakpoints in the try and catch block. No
> breakpoints were hit. I then added print statements in the lambda, both at
> the top and in the catch clause. Nothing comes out. I then added a flag
> to the parent instance and set it in the body of the lambda, and then
> printed out the value after I got the response, and the flag was not set.
>
> From the evidence I'm seeing, it almost seems like just the presence of
> ANY host name verifier allows the verification to succeed, without even
> executing it. That can't be right.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com