qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: Using Qpid Dispatch (with C++ broker)
Date Mon, 31 Aug 2015 13:50:34 GMT
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
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message