You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by leung cc <dk...@hotmail.com> on 2006/08/03 03:39:22 UTC

Re: applet needing https access to a servlet that requires aclient certificate

>From: Oleg Kalnichevski 
>Reply-To: "HttpClient User Discussion" 
>To: HttpClient User Discussion 
>Subject: Re: applet needing https access to a servlet that requires 
aclient certificate 
>Date: Wed, 02 Aug 2006 11:12:58 +0200 
> 
>On Wed, 2006-08-02 at 12:18 +0800, leung cc wrote: 
> > Sorry about duplicating this post here if you are also subscribed to 
> > httpclient-dev - I didn't realize this group is the more appropriate 
one. 
> > Anyway, here's my question: 
> > 
> > I've an applet that needs to access a servlet (well, actually a jsp 
page) 
> > that requires a client 
> > certificate. I've had success with Sun's standard URL + 
HttpURLConnection 
> > classes but since 
> > I'm getting "connection timed out: connect" problems I am seeking to 
set 
> > the timeout value 
> > longer. After some searching, it seemed to that there's no way to do 
such a 
> > thing with Sun's 
> > classes and that I should perhaps try Apache's httpclient if I must set 
the 
> > timeout value 
> > and so I here I am. 
> > 
> > Needless to say, I stumped on a problem right away, which I kind of 
> > expected because I suspected 
> > httpclient wouldn't be able to use the browser's https connection 
without 
> > me doing some tricky 
> > things. 
> > 
> > So, what should I do? Surely somebody in here must have used httpclient 
in 
> > an applet to do 
> > some https access, right? 
> > 
> 
>HttpClient is known to have been used successfully in applets. I 
>personally try to stay away from applets at all costs, so I can not give 
>a first-hand account of that. 

Firstly, thank you very much for replying. I think you are the man himself 
who made httpclient, right? 

I'm in too deep now and can't abandon the applet approach now, too bad. :(

I've heard about "the possibility" even after a short while in this mail 
list and that means some hope for me, at least. But I'm not sure by how 
much would my servlet's requiring a client certificate further complicate 
the picture. I did some research and it now seems I can make use of your 
goodself's AuthSSLProtocolSocketFactory in order to specify a client 
certificate and that's assuming I would go the JSSE route and not reusing 
the browser's https connection, which the current java plugin is allowing 
me to do. That would be soooo painful to give up on since I imagine then I 
would need to sign my applet and/or mess around with applet permissions 
etc.

> > I don't think the message I got (on the java plugin console) would be 
of 
> > much use, but let 
> > me quote a bit anyway: 
> > 
> > java.net.SocketException: Default SSL context init failed: failed to 
> > decrypt safe contents 
> > entry: javax.crypto.BadPaddingException: Given final block not properly 

> > padded 
> > at javax.net.ssl.DefaultSSLSocketFactory.createSocket(Unknown Source) 
> > at 
> 
>This is clearly a problem with the SSL layer and not with HttpClient. 
> 
>Also consider getting your code to work outside the applet in a 
>standalone application and once you are sure the SSL settings are sane, 
>try moving your code back to the applet and see what happens. 
> 
>Running your code with SSL debug traces on may also be of some help 
> 
>-Djavax.net.debug=ssl,handshake,data,trustmanager 

Think I am in one of those situations where this "get it running as an app 
first" debugging strategy won't work. To do that would mean no brower https 
connection to use - need to go jsse, using your goodself's 
AuthSSLProtocolSocketFactory and the only good thing about running it as an 
app is that I can delay worrying about the applet's sandbox. 

There,  I am about to cry out my question to everyone now: Has anyone done 
any https access in an applet with httpclient whilst using the browser's 
https channel - i.e. not needing to obtain socket i/o permissions for the 
applet?  A success story even when the server side doesn't require a client 
certificate would be very encouraging.



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


Re: applet needing https access to a servlet that requires aclient certificate

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2006-08-03 at 09:39 +0800, leung cc wrote:
> >From: Oleg Kalnichevski 
> >Reply-To: "HttpClient User Discussion" 
> >To: HttpClient User Discussion 
> >Subject: Re: applet needing https access to a servlet that requires 
> aclient certificate 
> >Date: Wed, 02 Aug 2006 11:12:58 +0200 
> > 
...
> > 
> >HttpClient is known to have been used successfully in applets. I 
> >personally try to stay away from applets at all costs, so I can not give 
> >a first-hand account of that. 
> 
> Firstly, thank you very much for replying. I think you are the man himself 
> who made httpclient, right? 
> 

I am just one of many contributors.

> I'm in too deep now and can't abandon the applet approach now, too bad. :(
> 
> I've heard about "the possibility" even after a short while in this mail 
> list and that means some hope for me, at least. But I'm not sure by how 
> much would my servlet's requiring a client certificate further complicate 
> the picture. I did some research and it now seems I can make use of your 
> goodself's AuthSSLProtocolSocketFactory in order to specify a client 
> certificate and that's assuming I would go the JSSE route and not reusing 
> the browser's https connection, which the current java plugin is allowing 
> me to do. That would be soooo painful to give up on since I imagine then I 
> would need to sign my applet and/or mess around with applet permissions 
> etc.
> 

As far as I know there is simply no way to trigger client SSL
authentication once connection has been established. You can either
perform client authentication in the browser while the connection is
being negotiated or you have to open a new connection from the applet
sandbox with all the design consequences that entail.

> > > I don't think the message I got (on the java plugin console) would be 
> of 
> > > much use, but let 
> > > me quote a bit anyway: 
> > > 
> > > java.net.SocketException: Default SSL context init failed: failed to 
> > > decrypt safe contents 
> > > entry: javax.crypto.BadPaddingException: Given final block not properly 
> 
> > > padded 
> > > at javax.net.ssl.DefaultSSLSocketFactory.createSocket(Unknown Source) 
> > > at 
> > 
> >This is clearly a problem with the SSL layer and not with HttpClient. 
> > 
> >Also consider getting your code to work outside the applet in a 
> >standalone application and once you are sure the SSL settings are sane, 
> >try moving your code back to the applet and see what happens. 
> > 
> >Running your code with SSL debug traces on may also be of some help 
> > 
> >-Djavax.net.debug=ssl,handshake,data,trustmanager 
> 
> Think I am in one of those situations where this "get it running as an app 
> first" debugging strategy won't work. To do that would mean no brower https 
> connection to use - need to go jsse, using your goodself's 
> AuthSSLProtocolSocketFactory and the only good thing about running it as an 
> app is that I can delay worrying about the applet's sandbox. 
> 
> There,  I am about to cry out my question to everyone now: Has anyone done 
> any https access in an applet with httpclient whilst using the browser's 
> https channel - i.e. not needing to obtain socket i/o permissions for the 
> applet?  A success story even when the server side doesn't require a client 
> certificate would be very encouraging.
> 

This cannot be done as HttpClient cannot be attached to an arbitrary
HttpUrlConnection. HttpClient is designed to work directly with
java.net.Sockets. I hope this answers your question.

Oleg

> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org