hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: TrustSelfSignedStrategy implementation
Date Wed, 02 Mar 2016 15:18:44 GMT
On Wed, 2016-03-02 at 09:58 -0500, David Duchaine wrote:
> 2016-03-02 8:14 GMT-05:00 Oleg Kalnichevski <olegk@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 <olegk@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


Mime
View raw message