hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Duchaine <david.ducha...@gmail.com>
Subject Re: TrustSelfSignedStrategy implementation
Date Wed, 02 Mar 2016 16:46:58 GMT
2016-03-02 10:18 GMT-05:00 Oleg Kalnichevski <olegk@apache.org>:

> 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?
>
>
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message