qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Jansen <cliffjan...@gmail.com>
Subject Re: Using Qpid Dispatch (with C++ broker)
Date Mon, 31 Aug 2015 14:22:36 GMT
If you have set both the "basic constraint" and "extended key usage"
fields AND marked them both critical, then I believe you are being
limited by the RFC5280 section 6.2 murkiness exception for self-signed
certificates.

Cliff

On Mon, Aug 31, 2015 at 6:50 AM, Jakub Scholz <jakub@scholz.cz> wrote:
> BTW: I played with the CA:true / CA:false extensions and it doesn't seem
> that OpenSSL in Dispatch really cares about them.
>
> On Mon, Aug 31, 2015 at 9:32 AM, Jakub Scholz <jakub@scholz.cz> wrote:
>
>> Hi Cliff,
>>
>> Yes, you perfectly described how we use the NSS database in qpidd today.
>>
>> I was wondering whether the CA:false and CA:true can play a role. I will
>> test it to see.
>>
>> The idea of using the intermediate CAs to avoid the revocation list is
>> interesting, I didn't though about it before, but it sounds like an elegant
>> solution. The problem is that using custom CA and sign the certificates for
>> few hundred customers is often quite painful. On the other hand, the self
>> signed certificates also cause trouble here and there, so maybe it is
>> really time to get rid of them.
>>
>> Thanks & Regards
>> Jakub
>>
>> On Sun, Aug 30, 2015 at 9:13 PM, Cliff Jansen <cliffjansen@gmail.com>
>> wrote:
>>
>>> Hi Jacob,
>>>
>>> I believe you have been using the NSS trustargs to do special
>>> authentication configuration.  Something like assign "T" to a dummy
>>> cert and store client certificates in your list of CAs with an
>>> appropriate trustarg so that they could validate as a leaf certificate
>>> only and not as an intermediate CA (signing arbitrary credentials).
>>>
>>> Proton's trustedCerts can get you part way there, but I'm not
>>> convinced of the rest is possible.  NSS uses the trustargs attribute
>>> to augment or override attributes on the certificates themselves.  To
>>> the best of my knowledge OpenSSL and Java crypto only use the
>>> attributes contained in the actual certificate (Windows certificates
>>> can have limited different meaning depending on which store they live
>>> in).
>>>
>>> In theory, you can require the self-signed certs that you use to have
>>> the proper X509v3 extensions that correspond to the NSS trustargs you
>>> rely on, otherwise you reject them as malformed before you insert them
>>> in your CA database.  The extensions would presumably be:
>>>
>>>   Basic constraint: CA:false (critical)
>>>   Key usage: Digital signature/key encipherment (critical)
>>>   Extended key usage: TLS Web Client Auth (only, no signing)
>>>
>>> That may work as you intend for OpenSSL and Dispatch.
>>>
>>> However, I do not recommend this as your preferred approach.  The fly
>>> in the ointment is RFC5280 section 6.2 which essentially says: the
>>> rules in this RFC are deliberately murky when using self-signed certs
>>> as CA's... implementations can do what they want.
>>>
>>>
>>> As an alternative that works more within stricter rfc5280 rules,
>>> perhaps you could do something like:
>>>
>>>   You become the root certificate authority
>>>   Users send you a CSR
>>>   You create a unique intermediate CA for each user from the root
>>>   Use this CA to sign this one CSR using the constraints you like
>>>   Import each intermediate CA into your CA database but not the root
>>>
>>> Here a stolen user private key cannot be used to create fake
>>> credentials.  You can remove the intermediate CA at will to revoke the
>>> client certificate (without using the formal revocation list
>>> mechanism).  Predictable rfc5280 validation will occur on all
>>> platforms.  Disclaimer: I haven't actually tried this and I'm mostly
>>> guessing at your use case.  But I do worry that using self-signed
>>> certificates as you currently do will require reworking all your
>>> certificates each time you add a future component (Java broker,
>>> Windows thingamajig).
>>>
>>> Cliff
>>>
>>> On Fri, Aug 28, 2015 at 6:54 AM, Jakub Scholz <jakub@scholz.cz> wrote:
>>> > Thanks for the clarification regarding the certificate databases. As I
>>> see
>>> > it, the trustedCerts might be useful in case you don't use CAs but
>>> directly
>>> > the end user certificates. This is what I usually use with self-signed
>>> > certificates. In such case you don't wont to have them all listed during
>>> > the SSL handshake, because each certificate = user account. So one can
>>> use
>>> > the trustedCerts to override it. That is nice.
>>> >
>>> > However, that brings me to another question ... the C++ broker is using
>>> the
>>> > NSS library which distinguishes between trusted peer (only the trusted
>>> peer
>>> > it self can connect, certificates signed by the peer will be rejected)
>>> and
>>> > trusted CA (certificates signed by the trusted CA can connect). Do you
>>> have
>>> > by coincidence an idea how Proton / OpenSSL deals with this? There is no
>>> > trusted peer / CA flag in the certDb.
>>> >
>>> > Thanks & Regards
>>> > Jakub
>>> >
>>> > On Tue, Aug 25, 2015 at 8:19 PM, Cliff Jansen <cliffjansen@gmail.com>
>>> wrote:
>>> >
>>> >> The certDb (proton:
>>> >> pn_ssl_domain_t::pn_ssl_domain_trusted_certificate_db) is the
>>> >> database/collection/store of CA certificates which are used to
>>> >> validate the authenticity of the peer's certificate (client or
>>> >> server).  For self signed certificates, at least the public portion
of
>>> >> the certificate itself must be in the database (since it is its own
>>> >> CA).
>>> >>
>>> >> The trustedCerts (proton
>>> >> pn_ssl_domain_t::pn_ssl_domain_set_peer_authentication) is a
>>> >> server-only attribute specifying the list of CA's that will be
>>> >> included in the "client certificate request" portion of the first SSL
>>> >> handshake packet from the server to the client.  In theory, Proton
>>> >> could allow the application examine this list and provide its
>>> >> preferred client certificate for that server, but it currently
>>> >> requires a single certificate to be specified before socket creation,
>>> >> and it does not change during SSL negotiation.  Proton could also
>>> >> allow the server to change the list based on the client's IP address
>>> >> or other client hello context, but again the value is fixed before
>>> >> listener socket creation.
>>> >>
>>> >> I am not sure if there is a good use case to specify the two with
>>> >> different values for messaging applications requiring client
>>> >> certificates, but the ability is there for the static case.  They are
>>> >> separately (and dynamically between handshake stages) configurable in
>>> >> both OpenSSL and SChannel, so it is clear some SSL applications need
>>> >> the flexibility.
>>> >>
>>> >> On Mon, Aug 24, 2015 at 7:58 PM, Ted Ross <tross@redhat.com> wrote:
>>> >> >
>>> >> >
>>> >> > On 08/19/2015 11:15 AM, Jakub Scholz wrote:
>>> >> >>
>>> >> >> I spent some time playing with Qpid Dispatch (0.4) in combination
>>> with
>>> >> >> Qpid
>>> >> >> C++ broker. I was impressed about what it does already. Big
+1 to
>>> >> everyone
>>> >> >> involved.
>>> >> >>
>>> >> >> I still run into some issues / limitations / questions ...
maybe
>>> someone
>>> >> >> can help with them ...
>>> >> >>
>>> >> >> 1) Is there some technical reason why the linkRoutePattern
isn't
>>> allowed
>>> >> >> to
>>> >> >> contain any periods (well, apart the one at the end) and why
it has
>>> to
>>> >> end
>>> >> >> with a period? In my use case, almost every address name contains
>>> >> several
>>> >> >> periods in it and in many cases the important part in the address
is
>>> >> only
>>> >> >> after the last period. So it would be very useful to be able
to use
>>> >> >> multiple periods in the linkRoutePattern prefix and to be not
>>> required
>>> >> to
>>> >> >> end the prefix with a period.
>>> >> >
>>> >> >
>>> >> > There is no technical reason for this limitation.  It was done
for
>>> >> > expediency to prove the link-routing concept.  This should be
>>> expanded to
>>> >> > match any pattern.
>>> >> >
>>> >> >>
>>> >> >> 2) The Listener allows to configure the certDB and trustedCert
>>> >> parameters.
>>> >> >> I thought that one is for CAs and one is for self signed
>>> certificates.
>>> >> But
>>> >> >> it doesn't seem to be that easy. Can someone explain how are
they
>>> >> supposed
>>> >> >> to work?
>>> >> >
>>> >> >
>>> >> > This functionality comes straight from Proton.  It is my
>>> understanding
>>> >> that
>>> >> > certDB can be for CAs or self-signed certs.  The trustedCert
>>> parameter
>>> >> can
>>> >> > be used to constrain the set of certificates in the DB that are
>>> >> considered
>>> >> > trusted for this listener.
>>> >> >
>>> >> > Perhaps someone else can provide some more clarity.
>>> >> >
>>> >> >>
>>> >> >> 3) In the configuration file, what is the relation between
"router",
>>> >> >> "container", "listener" and "connector"? Is there some kind
of
>>> hierarchy
>>> >> >> between them? It almost seems that "router" and "container"
are
>>> entities
>>> >> >> which always apply to the whole Dispatch process and can be
used
>>> only
>>> >> >> once.
>>> >> >> Is that correct?
>>> >> >
>>> >> >
>>> >> > That is correct.  In fact, we plan to combine the configuration
in
>>> >> > "container" and "router" into a single section (probably router)
to
>>> >> reduce
>>> >> > the confusion.
>>> >> >
>>> >> >>
>>> >> >> 4) The DISPATCH-58 issue seems to be quite annoying - are there
any
>>> >> plans
>>> >> >> to fix it?
>>> >> >
>>> >> >
>>> >> > Yes, I'm planning a refactor of the ingress links that will improve
>>> the
>>> >> > ability to use flow control across the network.  This will likely
>>> improve
>>> >> > the DISPATCH-58 issue.
>>> >> >
>>> >> >>
>>> >> >> Thanks & Regards
>>> >> >> JAkub
>>> >> >>
>>> >> >
>>> >> > ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> > For additional commands, e-mail: users-help@qpid.apache.org
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> For additional commands, e-mail: users-help@qpid.apache.org
>>> >>
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message