activemq-cpp and ssl support

[Teemu Torma <te...@torma.org>]

I known ssl support is targeted for 2.2 release, but we have a need for 
one rather sooner.  I am wondering if there are yet development plans 
to see how to proceed.

We could implement something internal and trash it once activemq-cpp 
supports ssl natively, or develop something "real" and contribute it 
back.  

If latter, are there any thoughts about the design and the api to manage 
certificates, keys, verification and like?

Teemu

RE: activemq-cpp and ssl support

["Mittler, Nathan" <na...@sensis.com>]

Hey guys,
I've updated the ssl issue
(https://issues.apache.org/activemq/browse/AMQCPP-140) with some more
thoughts on how the ssl transport might be configured.  Let me know what
you think.

Regards,
Nate

Re: activemq-cpp and ssl support

[Nathan Mittler <na...@gmail.com>]

Sounds good to me!

On 10/16/07, Timothy Bish <ta...@twcny.rr.com> wrote:
>
> Hey, that was going to be my suggestion!  :)
>
> Hiram Chirino wrote:
> > To make it simpler perhaps you can put the ssl configuration in a file
> > and refer to that in the uri...
> >
> > cf->createConnection("ssl://localhost:12121?conf=./path/to/file.conf");
> >
> > On 10/16/07, Nathan Mittler <na...@gmail.com> wrote:
> >
> >>> I know the goal is to use apr for service abstraction.  It would be
> nice
> >>> if someone with more knowledge of it give a shot from configuration
> >>> point of view.  I think subversion has support to use either installed
> >>> or "embedded" version of it.
> >>>
> >>> We definitely have need to use apr in the build tree without
> installing
> >>> it first.
> >>>
> >> Unfortunately, none of us are experts at the "art" of managing external
> >> dependencies with autoconf :(.  We do, however, have a binary
> dependency on
> >> apr in our m4 files.  Perhaps we could change the way our build handles
> apr
> >> to be more like subversion?
> >>
> >> Regardless, for now I don't see anything wrong with just manually
> installing
> >> apr locally to get your build working with the apr trunk.  It will take
> a
> >> bit to get ssl right anyway and by the time it's there, they might have
> a
> >> release distro of apr that includes ssl.
> >>
> >>
> >>
> >>> From the user perspective, we want all of the SSL configuration
> >>>
> >>>> embedded in the connection uri (e.g.
> >>>> "ssl://localhost:12121?sslProperty1=yadda").
> >>>>
> >>> That came to my mind initially, technically the easiest thing to do.
> >>>
> >>> The client key and certificate might be different for each connection
> >>> and not directly related to connection itself.  The ugly bit is that
> >>> you would need to pass paths to local filenames in the uri and often,
> >>> in practice, construct them on fly.  Something else might be nicer,
> but
> >>> I don't know what.
> >>>
> >>> I don't have any strong feelings either way, just what seems
> right.  Any
> >>> good arguments?
> >>>
> >> Unfortunately, uri parameters are probably the only pure way to deal
> with
> >> provider-specific parameters.  Otherwise, the user will have to go
> behind
> >> the scenes and make direct calls to the underlying transport, which
> would
> >> get icky.  I'm not sure that passing file paths in the uri is such a
> bad
> >> thing.  The user can always construct the uri with variables.
> >>
> >> string uri = string("ssl://localhost:12121?sslClientCert=") +
> clientCert +
> >> "...";
> >>
> >> Alternatively, we might be able to add support for embedding
> environment
> >> variables in the uri string.
> >>
> >>
> cf->createConnection("ssl://localhost:12121?sslClientCert=${clientCert}...");
> >>
> >> That's a little out of scope for this effort, however :).  I would say
> go
> >> ahead and add everything as uri parameters and we can come up with
> fancy
> >> ways of helping users clean up the uri's later.
> >>
> >>
> >> Teemu
> >>
> >>
> >> Regards,
> >> Nate
> >>
> >>
> >
> >
> >
>
>

Re: activemq-cpp and ssl support

[Timothy Bish <ta...@twcny.rr.com>]

Hey, that was going to be my suggestion!  :)

