Re: Need help to use TLSv1.2 in java 1.4

Hi Gaurav,

We have done it and it works like a charm. this was the source code
I used as a base and I adapted it for our use of SSLSocketFactory
(creating a child class called TLSSocketFactory, which creates an
instance of TLSSocket, which wrapped and managed a subclass of
DefaultTlsClient, etc:

We have done it and it works like a charm. this was the source code
I used as a base and I adapted it for our use of SSLSocketFactory
(creating a child class called TLSSocketFactory, which creates an
instance of TLSSocket, which wrapped and managed a subclass of
DefaultTlsClient, etc:

We have done it and it works like a charm. this was the
source code I used as a base and I adapted it for our use
of SSLSocketFactory (creating a child class called
TLSSocketFactory, which creates an instance of TLSSocket,
which wrapped and managed a subclass of DefaultTlsClient,
etc:

Re: Need help to use TLSv1.2 in java 1.4

here's the apache client code in a nutshell -- please note that we
specify TLS-based connections with URL prefix tls:// so that we
don't mess with legacy connection code and socket factories...

so --- HttpClient will ask the registered Protocol (i.e. tls://) how
to open a socket via a socket factory. So you setup the socket
factory first, register the custom protocol and ask HttpClient to
connect to something like tls://example.com/tls/server
-- i.e. this is so that https://another.example.com/ssl/server
doesn't get forced to use the TLS code as well.

Re: Need help to use TLSv1.2 in java 1.4

quote:From the release notes here:http://java.sun.com/j2se/1.4.1/docs/relnotes/features.html#security
this quote:"The JSSE implementation provided in this release
includes strong cipher suites. However, due to U.S. export
control restrictions, this release does not allow alternate
"pluggable" SSL/TLS implementations to be used. For more
information, please see the JSSE Reference Guide."

I've not encountered that problem. this is probably due to me
using apache http client which avoid this restriction somehow. We
originally switched to apache http client because the built-in Sun
URL and socket implementations had bugs in timeout in connections
such that threads would hang forever trying to connect to servers
behind firewalls, etc. timeout were ignored.

quote:From the release notes here:http://java.sun.com/j2se/1.4.1/docs/relnotes/features.html#security
this quote:"The JSSE implementation provided in this release
includes strong cipher suites. However, due to U.S. export
control restrictions, this release does not allow alternate
"pluggable" SSL/TLS implementations to be used. For more
information, please see the JSSE Reference Guide."

I've not encountered that problem. this is probably due to me
using apache http client which avoid this restriction somehow. We
originally switched to apache http client because the built-in Sun
URL and socket implementations had bugs in timeout in connections
such that threads would hang forever trying to connect to servers
behind firewalls, etc. timeout were ignored.

quote:From the release notes here:http://java.sun.com/j2se/1.4.1/docs/relnotes/features.html#security this quote:"The JSSE implementation provided in
this release includes strong cipher suites. However, due
to U.S. export control restrictions, this release does
not allow alternate "pluggable" SSL/TLS implementations
to be used. For more information, please see the JSSE
Reference Guide."

I've not encountered that problem. this is probably
due to me using apache http client which avoid this
restriction somehow. We originally switched to apache http
client because the built-in Sun URL and socket
implementations had bugs in timeout in connections such that
threads would hang forever trying to connect to servers
behind firewalls, etc. timeout were ignored.

quote:From the release notes here:http://java.sun.com/j2se/1.4.1/docs/relnotes/features.html#security this quote:"The JSSE implementation provided in
this release includes strong cipher suites. However, due
to U.S. export control restrictions, this release does
not allow alternate "pluggable" SSL/TLS implementations
to be used. For more information, please see the JSSE
Reference Guide."

I've not encountered that problem. this is probably
due to me using apache http client which avoid this
restriction somehow. We originally switched to apache http
client because the built-in Sun URL and socket
implementations had bugs in timeout in connections such that
threads would hang forever trying to connect to servers
behind firewalls, etc. timeout were ignored.

quote:From the release notes here:http://java.sun.com/j2se/1.4.1/docs/relnotes/features.html#security this quote:"The JSSE implementation provided in
this release includes strong cipher suites. However, due
to U.S. export control restrictions, this release does
not allow alternate "pluggable" SSL/TLS implementations
to be used. For more information, please see the JSSE
Reference Guide."

I've not encountered that problem. this is probably
due to me using apache http client which avoid this
restriction somehow. We originally switched to apache http
client because the built-in Sun URL and socket
implementations had bugs in timeout in connections such that
threads would hang forever trying to connect to servers
behind firewalls, etc. timeout were ignored.

Re: Need help to use TLSv1.2 in java 1.4

right -- I replied earlier with that
forum link with people discussing that you can't plug in new JSSE
code (bouncycastle) into Sun-based URLConnection code. You'll
have to use something like apache's HttpClient.

quote:From the release notes here:http://java.sun.com/j2se/1.4.1/docs/relnotes/features.html#security this quote:"The JSSE implementation
provided in this release includes strong cipher
suites. However, due to U.S. export control
restrictions, this release does not allow
alternate "pluggable" SSL/TLS implementations to
be used. For more information, please see the
JSSE Reference Guide."

I've not encountered that problem. this is
probably due to me using apache http client which
avoid this restriction somehow. We originally
switched to apache http client because the built-in
Sun URL and socket implementations had bugs in
timeout in connections such that threads would hang
forever trying to connect to servers behind
firewalls, etc. timeout were ignored.

Re: Need help to use TLSv1.2 in java 1.4

right -- just keep pairing down the code to strip out these
variables. tsfcache, for instance, is a static cache of tls
factories because they are too expensive to create for each new
connection. and yes, that cache probably hold just one instance.
it was modeled on our other factory cache, etc etc etc....

unfortunately, I can't provide a complete independent working
sample right now. I won't have time until next week. keep
pairing down the code and remove variables and cruft I created and
you'll get a working sample. if you're still stuck by next week,
let me know.

Dan

On 2017-06-23 7:18 AM, Gaurav Tawale wrote:

Hi
Daniel ,

I have gone thorugh your https client code but it has some
variables which I did not find any reference like tsfcache.

quote:From the release notes here:http://java.sun.com/j2se/1.4.1/docs/relnotes/features.html#security this quote:"The JSSE implementation
provided in this release includes strong cipher
suites. However, due to U.S. export control
restrictions, this release does not allow
alternate "pluggable" SSL/TLS implementations to
be used. For more information, please see the
JSSE Reference Guide."

I've not encountered that problem. this is
probably due to me using apache http client which
avoid this restriction somehow. We originally
switched to apache http client because the built-in
Sun URL and socket implementations had bugs in
timeout in connections such that threads would hang
forever trying to connect to servers behind
firewalls, etc. timeout were ignored.

right -- just keep pairing down the code to strip out these
variables. tsfcache, for instance, is a static cache of tls
factories because they are too expensive to create for each new
connection. and yes, that cache probably hold just one instance.
it was modeled on our other factory cache, etc etc etc....

unfortunately, I can't provide a complete independent working
sample right now. I won't have time until next week. keep
pairing down the code and remove variables and cruft I created and
you'll get a working sample. if you're still stuck by next week,
let me know.

Dan

On 2017-06-23 7:18 AM, Gaurav Tawale wrote:

Hi
Daniel ,

I have gone thorugh your https client code but it has some
variables which I did not find any reference like tsfcache.

quote:From the release notes here:http://java.sun.com/j2se/1.4.1/docs/relnotes/features.html#security this quote:"The JSSE implementation
provided in this release includes strong cipher
suites. However, due to U.S. export control
restrictions, this release does not allow
alternate "pluggable" SSL/TLS implementations to
be used. For more information, please see the
JSSE Reference Guide."

I've not encountered that problem. this is
probably due to me using apache http client which
avoid this restriction somehow. We originally
switched to apache http client because the built-in
Sun URL and socket implementations had bugs in
timeout in connections such that threads would hang
forever trying to connect to servers behind
firewalls, etc. timeout were ignored.

right -- just keep pairing down the code to strip out these
variables. tsfcache, for instance, is a static cache of tls
factories because they are too expensive to create for each new
connection. and yes, that cache probably hold just one instance.
it was modeled on our other factory cache, etc etc etc....

unfortunately, I can't provide a complete independent working
sample right now. I won't have time until next week. keep
pairing down the code and remove variables and cruft I created and
you'll get a working sample. if you're still stuck by next week,
let me know.

Dan

On 2017-06-23 7:18 AM, Gaurav Tawale wrote:

Hi
Daniel ,

I have gone thorugh your https client code but it has some
variables which I did not find any reference like tsfcache.

quote:From the release notes here:http://java.sun.com/j2se/1.4.1/docs/relnotes/features.html#security this quote:"The JSSE implementation
provided in this release includes strong cipher
suites. However, due to U.S. export control
restrictions, this release does not allow
alternate "pluggable" SSL/TLS implementations to
be used. For more information, please see the
JSSE Reference Guide."

I've not encountered that problem. this is
probably due to me using apache http client which
avoid this restriction somehow. We originally
switched to apache http client because the built-in
Sun URL and socket implementations had bugs in
timeout in connections such that threads would hang
forever trying to connect to servers behind
firewalls, etc. timeout were ignored.

right -- just keep pairing down the code to strip out
these variables. tsfcache, for instance, is a static
cache of tls factories because they are too expensive
to create for each new connection. and yes, that
cache probably hold just one instance. it was modeled
on our other factory cache, etc etc etc....

unfortunately, I can't provide a complete independent
working sample right now. I won't have time until
next week. keep pairing down the code and remove
variables and cruft I created and you'll get a working
sample. if you're still stuck by next week, let me
know.

Dan

On 2017-06-23 7:18 AM, Gaurav Tawale wrote:

Hi Daniel ,

I have gone thorugh your https client code but it
has some variables which I did not find any
reference like tsfcache.

quote:From the release notes here:http://java.sun.com/j2se/1.4.1/docs/relnotes/features.html#security this quote:"The JSSE
implementation provided in this
release includes strong cipher
suites. However, due to U.S. export
control restrictions, this release
does not allow alternate "pluggable"
SSL/TLS implementations to be used.
For more information, please see the
JSSE Reference Guide."

I've not encountered that problem.
this is probably due to me using apache
http client which avoid this restriction
somehow. We originally switched to
apache http client because the built-in
Sun URL and socket implementations had
bugs in timeout in connections such that
threads would hang forever trying to
connect to servers behind firewalls,
etc. timeout were ignored.