You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Jakub Scholz <ja...@scholz.cz> on 2015/08/19 18:15:15 UTC
Using Qpid Dispatch (with C++ broker)
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.
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?
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?
4) The DISPATCH-58 issue seems to be quite annoying - are there any plans
to fix it?
Thanks & Regards
JAkub
Re: Using Qpid Dispatch (with C++ broker)
Posted by Jakub Scholz <ja...@scholz.cz>.
Thanks for answering the questions. I didn't found any JIRA for enhancing
the prefix in link routing, so I entered DISPATCH-159
<https://issues.apache.org/jira/browse/DISPATCH-159>.
Regards
Jakub
On Tue, Aug 25, 2015 at 4:58 AM, Ted Ross <tr...@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
>
>
Re: Using Qpid Dispatch (with C++ broker)
Posted by Ken Giusti <kg...@redhat.com>.
Hi Jakub,
Not sure if this answers your Q, but IIRC - a proton server doesn't distinguish a self-signed CA from a CA signed by a "real" certificate authority. As far as a proton server is concerned, if it's in the CA database (pn_ssl_domain_set_trusted_ca_db()) any peer whose certificate is signed by those CA's (including the self-signed CA) are trusted.
I'm pretty sure that behavior is similar to qpidd's. If you take a look at qpid/cpp/src/tests/ssl_test, the peer authentication tests use a self-signed CA.
----- Original Message -----
> From: "Jakub Scholz" <ja...@scholz.cz>
> To: users@qpid.apache.org
> Sent: Friday, August 28, 2015 9:54:35 AM
> Subject: Re: Using Qpid Dispatch (with C++ broker)
>
> 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 <cl...@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 <tr...@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
> >
> >
>
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Using Qpid Dispatch (with C++ broker)
Posted by Jakub Scholz <ja...@scholz.cz>.
Ok, I have to correct my self ... with the extensions as critical it seems
to work as desired. I will have to think which approach would be better for
us. Either case, thanks a lot for your help.
Regards
Jakub
On Mon, Aug 31, 2015 at 4:26 PM, Jakub Scholz <ja...@scholz.cz> wrote:
>
> On Mon, Aug 31, 2015 at 4:22 PM, Cliff Jansen <cl...@gmail.com>
> wrote:
>
>> both the "basic constraint" and "extended k
>
>
> Ah, I don't think I set them both as critical - my mistake. I will try
> again :-).
>
Re: Using Qpid Dispatch (with C++ broker)
Posted by Jakub Scholz <ja...@scholz.cz>.
On Mon, Aug 31, 2015 at 4:22 PM, Cliff Jansen <cl...@gmail.com> wrote:
> both the "basic constraint" and "extended k
Ah, I don't think I set them both as critical - my mistake. I will try
again :-).
Re: Using Qpid Dispatch (with C++ broker)
Posted by Cliff Jansen <cl...@gmail.com>.
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 <ja...@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 <ja...@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 <cl...@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 <ja...@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 <cl...@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 <tr...@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
Re: Using Qpid Dispatch (with C++ broker)
Posted by Jakub Scholz <ja...@scholz.cz>.
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 <ja...@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 <cl...@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 <ja...@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 <cl...@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 <tr...@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
>>
>>
>
Re: Using Qpid Dispatch (with C++ broker)
Posted by Jakub Scholz <ja...@scholz.cz>.
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 <cl...@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 <ja...@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 <cl...@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 <tr...@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
>
>
Re: Using Qpid Dispatch (with C++ broker)
Posted by Cliff Jansen <cl...@gmail.com>.
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 <ja...@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 <cl...@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 <tr...@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
Re: Using Qpid Dispatch (with C++ broker)
Posted by Jakub Scholz <ja...@scholz.cz>.
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 <cl...@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 <tr...@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
>
>
Re: Using Qpid Dispatch (with C++ broker)
Posted by Cliff Jansen <cl...@gmail.com>.
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 <tr...@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
Re: Using Qpid Dispatch (with C++ broker)
Posted by Ted Ross <tr...@redhat.com>.
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