Hiram Chirino wrote:
> To make it simpler perhaps you can put the ssl configuration in a file
> and refer to that in the uri...
>
> cf->createConnection("ssl://localhost:12121?conf=./path/to/file.conf");
>
> On 10/16/07, Nathan Mittler <na...@gmail.com> wrote:
>   
>>> I know the goal is to use apr for service abstraction.  It would be nice
>>> if someone with more knowledge of it give a shot from configuration
>>> point of view.  I think subversion has support to use either installed
>>> or "embedded" version of it.
>>>
>>> We definitely have need to use apr in the build tree without installing
>>> it first.
>>>       
>> Unfortunately, none of us are experts at the "art" of managing external
>> dependencies with autoconf :(.  We do, however, have a binary dependency on
>> apr in our m4 files.  Perhaps we could change the way our build handles apr
>> to be more like subversion?
>>
>> Regardless, for now I don't see anything wrong with just manually installing
>> apr locally to get your build working with the apr trunk.  It will take a
>> bit to get ssl right anyway and by the time it's there, they might have a
>> release distro of apr that includes ssl.
>>
>>
>>     
>>> From the user perspective, we want all of the SSL configuration
>>>       
>>>> embedded in the connection uri (e.g.
>>>> "ssl://localhost:12121?sslProperty1=yadda").
>>>>         
>>> That came to my mind initially, technically the easiest thing to do.
>>>
>>> The client key and certificate might be different for each connection
>>> and not directly related to connection itself.  The ugly bit is that
>>> you would need to pass paths to local filenames in the uri and often,
>>> in practice, construct them on fly.  Something else might be nicer, but
>>> I don't know what.
>>>
>>> I don't have any strong feelings either way, just what seems right.  Any
>>> good arguments?
>>>       
>> Unfortunately, uri parameters are probably the only pure way to deal with
>> provider-specific parameters.  Otherwise, the user will have to go behind
>> the scenes and make direct calls to the underlying transport, which would
>> get icky.  I'm not sure that passing file paths in the uri is such a bad
>> thing.  The user can always construct the uri with variables.
>>
>> string uri = string("ssl://localhost:12121?sslClientCert=") + clientCert +
>> "...";
>>
>> Alternatively, we might be able to add support for embedding environment
>> variables in the uri string.
>>
>> cf->createConnection("ssl://localhost:12121?sslClientCert=${clientCert}...");
>>
>> That's a little out of scope for this effort, however :).  I would say go
>> ahead and add everything as uri parameters and we can come up with fancy
>> ways of helping users clean up the uri's later.
>>
>>
>> Teemu
>>
>>
>> Regards,
>> Nate
>>
>>     
>
>
>   

Re: activemq-cpp and ssl support

[Hiram Chirino <hi...@hiramchirino.com>]

To make it simpler perhaps you can put the ssl configuration in a file
and refer to that in the uri...

cf->createConnection("ssl://localhost:12121?conf=./path/to/file.conf");

On 10/16/07, Nathan Mittler <na...@gmail.com> wrote:
> > I know the goal is to use apr for service abstraction.  It would be nice
> > if someone with more knowledge of it give a shot from configuration
> > point of view.  I think subversion has support to use either installed
> > or "embedded" version of it.
> >
> > We definitely have need to use apr in the build tree without installing
> > it first.
>
>
> Unfortunately, none of us are experts at the "art" of managing external
> dependencies with autoconf :(.  We do, however, have a binary dependency on
> apr in our m4 files.  Perhaps we could change the way our build handles apr
> to be more like subversion?
>
> Regardless, for now I don't see anything wrong with just manually installing
> apr locally to get your build working with the apr trunk.  It will take a
> bit to get ssl right anyway and by the time it's there, they might have a
> release distro of apr that includes ssl.
>
>
> > From the user perspective, we want all of the SSL configuration
> > > embedded in the connection uri (e.g.
> > > "ssl://localhost:12121?sslProperty1=yadda").
> >
> > That came to my mind initially, technically the easiest thing to do.
> >
> > The client key and certificate might be different for each connection
> > and not directly related to connection itself.  The ugly bit is that
> > you would need to pass paths to local filenames in the uri and often,
> > in practice, construct them on fly.  Something else might be nicer, but
> > I don't know what.
> >
> > I don't have any strong feelings either way, just what seems right.  Any
> > good arguments?
>
>
> Unfortunately, uri parameters are probably the only pure way to deal with
> provider-specific parameters.  Otherwise, the user will have to go behind
> the scenes and make direct calls to the underlying transport, which would
> get icky.  I'm not sure that passing file paths in the uri is such a bad
> thing.  The user can always construct the uri with variables.
>
> string uri = string("ssl://localhost:12121?sslClientCert=") + clientCert +
> "...";
>
> Alternatively, we might be able to add support for embedding environment
> variables in the uri string.
>
> cf->createConnection("ssl://localhost:12121?sslClientCert=${clientCert}...");
>
> That's a little out of scope for this effort, however :).  I would say go
> ahead and add everything as uri parameters and we can come up with fancy
> ways of helping users clean up the uri's later.
>
>
> Teemu
>
>
> Regards,
> Nate
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: activemq-cpp and ssl support

[Nathan Mittler <na...@gmail.com>]

> I know the goal is to use apr for service abstraction.  It would be nice
> if someone with more knowledge of it give a shot from configuration
> point of view.  I think subversion has support to use either installed
> or "embedded" version of it.
>
> We definitely have need to use apr in the build tree without installing
> it first.


Unfortunately, none of us are experts at the "art" of managing external
dependencies with autoconf :(.  We do, however, have a binary dependency on
apr in our m4 files.  Perhaps we could change the way our build handles apr
to be more like subversion?

Regardless, for now I don't see anything wrong with just manually installing
apr locally to get your build working with the apr trunk.  It will take a
bit to get ssl right anyway and by the time it's there, they might have a
release distro of apr that includes ssl.


> From the user perspective, we want all of the SSL configuration
> > embedded in the connection uri (e.g.
> > "ssl://localhost:12121?sslProperty1=yadda").
>
> That came to my mind initially, technically the easiest thing to do.
>
> The client key and certificate might be different for each connection
> and not directly related to connection itself.  The ugly bit is that
> you would need to pass paths to local filenames in the uri and often,
> in practice, construct them on fly.  Something else might be nicer, but
> I don't know what.
>
> I don't have any strong feelings either way, just what seems right.  Any
> good arguments?


Unfortunately, uri parameters are probably the only pure way to deal with
provider-specific parameters.  Otherwise, the user will have to go behind
the scenes and make direct calls to the underlying transport, which would
get icky.  I'm not sure that passing file paths in the uri is such a bad
thing.  The user can always construct the uri with variables.

string uri = string("ssl://localhost:12121?sslClientCert=") + clientCert +
"...";

Alternatively, we might be able to add support for embedding environment
variables in the uri string.

cf->createConnection("ssl://localhost:12121?sslClientCert=${clientCert}...");

That's a little out of scope for this effort, however :).  I would say go
ahead and add everything as uri parameters and we can come up with fancy
ways of helping users clean up the uri's later.


Teemu


Regards,
Nate

Re: activemq-cpp and ssl support

[Teemu Torma <te...@torma.org>]

On Tuesday 16 October 2007, Nathan Mittler wrote:
> We haven't begun work on it as of yet.  We've been putting it off
> because we were waiting for official ssl support in apr.  By the
> looks of things, ssl support is still only in their trunk.

I know the goal is to use apr for service abstraction.  It would be nice 
if someone with more knowledge of it give a shot from configuration 
point of view.  I think subversion has support to use either installed 
or "embedded" version of it.  

We definitely have need to use apr in the build tree without installing 
it first.

> From the user perspective, we want all of the SSL configuration
> embedded in the connection uri (e.g. 
> "ssl://localhost:12121?sslProperty1=yadda").

That came to my mind initially, technically the easiest thing to do.

The client key and certificate might be different for each connection 
and not directly related to connection itself.  The ugly bit is that 
you would need to pass paths to local filenames in the uri and often, 
in practice, construct them on fly.  Something else might be nicer, but 
I don't know what. 

I don't have any strong feelings either way, just what seems right.  Any 
good arguments?

Teemu

Re: activemq-cpp and ssl support

[Nathan Mittler <na...@gmail.com>]

Excellent - contributions are always welcome!  Here's the scoop on ssl ...

We haven't begun work on it as of yet.  We've been putting it off because we
were waiting for official ssl support in apr.  By the looks of things, ssl
support is still only in their trunk (
http://apr.apache.org/docs/apr-util/trunk/).  So if you'd like to take a
shot at it, I would start by working from the apr-trunk.  If apr still
doesn't have a release with ssl by the time we're ready, we can just make a
branch to hold the ssl code.

>From the user perspective, we want all of the SSL configuration embedded in
the connection uri (e.g. "ssl://localhost:12121?sslProperty1=yadda").  The
way I envisioned SSL fitting into the architecture was by making a SSLSocket
class, similar to the one in the JDK (
http://java.sun.com/j2se/1.5.0/docs/api/javax/net/ssl/SSLSocket.html).  We
have already defined a Socket interface, which is implemented by TcpSocket.
SSLSocket might extend TcpSocket or might simply be another socket
altogether.

We'll use the first bit of the connection uri (e.g. ssl://) to determine
which transport/socket to create.  I think we'll have to create a new
SSLTransportFactory class that registers itself for the protocol "ssl" (see
TcpTransportFactory).  Alternatively, you could register TcpTransportFactory
once for each "tcp" and "ssl".

When created, TcpTransport (
https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/main/activemq/transport/filters/TcpTransport.cpp)
passes in the transport URI parameter (now will be one of "tcp" or "ssl")
into SocketFactory (
https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/main/activemq/network/SocketFactory.cpp).
Some extra logic can be added to SocketFactory to decide whether to create a
TcpSocket or a new SSLSocket.

Once all of this is in place, the IOTransport (
https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/main/activemq/transport/IOTransport.cpp)
should work just as it would with a TcpSocket - no changes there.

That's all I can think of right now.  You can start by just digging around
through the classes I pointed out and get a feel for how everything fits
together.  If you have any questions, feel free to ask.

Thanks,
Nate


On 10/15/07, Teemu Torma <te...@torma.org> wrote:
>
> I known ssl support is targeted for 2.2 release, but we have a need for
> one rather sooner.  I am wondering if there are yet development plans
> to see how to proceed.
>
> We could implement something internal and trash it once activemq-cpp
> supports ssl natively, or develop something "real" and contribute it
> back.
>
> If latter, are there any thoughts about the design and the api to manage
> certificates, keys, verification and like?
>
> Teemu
>