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 Mohan Radhakrishnan <ra...@gmail.com> on 2017/11/04 13:01:28 UTC
SSL Certificate exceptions and defensive coding
Hi,
I am invoking a HTTPS SOAP service and this is what I think is
happening. It is one-way SSL. The JSSE implementation automagically adds it
to the client's truststore and ensures that the SOAP call is successful.
This question is based on this assumption.
When I read
https://www.ssl.com/guide/ssl-best-practices-a-quick-and-dirty-guide/ there
are various SSL exceptions and checks that
are required. I code the client. How do I trap the various exceptions ?
Which list of exceptions should I use for SSL ?
How do I know the the HttpClient uses the latest security patches in my JDK
8 ? It should automatically be secure. Right ?
Thanks,
Mohan
Re: SSL Certificate exceptions and defensive coding
Posted by Mohan Radhakrishnan <ra...@gmail.com>.
I will try SSLContext and loadTrustMaterial() and ask any further questions.
Thanks,
Mohan
On 8 November 2017 at 01:43, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mohan,
>
> On 11/7/17 6:31 AM, Mohan Radhakrishnan wrote:
> > I have imported the server certificate into a new truststore.( not
> > cacerts ). with one line of code to set the system property
> > javax.net.ssl.trustStrore to point to my truststore.
>
> You shouldn't do this: you are setting the truststore for the whole
> JVM and not just this particular connection.
>
> Instead, you should write proper Java code to configure your
> HttpClient to use your preferred truststore.
>
> - -chris
>
> > On 6 November 2017 at 13:36, Bernd Eckenfels
> > <ec...@zusammenkunft.net> wrote:
> >
> >> Without knowing your code it is hard to tell what is configured.
> >> You can implement multiple strategies for server certificate
> >> checking (including to ignore the checks or use the default
> >> cacerts trust store)
> >>
> >> Gruss Bernd -- http://bernd.eckenfels.net
> >> ________________________________ From: Mohan Radhakrishnan
> >> <ra...@gmail.com> Sent: Monday, November 6, 2017
> >> 8:48:42 AM To: HttpClient User Discussion Subject: Re: SSL
> >> Certificate exceptions and defensive coding
> >>
> >> Hello,
> >>
> >> Could you point to some sample ? When I invoke this Https WSDL
> >> URL I do get a certificate in the browser. The URL pointing to
> >> the SOAP service is also a HTTPS URL.
> >>
> >> Does this mean that the server presents its certificate to the
> >> client which has to trust it ? How does HttpClient know how to
> >> trust it without the truststore ?
> >>
> >> The following is unrelated to my original question but this is
> >> what I observe.
> >>
> >> When I generate JAX-WS classes I need to import the WSDL URL
> >> certificate into my trust store and set the system properly.
> >>
> >> Thanks, Mohan
> >>
> >> On 5 November 2017 at 22:38, Oleg Kalnichevski <ol...@apache.org>
> >> wrote:
> >>
> >>> On Sun, 2017-11-05 at 08:41 +0530, Mohan Radhakrishnan wrote:
> >>>> I do have a trustore into which I have imported the server
> >>>> certificate. I set a system property and use it.
> >>>>
> >>>> System.setProperty("javax.net.ssl.trustStrore",
> >>>> "trustStore");
> >>>>
> >>>> JSSE should be able to use it. I think. RIght ? Don't see a
> >>>> problem at this time. Just getting some clarifications.
> >>>>
> >>>
> >>> HttpClient does not take system properties into account by
> >>> default. You need to explicitly instruct to do so when building
> >>> HttpClient instances.
> >>>
> >>> Oleg
> >>>
> >>>
> >>>> Thanks, Mohan
> >>>>
> >>>> On 5 November 2017 at 03:28, Bindul Bhowmik
> >>>> <bi...@gmail.com> wrote:
> >>>>
> >>>>> Mohan,
> >>>>>
> >>>>> On Sat, Nov 4, 2017 at 6:01 AM, Mohan Radhakrishnan
> >>>>> <ra...@gmail.com> wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> Let me start by mentioning that Http Client does not
> >>>>> implement its own cyrpto algorithms or SSL/TLS protocols.
> >>>>> It relies on the underlying Java JSSE implementation to
> >>>>> create secure sockets. And unless you have plugged in an
> >>>>> alternate JSSE provider, you are using the JSSE
> >>>>> implementation packaged with your JRE. Having said that,
> >>>>> Http Client does allow some customization to the secure
> >>>>> socket creation process using SSLConnectionSocketFactory
> >>>>> [1]. This allows you to use an alternate trust store, host
> >>>>> name verifier, etc.. The latter being especially valuable
> >>>>> during development/testing, but should not be used in
> >>>>> production IMO. To see how you can customize the SSL
> >>>>> socket creation, please read the 'Connection management'
> >>>>> chapter in the Http Client tutorial [2].
> >>>>>
> >>>>>> I am invoking a HTTPS SOAP service and this is what I
> >>>>>> think is happening. It is one-way SSL. The JSSE
> >>>>>> implementation automagically adds
> >>>>>
> >>>>> it
> >>>>>> to the client's truststore and ensures that the SOAP call
> >>>>>> is successful.
> >>>>>
> >>>>> I am not sure that is accurate. If the server you are
> >>>>> targeting uses a certificate signed by one of the trusted
> >>>>> CAs (or a CA signed by a trusted CA) in your trust store,
> >>>>> the secure socket will be established. The client does not
> >>>>> alter the trust store automagically, unless you have done
> >>>>> it yourself, or are using a custom trust store (other than
> >>>>> say the cacerts that ships with Oracle JRE).
> >>>>>
> >>>>>>
> >>>>>> This question is based on this assumption. When I read
> >>>>>> https://www.ssl.com/guide/ssl-best-practices-a-quick-and-dirty-gu
> >>>>>>
> >>>>>>
> ide/
> >>>>>
> >>>>> there
> >>>>>> are various SSL exceptions and checks that are required.
> >>>>>> I code the client. How do I trap the various exceptions
> >>>>>> ? Which list of exceptions should I use for SSL ?
> >>>>>
> >>>>> I am not sure I understand the question, but if you need to
> >>>>> catch all exceptions, see the JSSE Reference Guide [3] on
> >>>>> exceptions that can come from the SSL context. I guess the
> >>>>> most important one will be javax.net.ssl.SSLException and
> >>>>> its sub-classes. As far as I can tell, HC adds
> >>>>> org.apache.http.conn.ssl.SSLInitializationException and of
> >>>>> course most connect methods can throw IOException.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> How do I know the the HttpClient uses the latest security
> >>>>>> patches in my
> >>>>>
> >>>>> JDK
> >>>>>> 8 ? It should automatically be secure. Right ?
> >>>>>
> >>>>> As I noted above, HC is using the configured or default
> >>>>> JSSE implementation in your JRE. If that is patched, you
> >>>>> will be as secure as that.
> >>>>>
> >>>>>>
> >>>>>> Thanks, Mohan
> >>>>>
> >>>>> Regards, Bindul
> >>>>>
> >>>>> [1] https://hc.apache.org/httpcomponents-client-ga/
> >>>>> httpclient/apidocs/org/apache/http/conn/ssl/SSLConnectionSocketFac
> t
> >>>>>
> >>>>>
> ory.
> >>>>> html [2]
> >>>>> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/
> >>>>>
> >>>>>
> >>>>>
> - -----------------------------------------------------------------
> >>>>> ---- To unsubscribe, e-mail:
> >>>>> httpclient-users-unsubscribe@hc.apache.org For additional
> >>>>> commands, e-mail: httpclient-users-help@hc.apache.or g
> >>>>>
> >>>>>
> >>>
> >>> --------------------------------------------------------------------
> - -
> >>>
> >>>
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> >>> For additional commands, e-mail:
> >>> httpclient-users-help@hc.apache.org
> >>>
> >>>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloCE/cdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgPXw/7BLYLaYSSGQSWQAbL
> k8PV0z1ndN5zSJQv/2Po/hQ5HSWKa9BMO03+41gUAJb2CkpmpfsOHhwQZPoy3tP8
> NIm0wmRmD9BnXoik2AusKTy/KGh9tejrBgF+bYViXEgW/RyHGHHOWvFlBo4YcimX
> ZSq42HpJP4+rzy21Sx/Ri3motwBq1ONQgZibTfFF89dTRV4F+IBH74W7Jyg1jLlp
> txQTxIUGGKUfA4E69dvwKHw32uY8T9z65lv/ciBhS6i+n5qPQOb4Ry6xPZIAmrCo
> qax6emf93q9opLY4ee02mt4Djh+X2BMVL36ryAHfw2JlJNZAmPqB0+cZ8N5KsHxr
> ZOrX4sRKfeteVhNV+mCkjMtvWuV+9vxKKWt3v3mh61tLKxk077+g6wuGwG6EiIzm
> EWZnG2yVYnUX51O7gonvGAuUfjjPnl4GFRGtxNGit3E5Pa19TONFf4lG6pxDqxza
> FiF6HQV+WL6FdiXORSrFM72TXLat/HauyZbIWrQo/bx+S9uCGkEcgXmS7Y+k8J9Q
> lTDIA2TmQW4KfPXreVW2OPq4g2mZ798Dd+OtDUAlPlcA83Hl6gqvWF4FygfOrQhF
> sLpz4SZdtZNvRfqtzNPkpOnIv0d3FypqaiUZs8jxKiz/Ca6d6jsuJryxhOKrEewo
> p2QplkK/JDZCYh3sbiOa3223OK4=
> =lWME
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: SSL Certificate exceptions and defensive coding
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mohan,
On 11/7/17 6:31 AM, Mohan Radhakrishnan wrote:
> I have imported the server certificate into a new truststore.( not
> cacerts ). with one line of code to set the system property
> javax.net.ssl.trustStrore to point to my truststore.
You shouldn't do this: you are setting the truststore for the whole
JVM and not just this particular connection.
Instead, you should write proper Java code to configure your
HttpClient to use your preferred truststore.
- -chris
> On 6 November 2017 at 13:36, Bernd Eckenfels
> <ec...@zusammenkunft.net> wrote:
>
>> Without knowing your code it is hard to tell what is configured.
>> You can implement multiple strategies for server certificate
>> checking (including to ignore the checks or use the default
>> cacerts trust store)
>>
>> Gruss Bernd -- http://bernd.eckenfels.net
>> ________________________________ From: Mohan Radhakrishnan
>> <ra...@gmail.com> Sent: Monday, November 6, 2017
>> 8:48:42 AM To: HttpClient User Discussion Subject: Re: SSL
>> Certificate exceptions and defensive coding
>>
>> Hello,
>>
>> Could you point to some sample ? When I invoke this Https WSDL
>> URL I do get a certificate in the browser. The URL pointing to
>> the SOAP service is also a HTTPS URL.
>>
>> Does this mean that the server presents its certificate to the
>> client which has to trust it ? How does HttpClient know how to
>> trust it without the truststore ?
>>
>> The following is unrelated to my original question but this is
>> what I observe.
>>
>> When I generate JAX-WS classes I need to import the WSDL URL
>> certificate into my trust store and set the system properly.
>>
>> Thanks, Mohan
>>
>> On 5 November 2017 at 22:38, Oleg Kalnichevski <ol...@apache.org>
>> wrote:
>>
>>> On Sun, 2017-11-05 at 08:41 +0530, Mohan Radhakrishnan wrote:
>>>> I do have a trustore into which I have imported the server
>>>> certificate. I set a system property and use it.
>>>>
>>>> System.setProperty("javax.net.ssl.trustStrore",
>>>> "trustStore");
>>>>
>>>> JSSE should be able to use it. I think. RIght ? Don't see a
>>>> problem at this time. Just getting some clarifications.
>>>>
>>>
>>> HttpClient does not take system properties into account by
>>> default. You need to explicitly instruct to do so when building
>>> HttpClient instances.
>>>
>>> Oleg
>>>
>>>
>>>> Thanks, Mohan
>>>>
>>>> On 5 November 2017 at 03:28, Bindul Bhowmik
>>>> <bi...@gmail.com> wrote:
>>>>
>>>>> Mohan,
>>>>>
>>>>> On Sat, Nov 4, 2017 at 6:01 AM, Mohan Radhakrishnan
>>>>> <ra...@gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>
>>>>> Let me start by mentioning that Http Client does not
>>>>> implement its own cyrpto algorithms or SSL/TLS protocols.
>>>>> It relies on the underlying Java JSSE implementation to
>>>>> create secure sockets. And unless you have plugged in an
>>>>> alternate JSSE provider, you are using the JSSE
>>>>> implementation packaged with your JRE. Having said that,
>>>>> Http Client does allow some customization to the secure
>>>>> socket creation process using SSLConnectionSocketFactory
>>>>> [1]. This allows you to use an alternate trust store, host
>>>>> name verifier, etc.. The latter being especially valuable
>>>>> during development/testing, but should not be used in
>>>>> production IMO. To see how you can customize the SSL
>>>>> socket creation, please read the 'Connection management'
>>>>> chapter in the Http Client tutorial [2].
>>>>>
>>>>>> I am invoking a HTTPS SOAP service and this is what I
>>>>>> think is happening. It is one-way SSL. The JSSE
>>>>>> implementation automagically adds
>>>>>
>>>>> it
>>>>>> to the client's truststore and ensures that the SOAP call
>>>>>> is successful.
>>>>>
>>>>> I am not sure that is accurate. If the server you are
>>>>> targeting uses a certificate signed by one of the trusted
>>>>> CAs (or a CA signed by a trusted CA) in your trust store,
>>>>> the secure socket will be established. The client does not
>>>>> alter the trust store automagically, unless you have done
>>>>> it yourself, or are using a custom trust store (other than
>>>>> say the cacerts that ships with Oracle JRE).
>>>>>
>>>>>>
>>>>>> This question is based on this assumption. When I read
>>>>>> https://www.ssl.com/guide/ssl-best-practices-a-quick-and-dirty-gu
>>>>>>
>>>>>>
ide/
>>>>>
>>>>> there
>>>>>> are various SSL exceptions and checks that are required.
>>>>>> I code the client. How do I trap the various exceptions
>>>>>> ? Which list of exceptions should I use for SSL ?
>>>>>
>>>>> I am not sure I understand the question, but if you need to
>>>>> catch all exceptions, see the JSSE Reference Guide [3] on
>>>>> exceptions that can come from the SSL context. I guess the
>>>>> most important one will be javax.net.ssl.SSLException and
>>>>> its sub-classes. As far as I can tell, HC adds
>>>>> org.apache.http.conn.ssl.SSLInitializationException and of
>>>>> course most connect methods can throw IOException.
>>>>>
>>>>>
>>>>>>
>>>>>> How do I know the the HttpClient uses the latest security
>>>>>> patches in my
>>>>>
>>>>> JDK
>>>>>> 8 ? It should automatically be secure. Right ?
>>>>>
>>>>> As I noted above, HC is using the configured or default
>>>>> JSSE implementation in your JRE. If that is patched, you
>>>>> will be as secure as that.
>>>>>
>>>>>>
>>>>>> Thanks, Mohan
>>>>>
>>>>> Regards, Bindul
>>>>>
>>>>> [1] https://hc.apache.org/httpcomponents-client-ga/
>>>>> httpclient/apidocs/org/apache/http/conn/ssl/SSLConnectionSocketFac
t
>>>>>
>>>>>
ory.
>>>>> html [2]
>>>>> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/
>>>>>
>>>>>
>>>>>
- -----------------------------------------------------------------
>>>>> ---- To unsubscribe, e-mail:
>>>>> httpclient-users-unsubscribe@hc.apache.org For additional
>>>>> commands, e-mail: httpclient-users-help@hc.apache.or g
>>>>>
>>>>>
>>>
>>> --------------------------------------------------------------------
- -
>>>
>>>
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>> For additional commands, e-mail:
>>> httpclient-users-help@hc.apache.org
>>>
>>>
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloCE/cdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgPXw/7BLYLaYSSGQSWQAbL
k8PV0z1ndN5zSJQv/2Po/hQ5HSWKa9BMO03+41gUAJb2CkpmpfsOHhwQZPoy3tP8
NIm0wmRmD9BnXoik2AusKTy/KGh9tejrBgF+bYViXEgW/RyHGHHOWvFlBo4YcimX
ZSq42HpJP4+rzy21Sx/Ri3motwBq1ONQgZibTfFF89dTRV4F+IBH74W7Jyg1jLlp
txQTxIUGGKUfA4E69dvwKHw32uY8T9z65lv/ciBhS6i+n5qPQOb4Ry6xPZIAmrCo
qax6emf93q9opLY4ee02mt4Djh+X2BMVL36ryAHfw2JlJNZAmPqB0+cZ8N5KsHxr
ZOrX4sRKfeteVhNV+mCkjMtvWuV+9vxKKWt3v3mh61tLKxk077+g6wuGwG6EiIzm
EWZnG2yVYnUX51O7gonvGAuUfjjPnl4GFRGtxNGit3E5Pa19TONFf4lG6pxDqxza
FiF6HQV+WL6FdiXORSrFM72TXLat/HauyZbIWrQo/bx+S9uCGkEcgXmS7Y+k8J9Q
lTDIA2TmQW4KfPXreVW2OPq4g2mZ798Dd+OtDUAlPlcA83Hl6gqvWF4FygfOrQhF
sLpz4SZdtZNvRfqtzNPkpOnIv0d3FypqaiUZs8jxKiz/Ca6d6jsuJryxhOKrEewo
p2QplkK/JDZCYh3sbiOa3223OK4=
=lWME
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: SSL Certificate exceptions and defensive coding
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
And is it working or not? How do you construct the SSLContext and do you use loadTrustMaterial()?
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Mohan Radhakrishnan <ra...@gmail.com>
Sent: Tuesday, November 7, 2017 12:31:33 PM
To: HttpClient User Discussion
Subject: Re: SSL Certificate exceptions and defensive coding
I have imported the server certificate into a new truststore.( not cacerts
). with one line of code to set the system property javax.net.ssl.trustStrore
to point to my truststore.
Thanks,
Mohan
On 6 November 2017 at 13:36, Bernd Eckenfels <ec...@zusammenkunft.net> wrote:
> Without knowing your code it is hard to tell what is configured. You can
> implement multiple strategies for server certificate checking (including to
> ignore the checks or use the default cacerts trust store)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: Mohan Radhakrishnan <ra...@gmail.com>
> Sent: Monday, November 6, 2017 8:48:42 AM
> To: HttpClient User Discussion
> Subject: Re: SSL Certificate exceptions and defensive coding
>
> Hello,
>
> Could you point to some sample ? When I invoke this Https WSDL URL I do get
> a certificate in the browser. The URL pointing to the SOAP service is also
> a HTTPS URL.
>
> Does this mean that the server presents its certificate to the client which
> has to trust it ? How does HttpClient know how to trust it without the
> truststore ?
>
> The following is unrelated to my original question but this is what I
> observe.
>
> When I generate JAX-WS classes I need to import the WSDL URL certificate
> into my trust store and set the system properly.
>
> Thanks,
> Mohan
>
> On 5 November 2017 at 22:38, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > On Sun, 2017-11-05 at 08:41 +0530, Mohan Radhakrishnan wrote:
> > > I do have a trustore into which I have imported the server
> > > certificate. I
> > > set a system property and use it.
> > >
> > > System.setProperty("javax.net.ssl.trustStrore", "trustStore");
> > >
> > > JSSE should be able to use it. I think. RIght ? Don't see a problem
> > > at this
> > > time. Just getting some clarifications.
> > >
> >
> > HttpClient does not take system properties into account by default. You
> > need to explicitly instruct to do so when building HttpClient
> > instances.
> >
> > Oleg
> >
> >
> > > Thanks,
> > > Mohan
> > >
> > > On 5 November 2017 at 03:28, Bindul Bhowmik <bi...@gmail.com>
> > > wrote:
> > >
> > > > Mohan,
> > > >
> > > > On Sat, Nov 4, 2017 at 6:01 AM, Mohan Radhakrishnan
> > > > <ra...@gmail.com> wrote:
> > > > > Hi,
> > > > >
> > > > >
> > > >
> > > > Let me start by mentioning that Http Client does not implement its
> > > > own
> > > > cyrpto algorithms or SSL/TLS protocols. It relies on the underlying
> > > > Java JSSE implementation to create secure sockets. And unless you
> > > > have
> > > > plugged in an alternate JSSE provider, you are using the JSSE
> > > > implementation packaged with your JRE. Having said that, Http
> > > > Client
> > > > does allow some customization to the secure socket creation process
> > > > using SSLConnectionSocketFactory [1]. This allows you to use an
> > > > alternate trust store, host name verifier, etc.. The latter being
> > > > especially valuable during development/testing, but should not be
> > > > used
> > > > in production IMO. To see how you can customize the SSL socket
> > > > creation, please read the 'Connection management' chapter in the
> > > > Http
> > > > Client tutorial [2].
> > > >
> > > > > I am invoking a HTTPS SOAP service and this is what I
> > > > > think is
> > > > > happening. It is one-way SSL. The JSSE implementation
> > > > > automagically adds
> > > >
> > > > it
> > > > > to the client's truststore and ensures that the SOAP call is
> > > > > successful.
> > > >
> > > > I am not sure that is accurate. If the server you are targeting
> > > > uses a
> > > > certificate signed by one of the trusted CAs (or a CA signed by a
> > > > trusted CA) in your trust store, the secure socket will be
> > > > established. The client does not alter the trust store
> > > > automagically,
> > > > unless you have done it yourself, or are using a custom trust store
> > > > (other than say the cacerts that ships with Oracle JRE).
> > > >
> > > > >
> > > > > This question is based on this assumption.
> > > > > When I read
> > > > > https://www.ssl.com/guide/ssl-best-practices-a-quick-and-dirty-gu
> > > > > ide/
> > > >
> > > > there
> > > > > are various SSL exceptions and checks that
> > > > > are required. I code the client. How do I trap the various
> > > > > exceptions ?
> > > > > Which list of exceptions should I use for SSL ?
> > > >
> > > > I am not sure I understand the question, but if you need to catch
> > > > all
> > > > exceptions, see the JSSE Reference Guide [3] on exceptions that can
> > > > come from the SSL context. I guess the most important one will be
> > > > javax.net.ssl.SSLException and its sub-classes. As far as I can
> > > > tell,
> > > > HC adds org.apache.http.conn.ssl.SSLInitializationException and of
> > > > course most connect methods can throw IOException.
> > > >
> > > >
> > > > >
> > > > > How do I know the the HttpClient uses the latest security patches
> > > > > in my
> > > >
> > > > JDK
> > > > > 8 ? It should automatically be secure. Right ?
> > > >
> > > > As I noted above, HC is using the configured or default JSSE
> > > > implementation in your JRE. If that is patched, you will be as
> > > > secure
> > > > as that.
> > > >
> > > > >
> > > > > Thanks,
> > > > > Mohan
> > > >
> > > > Regards,
> > > > Bindul
> > > >
> > > > [1] https://hc.apache.org/httpcomponents-client-ga/
> > > > httpclient/apidocs/org/apache/http/conn/ssl/SSLConnectionSocketFact
> > > > ory.
> > > > html
> > > > [2] http://hc.apache.org/httpcomponents-client-ga/tutorial/html/
> > > >
> > > > -----------------------------------------------------------------
> > > > ----
> > > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > > For additional commands, e-mail: httpclient-users-help@hc.apache.or
> > > > g
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
>
Re: SSL Certificate exceptions and defensive coding
Posted by Mohan Radhakrishnan <ra...@gmail.com>.
I have imported the server certificate into a new truststore.( not cacerts
). with one line of code to set the system property javax.net.ssl.trustStrore
to point to my truststore.
Thanks,
Mohan
On 6 November 2017 at 13:36, Bernd Eckenfels <ec...@zusammenkunft.net> wrote:
> Without knowing your code it is hard to tell what is configured. You can
> implement multiple strategies for server certificate checking (including to
> ignore the checks or use the default cacerts trust store)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: Mohan Radhakrishnan <ra...@gmail.com>
> Sent: Monday, November 6, 2017 8:48:42 AM
> To: HttpClient User Discussion
> Subject: Re: SSL Certificate exceptions and defensive coding
>
> Hello,
>
> Could you point to some sample ? When I invoke this Https WSDL URL I do get
> a certificate in the browser. The URL pointing to the SOAP service is also
> a HTTPS URL.
>
> Does this mean that the server presents its certificate to the client which
> has to trust it ? How does HttpClient know how to trust it without the
> truststore ?
>
> The following is unrelated to my original question but this is what I
> observe.
>
> When I generate JAX-WS classes I need to import the WSDL URL certificate
> into my trust store and set the system properly.
>
> Thanks,
> Mohan
>
> On 5 November 2017 at 22:38, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > On Sun, 2017-11-05 at 08:41 +0530, Mohan Radhakrishnan wrote:
> > > I do have a trustore into which I have imported the server
> > > certificate. I
> > > set a system property and use it.
> > >
> > > System.setProperty("javax.net.ssl.trustStrore", "trustStore");
> > >
> > > JSSE should be able to use it. I think. RIght ? Don't see a problem
> > > at this
> > > time. Just getting some clarifications.
> > >
> >
> > HttpClient does not take system properties into account by default. You
> > need to explicitly instruct to do so when building HttpClient
> > instances.
> >
> > Oleg
> >
> >
> > > Thanks,
> > > Mohan
> > >
> > > On 5 November 2017 at 03:28, Bindul Bhowmik <bi...@gmail.com>
> > > wrote:
> > >
> > > > Mohan,
> > > >
> > > > On Sat, Nov 4, 2017 at 6:01 AM, Mohan Radhakrishnan
> > > > <ra...@gmail.com> wrote:
> > > > > Hi,
> > > > >
> > > > >
> > > >
> > > > Let me start by mentioning that Http Client does not implement its
> > > > own
> > > > cyrpto algorithms or SSL/TLS protocols. It relies on the underlying
> > > > Java JSSE implementation to create secure sockets. And unless you
> > > > have
> > > > plugged in an alternate JSSE provider, you are using the JSSE
> > > > implementation packaged with your JRE. Having said that, Http
> > > > Client
> > > > does allow some customization to the secure socket creation process
> > > > using SSLConnectionSocketFactory [1]. This allows you to use an
> > > > alternate trust store, host name verifier, etc.. The latter being
> > > > especially valuable during development/testing, but should not be
> > > > used
> > > > in production IMO. To see how you can customize the SSL socket
> > > > creation, please read the 'Connection management' chapter in the
> > > > Http
> > > > Client tutorial [2].
> > > >
> > > > > I am invoking a HTTPS SOAP service and this is what I
> > > > > think is
> > > > > happening. It is one-way SSL. The JSSE implementation
> > > > > automagically adds
> > > >
> > > > it
> > > > > to the client's truststore and ensures that the SOAP call is
> > > > > successful.
> > > >
> > > > I am not sure that is accurate. If the server you are targeting
> > > > uses a
> > > > certificate signed by one of the trusted CAs (or a CA signed by a
> > > > trusted CA) in your trust store, the secure socket will be
> > > > established. The client does not alter the trust store
> > > > automagically,
> > > > unless you have done it yourself, or are using a custom trust store
> > > > (other than say the cacerts that ships with Oracle JRE).
> > > >
> > > > >
> > > > > This question is based on this assumption.
> > > > > When I read
> > > > > https://www.ssl.com/guide/ssl-best-practices-a-quick-and-dirty-gu
> > > > > ide/
> > > >
> > > > there
> > > > > are various SSL exceptions and checks that
> > > > > are required. I code the client. How do I trap the various
> > > > > exceptions ?
> > > > > Which list of exceptions should I use for SSL ?
> > > >
> > > > I am not sure I understand the question, but if you need to catch
> > > > all
> > > > exceptions, see the JSSE Reference Guide [3] on exceptions that can
> > > > come from the SSL context. I guess the most important one will be
> > > > javax.net.ssl.SSLException and its sub-classes. As far as I can
> > > > tell,
> > > > HC adds org.apache.http.conn.ssl.SSLInitializationException and of
> > > > course most connect methods can throw IOException.
> > > >
> > > >
> > > > >
> > > > > How do I know the the HttpClient uses the latest security patches
> > > > > in my
> > > >
> > > > JDK
> > > > > 8 ? It should automatically be secure. Right ?
> > > >
> > > > As I noted above, HC is using the configured or default JSSE
> > > > implementation in your JRE. If that is patched, you will be as
> > > > secure
> > > > as that.
> > > >
> > > > >
> > > > > Thanks,
> > > > > Mohan
> > > >
> > > > Regards,
> > > > Bindul
> > > >
> > > > [1] https://hc.apache.org/httpcomponents-client-ga/
> > > > httpclient/apidocs/org/apache/http/conn/ssl/SSLConnectionSocketFact
> > > > ory.
> > > > html
> > > > [2] http://hc.apache.org/httpcomponents-client-ga/tutorial/html/
> > > >
> > > > -----------------------------------------------------------------
> > > > ----
> > > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > > For additional commands, e-mail: httpclient-users-help@hc.apache.or
> > > > g
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
>
Re: SSL Certificate exceptions and defensive coding
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Without knowing your code it is hard to tell what is configured. You can implement multiple strategies for server certificate checking (including to ignore the checks or use the default cacerts trust store)
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Mohan Radhakrishnan <ra...@gmail.com>
Sent: Monday, November 6, 2017 8:48:42 AM
To: HttpClient User Discussion
Subject: Re: SSL Certificate exceptions and defensive coding
Hello,
Could you point to some sample ? When I invoke this Https WSDL URL I do get
a certificate in the browser. The URL pointing to the SOAP service is also
a HTTPS URL.
Does this mean that the server presents its certificate to the client which
has to trust it ? How does HttpClient know how to trust it without the
truststore ?
The following is unrelated to my original question but this is what I
observe.
When I generate JAX-WS classes I need to import the WSDL URL certificate
into my trust store and set the system properly.
Thanks,
Mohan
On 5 November 2017 at 22:38, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sun, 2017-11-05 at 08:41 +0530, Mohan Radhakrishnan wrote:
> > I do have a trustore into which I have imported the server
> > certificate. I
> > set a system property and use it.
> >
> > System.setProperty("javax.net.ssl.trustStrore", "trustStore");
> >
> > JSSE should be able to use it. I think. RIght ? Don't see a problem
> > at this
> > time. Just getting some clarifications.
> >
>
> HttpClient does not take system properties into account by default. You
> need to explicitly instruct to do so when building HttpClient
> instances.
>
> Oleg
>
>
> > Thanks,
> > Mohan
> >
> > On 5 November 2017 at 03:28, Bindul Bhowmik <bi...@gmail.com>
> > wrote:
> >
> > > Mohan,
> > >
> > > On Sat, Nov 4, 2017 at 6:01 AM, Mohan Radhakrishnan
> > > <ra...@gmail.com> wrote:
> > > > Hi,
> > > >
> > > >
> > >
> > > Let me start by mentioning that Http Client does not implement its
> > > own
> > > cyrpto algorithms or SSL/TLS protocols. It relies on the underlying
> > > Java JSSE implementation to create secure sockets. And unless you
> > > have
> > > plugged in an alternate JSSE provider, you are using the JSSE
> > > implementation packaged with your JRE. Having said that, Http
> > > Client
> > > does allow some customization to the secure socket creation process
> > > using SSLConnectionSocketFactory [1]. This allows you to use an
> > > alternate trust store, host name verifier, etc.. The latter being
> > > especially valuable during development/testing, but should not be
> > > used
> > > in production IMO. To see how you can customize the SSL socket
> > > creation, please read the 'Connection management' chapter in the
> > > Http
> > > Client tutorial [2].
> > >
> > > > I am invoking a HTTPS SOAP service and this is what I
> > > > think is
> > > > happening. It is one-way SSL. The JSSE implementation
> > > > automagically adds
> > >
> > > it
> > > > to the client's truststore and ensures that the SOAP call is
> > > > successful.
> > >
> > > I am not sure that is accurate. If the server you are targeting
> > > uses a
> > > certificate signed by one of the trusted CAs (or a CA signed by a
> > > trusted CA) in your trust store, the secure socket will be
> > > established. The client does not alter the trust store
> > > automagically,
> > > unless you have done it yourself, or are using a custom trust store
> > > (other than say the cacerts that ships with Oracle JRE).
> > >
> > > >
> > > > This question is based on this assumption.
> > > > When I read
> > > > https://www.ssl.com/guide/ssl-best-practices-a-quick-and-dirty-gu
> > > > ide/
> > >
> > > there
> > > > are various SSL exceptions and checks that
> > > > are required. I code the client. How do I trap the various
> > > > exceptions ?
> > > > Which list of exceptions should I use for SSL ?
> > >
> > > I am not sure I understand the question, but if you need to catch
> > > all
> > > exceptions, see the JSSE Reference Guide [3] on exceptions that can
> > > come from the SSL context. I guess the most important one will be
> > > javax.net.ssl.SSLException and its sub-classes. As far as I can
> > > tell,
> > > HC adds org.apache.http.conn.ssl.SSLInitializationException and of
> > > course most connect methods can throw IOException.
> > >
> > >
> > > >
> > > > How do I know the the HttpClient uses the latest security patches
> > > > in my
> > >
> > > JDK
> > > > 8 ? It should automatically be secure. Right ?
> > >
> > > As I noted above, HC is using the configured or default JSSE
> > > implementation in your JRE. If that is patched, you will be as
> > > secure
> > > as that.
> > >
> > > >
> > > > Thanks,
> > > > Mohan
> > >
> > > Regards,
> > > Bindul
> > >
> > > [1] https://hc.apache.org/httpcomponents-client-ga/
> > > httpclient/apidocs/org/apache/http/conn/ssl/SSLConnectionSocketFact
> > > ory.
> > > html
> > > [2] http://hc.apache.org/httpcomponents-client-ga/tutorial/html/
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.or
> > > g
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: SSL Certificate exceptions and defensive coding
Posted by Mohan Radhakrishnan <ra...@gmail.com>.
Hello,
Could you point to some sample ? When I invoke this Https WSDL URL I do get
a certificate in the browser. The URL pointing to the SOAP service is also
a HTTPS URL.
Does this mean that the server presents its certificate to the client which
has to trust it ? How does HttpClient know how to trust it without the
truststore ?
The following is unrelated to my original question but this is what I
observe.
When I generate JAX-WS classes I need to import the WSDL URL certificate
into my trust store and set the system properly.
Thanks,
Mohan
On 5 November 2017 at 22:38, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sun, 2017-11-05 at 08:41 +0530, Mohan Radhakrishnan wrote:
> > I do have a trustore into which I have imported the server
> > certificate. I
> > set a system property and use it.
> >
> > System.setProperty("javax.net.ssl.trustStrore", "trustStore");
> >
> > JSSE should be able to use it. I think. RIght ? Don't see a problem
> > at this
> > time. Just getting some clarifications.
> >
>
> HttpClient does not take system properties into account by default. You
> need to explicitly instruct to do so when building HttpClient
> instances.
>
> Oleg
>
>
> > Thanks,
> > Mohan
> >
> > On 5 November 2017 at 03:28, Bindul Bhowmik <bi...@gmail.com>
> > wrote:
> >
> > > Mohan,
> > >
> > > On Sat, Nov 4, 2017 at 6:01 AM, Mohan Radhakrishnan
> > > <ra...@gmail.com> wrote:
> > > > Hi,
> > > >
> > > >
> > >
> > > Let me start by mentioning that Http Client does not implement its
> > > own
> > > cyrpto algorithms or SSL/TLS protocols. It relies on the underlying
> > > Java JSSE implementation to create secure sockets. And unless you
> > > have
> > > plugged in an alternate JSSE provider, you are using the JSSE
> > > implementation packaged with your JRE. Having said that, Http
> > > Client
> > > does allow some customization to the secure socket creation process
> > > using SSLConnectionSocketFactory [1]. This allows you to use an
> > > alternate trust store, host name verifier, etc.. The latter being
> > > especially valuable during development/testing, but should not be
> > > used
> > > in production IMO. To see how you can customize the SSL socket
> > > creation, please read the 'Connection management' chapter in the
> > > Http
> > > Client tutorial [2].
> > >
> > > > I am invoking a HTTPS SOAP service and this is what I
> > > > think is
> > > > happening. It is one-way SSL. The JSSE implementation
> > > > automagically adds
> > >
> > > it
> > > > to the client's truststore and ensures that the SOAP call is
> > > > successful.
> > >
> > > I am not sure that is accurate. If the server you are targeting
> > > uses a
> > > certificate signed by one of the trusted CAs (or a CA signed by a
> > > trusted CA) in your trust store, the secure socket will be
> > > established. The client does not alter the trust store
> > > automagically,
> > > unless you have done it yourself, or are using a custom trust store
> > > (other than say the cacerts that ships with Oracle JRE).
> > >
> > > >
> > > > This question is based on this assumption.
> > > > When I read
> > > > https://www.ssl.com/guide/ssl-best-practices-a-quick-and-dirty-gu
> > > > ide/
> > >
> > > there
> > > > are various SSL exceptions and checks that
> > > > are required. I code the client. How do I trap the various
> > > > exceptions ?
> > > > Which list of exceptions should I use for SSL ?
> > >
> > > I am not sure I understand the question, but if you need to catch
> > > all
> > > exceptions, see the JSSE Reference Guide [3] on exceptions that can
> > > come from the SSL context. I guess the most important one will be
> > > javax.net.ssl.SSLException and its sub-classes. As far as I can
> > > tell,
> > > HC adds org.apache.http.conn.ssl.SSLInitializationException and of
> > > course most connect methods can throw IOException.
> > >
> > >
> > > >
> > > > How do I know the the HttpClient uses the latest security patches
> > > > in my
> > >
> > > JDK
> > > > 8 ? It should automatically be secure. Right ?
> > >
> > > As I noted above, HC is using the configured or default JSSE
> > > implementation in your JRE. If that is patched, you will be as
> > > secure
> > > as that.
> > >
> > > >
> > > > Thanks,
> > > > Mohan
> > >
> > > Regards,
> > > Bindul
> > >
> > > [1] https://hc.apache.org/httpcomponents-client-ga/
> > > httpclient/apidocs/org/apache/http/conn/ssl/SSLConnectionSocketFact
> > > ory.
> > > html
> > > [2] http://hc.apache.org/httpcomponents-client-ga/tutorial/html/
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.or
> > > g
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: SSL Certificate exceptions and defensive coding
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2017-11-05 at 08:41 +0530, Mohan Radhakrishnan wrote:
> I do have a trustore into which I have imported the server
> certificate. I
> set a system property and use it.
>
> System.setProperty("javax.net.ssl.trustStrore", "trustStore");
>
> JSSE should be able to use it. I think. RIght ? Don't see a problem
> at this
> time. Just getting some clarifications.
>
HttpClient does not take system properties into account by default. You
need to explicitly instruct to do so when building HttpClient
instances.
Oleg
> Thanks,
> Mohan
>
> On 5 November 2017 at 03:28, Bindul Bhowmik <bi...@gmail.com>
> wrote:
>
> > Mohan,
> >
> > On Sat, Nov 4, 2017 at 6:01 AM, Mohan Radhakrishnan
> > <ra...@gmail.com> wrote:
> > > Hi,
> > >
> > >
> >
> > Let me start by mentioning that Http Client does not implement its
> > own
> > cyrpto algorithms or SSL/TLS protocols. It relies on the underlying
> > Java JSSE implementation to create secure sockets. And unless you
> > have
> > plugged in an alternate JSSE provider, you are using the JSSE
> > implementation packaged with your JRE. Having said that, Http
> > Client
> > does allow some customization to the secure socket creation process
> > using SSLConnectionSocketFactory [1]. This allows you to use an
> > alternate trust store, host name verifier, etc.. The latter being
> > especially valuable during development/testing, but should not be
> > used
> > in production IMO. To see how you can customize the SSL socket
> > creation, please read the 'Connection management' chapter in the
> > Http
> > Client tutorial [2].
> >
> > > I am invoking a HTTPS SOAP service and this is what I
> > > think is
> > > happening. It is one-way SSL. The JSSE implementation
> > > automagically adds
> >
> > it
> > > to the client's truststore and ensures that the SOAP call is
> > > successful.
> >
> > I am not sure that is accurate. If the server you are targeting
> > uses a
> > certificate signed by one of the trusted CAs (or a CA signed by a
> > trusted CA) in your trust store, the secure socket will be
> > established. The client does not alter the trust store
> > automagically,
> > unless you have done it yourself, or are using a custom trust store
> > (other than say the cacerts that ships with Oracle JRE).
> >
> > >
> > > This question is based on this assumption.
> > > When I read
> > > https://www.ssl.com/guide/ssl-best-practices-a-quick-and-dirty-gu
> > > ide/
> >
> > there
> > > are various SSL exceptions and checks that
> > > are required. I code the client. How do I trap the various
> > > exceptions ?
> > > Which list of exceptions should I use for SSL ?
> >
> > I am not sure I understand the question, but if you need to catch
> > all
> > exceptions, see the JSSE Reference Guide [3] on exceptions that can
> > come from the SSL context. I guess the most important one will be
> > javax.net.ssl.SSLException and its sub-classes. As far as I can
> > tell,
> > HC adds org.apache.http.conn.ssl.SSLInitializationException and of
> > course most connect methods can throw IOException.
> >
> >
> > >
> > > How do I know the the HttpClient uses the latest security patches
> > > in my
> >
> > JDK
> > > 8 ? It should automatically be secure. Right ?
> >
> > As I noted above, HC is using the configured or default JSSE
> > implementation in your JRE. If that is patched, you will be as
> > secure
> > as that.
> >
> > >
> > > Thanks,
> > > Mohan
> >
> > Regards,
> > Bindul
> >
> > [1] https://hc.apache.org/httpcomponents-client-ga/
> > httpclient/apidocs/org/apache/http/conn/ssl/SSLConnectionSocketFact
> > ory.
> > html
> > [2] http://hc.apache.org/httpcomponents-client-ga/tutorial/html/
> >
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.or
> > g
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: SSL Certificate exceptions and defensive coding
Posted by Mohan Radhakrishnan <ra...@gmail.com>.
I do have a trustore into which I have imported the server certificate. I
set a system property and use it.
System.setProperty("javax.net.ssl.trustStrore", "trustStore");
JSSE should be able to use it. I think. RIght ? Don't see a problem at this
time. Just getting some clarifications.
Thanks,
Mohan
On 5 November 2017 at 03:28, Bindul Bhowmik <bi...@gmail.com> wrote:
> Mohan,
>
> On Sat, Nov 4, 2017 at 6:01 AM, Mohan Radhakrishnan
> <ra...@gmail.com> wrote:
> > Hi,
> >
> >
>
> Let me start by mentioning that Http Client does not implement its own
> cyrpto algorithms or SSL/TLS protocols. It relies on the underlying
> Java JSSE implementation to create secure sockets. And unless you have
> plugged in an alternate JSSE provider, you are using the JSSE
> implementation packaged with your JRE. Having said that, Http Client
> does allow some customization to the secure socket creation process
> using SSLConnectionSocketFactory [1]. This allows you to use an
> alternate trust store, host name verifier, etc.. The latter being
> especially valuable during development/testing, but should not be used
> in production IMO. To see how you can customize the SSL socket
> creation, please read the 'Connection management' chapter in the Http
> Client tutorial [2].
>
> > I am invoking a HTTPS SOAP service and this is what I think is
> > happening. It is one-way SSL. The JSSE implementation automagically adds
> it
> > to the client's truststore and ensures that the SOAP call is successful.
>
> I am not sure that is accurate. If the server you are targeting uses a
> certificate signed by one of the trusted CAs (or a CA signed by a
> trusted CA) in your trust store, the secure socket will be
> established. The client does not alter the trust store automagically,
> unless you have done it yourself, or are using a custom trust store
> (other than say the cacerts that ships with Oracle JRE).
>
> >
> > This question is based on this assumption.
> > When I read
> > https://www.ssl.com/guide/ssl-best-practices-a-quick-and-dirty-guide/
> there
> > are various SSL exceptions and checks that
> > are required. I code the client. How do I trap the various exceptions ?
> > Which list of exceptions should I use for SSL ?
>
> I am not sure I understand the question, but if you need to catch all
> exceptions, see the JSSE Reference Guide [3] on exceptions that can
> come from the SSL context. I guess the most important one will be
> javax.net.ssl.SSLException and its sub-classes. As far as I can tell,
> HC adds org.apache.http.conn.ssl.SSLInitializationException and of
> course most connect methods can throw IOException.
>
>
> >
> > How do I know the the HttpClient uses the latest security patches in my
> JDK
> > 8 ? It should automatically be secure. Right ?
>
> As I noted above, HC is using the configured or default JSSE
> implementation in your JRE. If that is patched, you will be as secure
> as that.
>
> >
> > Thanks,
> > Mohan
>
> Regards,
> Bindul
>
> [1] https://hc.apache.org/httpcomponents-client-ga/
> httpclient/apidocs/org/apache/http/conn/ssl/SSLConnectionSocketFactory.
> html
> [2] http://hc.apache.org/httpcomponents-client-ga/tutorial/html/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: SSL Certificate exceptions and defensive coding
Posted by Bindul Bhowmik <bi...@gmail.com>.
Mohan,
On Sat, Nov 4, 2017 at 6:01 AM, Mohan Radhakrishnan
<ra...@gmail.com> wrote:
> Hi,
>
>
Let me start by mentioning that Http Client does not implement its own
cyrpto algorithms or SSL/TLS protocols. It relies on the underlying
Java JSSE implementation to create secure sockets. And unless you have
plugged in an alternate JSSE provider, you are using the JSSE
implementation packaged with your JRE. Having said that, Http Client
does allow some customization to the secure socket creation process
using SSLConnectionSocketFactory [1]. This allows you to use an
alternate trust store, host name verifier, etc.. The latter being
especially valuable during development/testing, but should not be used
in production IMO. To see how you can customize the SSL socket
creation, please read the 'Connection management' chapter in the Http
Client tutorial [2].
> I am invoking a HTTPS SOAP service and this is what I think is
> happening. It is one-way SSL. The JSSE implementation automagically adds it
> to the client's truststore and ensures that the SOAP call is successful.
I am not sure that is accurate. If the server you are targeting uses a
certificate signed by one of the trusted CAs (or a CA signed by a
trusted CA) in your trust store, the secure socket will be
established. The client does not alter the trust store automagically,
unless you have done it yourself, or are using a custom trust store
(other than say the cacerts that ships with Oracle JRE).
>
> This question is based on this assumption.
> When I read
> https://www.ssl.com/guide/ssl-best-practices-a-quick-and-dirty-guide/ there
> are various SSL exceptions and checks that
> are required. I code the client. How do I trap the various exceptions ?
> Which list of exceptions should I use for SSL ?
I am not sure I understand the question, but if you need to catch all
exceptions, see the JSSE Reference Guide [3] on exceptions that can
come from the SSL context. I guess the most important one will be
javax.net.ssl.SSLException and its sub-classes. As far as I can tell,
HC adds org.apache.http.conn.ssl.SSLInitializationException and of
course most connect methods can throw IOException.
>
> How do I know the the HttpClient uses the latest security patches in my JDK
> 8 ? It should automatically be secure. Right ?
As I noted above, HC is using the configured or default JSSE
implementation in your JRE. If that is patched, you will be as secure
as that.
>
> Thanks,
> Mohan
Regards,
Bindul
[1] https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/conn/ssl/SSLConnectionSocketFactory.html
[2] http://hc.apache.org/httpcomponents-client-ga/tutorial/html/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org