Re: Trust all certificates

2016-04-08 Thread Brent Putman
You can set the JSSE system property javax.net.debug to get a lot of debug output. It will probably tell you why the handshake fails. Try "javax.net.debug=ssl" or "javax.net.debug=all" . You can see all the options for that here: http://docs.oracle.com/javase/7/docs/technotes/guides/security/j

Re: Trust all certificates

2016-04-08 Thread Nick Chang
Hello, Have you tried the code suggested in this link? http://stackoverflow.com/questions/2642777/trusting-all-certificates-using-httpclient-over-https Nick On Fri, Apr 8, 2016 at 9:29 PM, Bernd Eckenfels wrote: > Hello, > > I suspect it is a problem with too short DH keys offered by Java 7 >

Re: Trust all certificates

2016-04-08 Thread Bernd Eckenfels
Hello, I suspect it is a problem with too short DH keys offered by Java 7 clients. You can try to turn TLS_DHE_* ciphers off. According to SSL Labs it does also support ECDHE which should then work fine. https://www.ssllabs.com/ssltest/analyze.html?d=www.trf5.jus.br&s=189.39.123.181&latest Grus

Re: Trust all certificates

2016-04-08 Thread Robson Roberto Souza Peixoto
Thanks a lot, Sam Wilson. I'll read it. It's work well on java 8, but not on java 7 =/ >From Google Chrome: ``` Your connection to www.trf5.jus.br is encrypted using a modern cipher suite. The connection uses TLS 1.2. The connection is encrypted and authenticated using AES_128_GCM and uses ECDHE_R

Re: Trust all certificates

2016-04-08 Thread Sam Wilson
There are quite a few documents out there that go over SSL/TLS. Really depends on what you need to know. Wikipedia might be a good place to start, and there's always google to find out more. I seem to remember Mozilla had some decent high level documentation, but I think they've marked it as ou

Re: Trust all certificates

2016-04-08 Thread Robson Roberto Souza Peixoto
I'm a complete noob. Are there resources to help-me understand the problem. On Fri, Apr 8, 2016 at 6:16 PM Sam Wilson wrote: > You can only turn off as much SSL validation as you control. The server > may also terminate a connection (say, for instance, it requires a client > SSL certificate.) >

Re: Trust all certificates

2016-04-08 Thread Sam Wilson
You can only turn off as much SSL validation as you control. The server may also terminate a connection (say, for instance, it requires a client SSL certificate.) On 4/8/16 4:53 PM, Robson Roberto Souza Peixoto wrote: But are there a way to disable the `SSL Verification`? I just wanna to igno

Re: Trust all certificates

2016-04-08 Thread Robson Roberto Souza Peixoto
But are there a way to disable the `SSL Verification`? I just wanna to ignore all SSL Verification. Thanks On Fri, Apr 8, 2016 at 5:26 PM Bernd Eckenfels wrote: > The exception you are showing means the server terminated the handshake > for some reason. Hard to say why. It might require a clie

Re: Trust all certificates

2016-04-08 Thread Bernd Eckenfels
The exception you are showing means the server terminated the handshake for some reason. Hard to say why. It might require a client cert or does not like yout proposed ciphers or ssl protocols. This particular exception seems not related to untrusted certificates, your different approaches are

Trust all certificates

2016-04-08 Thread Robson Roberto Souza Peixoto
Hi guys, I'm using the HC to crawler a lot of sites =D. It's working like a charm. I really in love with HC. But I'm getting the error `javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure` when I try to access a page with a invalid Certificate. I googled a lot and tried

RedirectStrategy and HttpHost

2016-04-08 Thread Sam Wilson
Hey httpclient-users, I've got another question for you! To make requests to a particular IP with a certain host I'm using: HttpClient.execute(HttpHost tgt, HttpRequest req) For example I'd give 127.0.0.1 as the target, while the request points to www.example.com. This works fine and

Re: releasing streamed connections back to connection pool

2016-04-08 Thread Tim Webster
I think I've found the problem. The Spring code isn't closing the input stream from the response after reading it. Easy to override and fix. Thanks for your help... On Fri, Apr 8, 2016 at 11:10 AM, Tim Webster wrote: > Hi sorry I'm not sure which question you are answering, but it sounds > l

Re: releasing streamed connections back to connection pool

2016-04-08 Thread Tim Webster
Hi sorry I'm not sure which question you are answering, but it sounds like you are saying that as long as I consume the response properly then the connections should be re-used properly (and not closed), despite the call to releaseConnection()? If that is so, why do we need the call to releaseCon

Re: releasing streamed connections back to connection pool

2016-04-08 Thread Oleg Kalnichevski
On Fri, 2016-04-08 at 11:02 +0100, Tim Webster wrote: > OK...so do you think I need to use this class to explicitly to consume the > response? I can see some methods on there for this. > > Also - I think the call to PostMethod.releaseConnection() will still close > it - do you have any idea if th

Re: releasing streamed connections back to connection pool

2016-04-08 Thread Tim Webster
OK...so do you think I need to use this class to explicitly to consume the response? I can see some methods on there for this. Also - I think the call to PostMethod.releaseConnection() will still close it - do you have any idea if this should / should not be used? Thanks, On Fri, Apr 8, 2016

AW: releasing streamed connections back to connection pool

2016-04-08 Thread Bernd Eckenfels
It looks like the HttpResponseProxy will be responsible for releasing the connection once the entity is consumed. Most likely by wrapping and tracking the input stream. Gruss Bernd -- http://bernd.eckenfels.net >From Win 10 Mobile Von: Tim Webster Gesendet: Freitag, 8. April 2016 11:42 An: ht

releasing streamed connections back to connection pool

2016-04-08 Thread Tim Webster
Hi, I'm using Spring's HttpComponentsHttpInvokerRequestExecutor in my application, configured with a PoolingHttpClientConnectionManager. It all works fine, except that when a request is executed, the HTTP connection that was used is closed after every request. This is a result of Spring calling