You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by David Duchaine <da...@gmail.com> on 2016/03/01 17:51:34 UTC
TrustSelfSignedStrategy implementation
Hello,
just stumbled across a problem with the
org.apache.http.conn.ssl.TrustSelfSignedStrategy.isTrusted(
final X509Certificate[] chain, final String authType)
4.4.1 implementation
public boolean isTrusted(
final X509Certificate[] chain, final String authType) throws
CertificateException {
return chain.length == 1;
}
Problem was that my client code was communicating with a server which had a
CA signed certificate. The chain length was not equal 1 so isTrusted
returned false;
Even though the javadoc specifically says :
A trust strategy that accepts self-signed certificates as trusted.
Verification of all other
* certificates is done by the trust manager configured in the SSL context.
Most of the examples found on the Internet use TrustSelfSignedStrategy . I
think people use that one to trust any certificate, signed or not, even if
that would pose a security issue.
Do you think it might be appropriate to change the method isTrusted so that
it returns true in any case?
Perhaps it would be better, for convenience purpose, to add a new
implementation named, TrustAnyStrategy in the same way NoopHostnameVerifier
can be used to disable hostname verification.
Just a suggestion,
thanks for you all,
David
Re: TrustSelfSignedStrategy implementation
Posted by David Duchaine <da...@gmail.com>.
2016-03-02 10:18 GMT-05:00 Oleg Kalnichevski <ol...@apache.org>:
> On Wed, 2016-03-02 at 09:58 -0500, David Duchaine wrote:
> > 2016-03-02 8:14 GMT-05:00 Oleg Kalnichevski <ol...@apache.org>:
> >
> > > On Wed, 2016-03-02 at 08:02 -0500, David Duchaine wrote:
> > > > The point of making it trust certificates indiscriminately is that if
> > > you make your code trust a self-signed cert, which is considered not
> > > secure, why would’nt you want it to connect to a signed cert, which is
> > > probably not more or less secure….
> > > >
> > > > The thing is, I had a really hard time finding why my code wasn’t
> > > connecting to server B, which had a signed, chained certificate
> > > (chain.length = 3). However , it was possible to connect to server A
> which
> > > was also signed, but without presenting a chained cert (chain.length
> == 1)
> > > >
> > >
> > > > A self-signed cert is the one that has only itself in its trust
> chain.
> > >
> >
> > After some research, I think this is correct. But it is possible to
> have a
> > chain.length == 1 for a certificate that is signed by a CA. When this is
> > the case, the certificate issuer Subject is not the same as the
> certificate
> > CN subject. If my understanding is correct, TrustSelfSignedStrategy
> should,
> > after checking chain.length == 1, also check that both Subject and
> Issuer
> > fields are identical. Something like:
> >
> > @Override
> > public boolean isTrusted(
> > final X509Certificate[] chain, final String authType) throws
> > CertificateException {
> > return ( chain.length == 1 &&
> >
> chain[0].getIssuerX500Principal().equals(chain[0].getSubjectX500Principal()))
> > }
> >
>
> > I cannot claim to be a PKI specialist but cannot see how anything signed
> > by another cert could possibly have a cert chain with one cert only.
>
> > Do you think you could generate such a cert with openssl and post it
> > here?
>
>
First, I will try to understand why the chain length received by the
isTrusted method is different from server A (CA signed, length == 1) and
server B (signed by same CA as A, length == 3)
According to RFC5280, at the end of section4.1.2.4
<https://tools.ietf.org/html/rfc5280#section-4.1.2.4>. Issuer
...
Certificate users MUST be prepared to process the issuer
distinguished name and subject distinguished name (Section 4.1.2.6
<https://tools.ietf.org/html/rfc5280#section-4.1.2.6>)
fields to perform name chaining for certification path validation
(Section 6 <https://tools.ietf.org/html/rfc5280#section-6>). Name
chaining is performed by matching the issuer
distinguished name in one certificate with the subject name in a CA
certificate. Rules for comparing distinguished names are specified
in Section 7.1 <https://tools.ietf.org/html/rfc5280#section-7.1>.
*If the names in the issuer and subject field in a
certificate match according to the rules specified in Section 7.1
<https://tools.ietf.org/html/rfc5280#section-7.1>,
then the certificate is self-issued.*
I will keep you informed of my findings.
David
> >
> > >
> > > > Perhaps it would be clearer for users if the API had a
> > > TrustAllCertsStrategy, just like a NoopHostnameVerifier
> > > >
> > >
> > > You are welcome to contribute one for 5.0
> > >
> > > Oleg
> > >
> > > >
> > > > David
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > Le 2 mars 2016 à 07:34, Oleg Kalnichevski <ol...@apache.org> a
> écrit :
> > > > >
> > > > > On Tue, 2016-03-01 at 11:51 -0500, David Duchaine wrote:
> > > > >> Hello,
> > > > >>
> > > > >> just stumbled across a problem with the
> > > > >>
> > > > >> org.apache.http.conn.ssl.TrustSelfSignedStrategy.isTrusted(
> > > > >> final X509Certificate[] chain, final String authType)
> > > > >>
> > > > >> 4.4.1 implementation
> > > > >>
> > > > >> public boolean isTrusted(
> > > > >> final X509Certificate[] chain, final String authType)
> > > throws
> > > > >> CertificateException {
> > > > >> return chain.length == 1;
> > > > >> }
> > > > >>
> > > > >>
> > > > >> Problem was that my client code was communicating with a server
> which
> > > had a
> > > > >> CA signed certificate. The chain length was not equal 1 so
> isTrusted
> > > > >> returned false;
> > > > >>
> > > > >>
> > > > >> Even though the javadoc specifically says :
> > > > >>
> > > > >> A trust strategy that accepts self-signed certificates as trusted.
> > > > >> Verification of all other
> > > > >> * certificates is done by the trust manager configured in the SSL
> > > context.
> > > > >>
> > > > >> Most of the examples found on the Internet use
> > > TrustSelfSignedStrategy . I
> > > > >> think people use that one to trust any certificate, signed or not,
> > > even if
> > > > >> that would pose a security issue.
> > > > >>
> > > > >>
> > > > >> Do you think it might be appropriate to change the method
> isTrusted
> > > so that
> > > > >> it returns true in any case?
> > > > >>
> > > > >
> > > > > TrustSelfSignedStrategy does exactly what its name implies: it
> treats
> > > > > self-signed (no CA) certs, but requires all certs issued by a CA
> to be
> > > > > verified as trusted.
> > > > >
> > > > > What would be the point in making it trust certificates
> > > > > indiscriminately?
> > > > >
> > > > > Oleg
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org <mailto:
> > > dev-unsubscribe@hc.apache.org>
> > > > > For additional commands, e-mail: dev-help@hc.apache.org <mailto:
> > > dev-help@hc.apache.org>
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: TrustSelfSignedStrategy implementation
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2016-03-02 at 09:58 -0500, David Duchaine wrote:
> 2016-03-02 8:14 GMT-05:00 Oleg Kalnichevski <ol...@apache.org>:
>
> > On Wed, 2016-03-02 at 08:02 -0500, David Duchaine wrote:
> > > The point of making it trust certificates indiscriminately is that if
> > you make your code trust a self-signed cert, which is considered not
> > secure, why would’nt you want it to connect to a signed cert, which is
> > probably not more or less secure….
> > >
> > > The thing is, I had a really hard time finding why my code wasn’t
> > connecting to server B, which had a signed, chained certificate
> > (chain.length = 3). However , it was possible to connect to server A which
> > was also signed, but without presenting a chained cert (chain.length == 1)
> > >
> >
> > > A self-signed cert is the one that has only itself in its trust chain.
> >
>
> After some research, I think this is correct. But it is possible to have a
> chain.length == 1 for a certificate that is signed by a CA. When this is
> the case, the certificate issuer Subject is not the same as the certificate
> CN subject. If my understanding is correct, TrustSelfSignedStrategy should,
> after checking chain.length == 1, also check that both Subject and Issuer
> fields are identical. Something like:
>
> @Override
> public boolean isTrusted(
> final X509Certificate[] chain, final String authType) throws
> CertificateException {
> return ( chain.length == 1 &&
> chain[0].getIssuerX500Principal().equals(chain[0].getSubjectX500Principal()))
> }
>
I cannot claim to be a PKI specialist but cannot see how anything signed
by another cert could possibly have a cert chain with one cert only.
Do you think you could generate such a cert with openssl and post it
here?
Oleg
>
> >
> > > Perhaps it would be clearer for users if the API had a
> > TrustAllCertsStrategy, just like a NoopHostnameVerifier
> > >
> >
> > You are welcome to contribute one for 5.0
> >
> > Oleg
> >
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > > > Le 2 mars 2016 à 07:34, Oleg Kalnichevski <ol...@apache.org> a écrit :
> > > >
> > > > On Tue, 2016-03-01 at 11:51 -0500, David Duchaine wrote:
> > > >> Hello,
> > > >>
> > > >> just stumbled across a problem with the
> > > >>
> > > >> org.apache.http.conn.ssl.TrustSelfSignedStrategy.isTrusted(
> > > >> final X509Certificate[] chain, final String authType)
> > > >>
> > > >> 4.4.1 implementation
> > > >>
> > > >> public boolean isTrusted(
> > > >> final X509Certificate[] chain, final String authType)
> > throws
> > > >> CertificateException {
> > > >> return chain.length == 1;
> > > >> }
> > > >>
> > > >>
> > > >> Problem was that my client code was communicating with a server which
> > had a
> > > >> CA signed certificate. The chain length was not equal 1 so isTrusted
> > > >> returned false;
> > > >>
> > > >>
> > > >> Even though the javadoc specifically says :
> > > >>
> > > >> A trust strategy that accepts self-signed certificates as trusted.
> > > >> Verification of all other
> > > >> * certificates is done by the trust manager configured in the SSL
> > context.
> > > >>
> > > >> Most of the examples found on the Internet use
> > TrustSelfSignedStrategy . I
> > > >> think people use that one to trust any certificate, signed or not,
> > even if
> > > >> that would pose a security issue.
> > > >>
> > > >>
> > > >> Do you think it might be appropriate to change the method isTrusted
> > so that
> > > >> it returns true in any case?
> > > >>
> > > >
> > > > TrustSelfSignedStrategy does exactly what its name implies: it treats
> > > > self-signed (no CA) certs, but requires all certs issued by a CA to be
> > > > verified as trusted.
> > > >
> > > > What would be the point in making it trust certificates
> > > > indiscriminately?
> > > >
> > > > Oleg
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org <mailto:
> > dev-unsubscribe@hc.apache.org>
> > > > For additional commands, e-mail: dev-help@hc.apache.org <mailto:
> > dev-help@hc.apache.org>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: TrustSelfSignedStrategy implementation
Posted by David Duchaine <da...@gmail.com>.
2016-03-02 8:14 GMT-05:00 Oleg Kalnichevski <ol...@apache.org>:
> On Wed, 2016-03-02 at 08:02 -0500, David Duchaine wrote:
> > The point of making it trust certificates indiscriminately is that if
> you make your code trust a self-signed cert, which is considered not
> secure, why would’nt you want it to connect to a signed cert, which is
> probably not more or less secure….
> >
> > The thing is, I had a really hard time finding why my code wasn’t
> connecting to server B, which had a signed, chained certificate
> (chain.length = 3). However , it was possible to connect to server A which
> was also signed, but without presenting a chained cert (chain.length == 1)
> >
>
> > A self-signed cert is the one that has only itself in its trust chain.
>
After some research, I think this is correct. But it is possible to have a
chain.length == 1 for a certificate that is signed by a CA. When this is
the case, the certificate issuer Subject is not the same as the certificate
CN subject. If my understanding is correct, TrustSelfSignedStrategy should,
after checking chain.length == 1, also check that both Subject and Issuer
fields are identical. Something like:
@Override
public boolean isTrusted(
final X509Certificate[] chain, final String authType) throws
CertificateException {
return ( chain.length == 1 &&
chain[0].getIssuerX500Principal().equals(chain[0].getSubjectX500Principal()))
}
>
> > Perhaps it would be clearer for users if the API had a
> TrustAllCertsStrategy, just like a NoopHostnameVerifier
> >
>
> You are welcome to contribute one for 5.0
>
> Oleg
>
> >
> > David
> >
> >
> >
> >
> >
> > > Le 2 mars 2016 à 07:34, Oleg Kalnichevski <ol...@apache.org> a écrit :
> > >
> > > On Tue, 2016-03-01 at 11:51 -0500, David Duchaine wrote:
> > >> Hello,
> > >>
> > >> just stumbled across a problem with the
> > >>
> > >> org.apache.http.conn.ssl.TrustSelfSignedStrategy.isTrusted(
> > >> final X509Certificate[] chain, final String authType)
> > >>
> > >> 4.4.1 implementation
> > >>
> > >> public boolean isTrusted(
> > >> final X509Certificate[] chain, final String authType)
> throws
> > >> CertificateException {
> > >> return chain.length == 1;
> > >> }
> > >>
> > >>
> > >> Problem was that my client code was communicating with a server which
> had a
> > >> CA signed certificate. The chain length was not equal 1 so isTrusted
> > >> returned false;
> > >>
> > >>
> > >> Even though the javadoc specifically says :
> > >>
> > >> A trust strategy that accepts self-signed certificates as trusted.
> > >> Verification of all other
> > >> * certificates is done by the trust manager configured in the SSL
> context.
> > >>
> > >> Most of the examples found on the Internet use
> TrustSelfSignedStrategy . I
> > >> think people use that one to trust any certificate, signed or not,
> even if
> > >> that would pose a security issue.
> > >>
> > >>
> > >> Do you think it might be appropriate to change the method isTrusted
> so that
> > >> it returns true in any case?
> > >>
> > >
> > > TrustSelfSignedStrategy does exactly what its name implies: it treats
> > > self-signed (no CA) certs, but requires all certs issued by a CA to be
> > > verified as trusted.
> > >
> > > What would be the point in making it trust certificates
> > > indiscriminately?
> > >
> > > Oleg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org <mailto:
> dev-unsubscribe@hc.apache.org>
> > > For additional commands, e-mail: dev-help@hc.apache.org <mailto:
> dev-help@hc.apache.org>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: TrustSelfSignedStrategy implementation
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2016-03-02 at 08:02 -0500, David Duchaine wrote:
> The point of making it trust certificates indiscriminately is that if you make your code trust a self-signed cert, which is considered not secure, why would’nt you want it to connect to a signed cert, which is probably not more or less secure….
>
> The thing is, I had a really hard time finding why my code wasn’t connecting to server B, which had a signed, chained certificate (chain.length = 3). However , it was possible to connect to server A which was also signed, but without presenting a chained cert (chain.length == 1)
>
A self-signed cert is the one that has only itself in its trust chain.
> Perhaps it would be clearer for users if the API had a TrustAllCertsStrategy, just like a NoopHostnameVerifier
>
You are welcome to contribute one for 5.0
Oleg
>
> David
>
>
>
>
>
> > Le 2 mars 2016 à 07:34, Oleg Kalnichevski <ol...@apache.org> a écrit :
> >
> > On Tue, 2016-03-01 at 11:51 -0500, David Duchaine wrote:
> >> Hello,
> >>
> >> just stumbled across a problem with the
> >>
> >> org.apache.http.conn.ssl.TrustSelfSignedStrategy.isTrusted(
> >> final X509Certificate[] chain, final String authType)
> >>
> >> 4.4.1 implementation
> >>
> >> public boolean isTrusted(
> >> final X509Certificate[] chain, final String authType) throws
> >> CertificateException {
> >> return chain.length == 1;
> >> }
> >>
> >>
> >> Problem was that my client code was communicating with a server which had a
> >> CA signed certificate. The chain length was not equal 1 so isTrusted
> >> returned false;
> >>
> >>
> >> Even though the javadoc specifically says :
> >>
> >> A trust strategy that accepts self-signed certificates as trusted.
> >> Verification of all other
> >> * certificates is done by the trust manager configured in the SSL context.
> >>
> >> Most of the examples found on the Internet use TrustSelfSignedStrategy . I
> >> think people use that one to trust any certificate, signed or not, even if
> >> that would pose a security issue.
> >>
> >>
> >> Do you think it might be appropriate to change the method isTrusted so that
> >> it returns true in any case?
> >>
> >
> > TrustSelfSignedStrategy does exactly what its name implies: it treats
> > self-signed (no CA) certs, but requires all certs issued by a CA to be
> > verified as trusted.
> >
> > What would be the point in making it trust certificates
> > indiscriminately?
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org <ma...@hc.apache.org>
> > For additional commands, e-mail: dev-help@hc.apache.org <ma...@hc.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: TrustSelfSignedStrategy implementation
Posted by David Duchaine <da...@gmail.com>.
The point of making it trust certificates indiscriminately is that if you make your code trust a self-signed cert, which is considered not secure, why would’nt you want it to connect to a signed cert, which is probably not more or less secure….
The thing is, I had a really hard time finding why my code wasn’t connecting to server B, which had a signed, chained certificate (chain.length = 3). However , it was possible to connect to server A which was also signed, but without presenting a chained cert (chain.length == 1)
Perhaps it would be clearer for users if the API had a TrustAllCertsStrategy, just like a NoopHostnameVerifier
David
> Le 2 mars 2016 à 07:34, Oleg Kalnichevski <ol...@apache.org> a écrit :
>
> On Tue, 2016-03-01 at 11:51 -0500, David Duchaine wrote:
>> Hello,
>>
>> just stumbled across a problem with the
>>
>> org.apache.http.conn.ssl.TrustSelfSignedStrategy.isTrusted(
>> final X509Certificate[] chain, final String authType)
>>
>> 4.4.1 implementation
>>
>> public boolean isTrusted(
>> final X509Certificate[] chain, final String authType) throws
>> CertificateException {
>> return chain.length == 1;
>> }
>>
>>
>> Problem was that my client code was communicating with a server which had a
>> CA signed certificate. The chain length was not equal 1 so isTrusted
>> returned false;
>>
>>
>> Even though the javadoc specifically says :
>>
>> A trust strategy that accepts self-signed certificates as trusted.
>> Verification of all other
>> * certificates is done by the trust manager configured in the SSL context.
>>
>> Most of the examples found on the Internet use TrustSelfSignedStrategy . I
>> think people use that one to trust any certificate, signed or not, even if
>> that would pose a security issue.
>>
>>
>> Do you think it might be appropriate to change the method isTrusted so that
>> it returns true in any case?
>>
>
> TrustSelfSignedStrategy does exactly what its name implies: it treats
> self-signed (no CA) certs, but requires all certs issued by a CA to be
> verified as trusted.
>
> What would be the point in making it trust certificates
> indiscriminately?
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org <ma...@hc.apache.org>
> For additional commands, e-mail: dev-help@hc.apache.org <ma...@hc.apache.org>
Re: TrustSelfSignedStrategy implementation
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2016-03-01 at 11:51 -0500, David Duchaine wrote:
> Hello,
>
> just stumbled across a problem with the
>
> org.apache.http.conn.ssl.TrustSelfSignedStrategy.isTrusted(
> final X509Certificate[] chain, final String authType)
>
> 4.4.1 implementation
>
> public boolean isTrusted(
> final X509Certificate[] chain, final String authType) throws
> CertificateException {
> return chain.length == 1;
> }
>
>
> Problem was that my client code was communicating with a server which had a
> CA signed certificate. The chain length was not equal 1 so isTrusted
> returned false;
>
>
> Even though the javadoc specifically says :
>
> A trust strategy that accepts self-signed certificates as trusted.
> Verification of all other
> * certificates is done by the trust manager configured in the SSL context.
>
> Most of the examples found on the Internet use TrustSelfSignedStrategy . I
> think people use that one to trust any certificate, signed or not, even if
> that would pose a security issue.
>
>
> Do you think it might be appropriate to change the method isTrusted so that
> it returns true in any case?
>
TrustSelfSignedStrategy does exactly what its name implies: it treats
self-signed (no CA) certs, but requires all certs issued by a CA to be
verified as trusted.
What would be the point in making it trust certificates
indiscriminately?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org