Ok, that works for relatively basic options, but what about the more
complex stuff I need to do? Specifically turning off weak ciphers on
the connection (via socket.setEnabledCipherSuites), and verifying the
server's DN. Also, I need to use different settings for setting up the
keystore and truststore (e.g. if one is in pkcs12 format and the other
is in jks format). Someone else on the user's mailing list asked a
similar question about customizing the ssl keystore.

If I add a SocketFactory param in the createTransport calls, it
requires lots of changes to support it across all the different
composite transports and such. Is there perhaps something similar to
the options that can have objects associated with a key for params to
the transports that will get passed along to all the sub transports so
the SSL one will get it?

Thanks,
Kelly

On 9/22/06, Sepand M <[EMAIL PROTECTED]> wrote:
Some of the more experienced people can correct me on this, but I think
you can set socket options using "socket._option_" arguments in the URI
(e.g. "ssl://localhost:61616?socket.my_option=true"). I'm not sure if
this would give all the flexibility you need, but it's a start. If that
doesn't work, for SSL specific stuff, I added a
SslActiveMQConnectionFactory (or a similar name).

Any good?
Sepand

Kelly Campbell wrote:
> Thanks Sepand. I did review those instructions earlier.
>
> What about the other requirements to be able to set specific options
> on the socket, e.g. not allowing weak ciphers? I think having the
> config in the URL is good, but not sufficient in this case. I'd like
> to propose adding a SocketFactory parameter to a new constructor on
> the ActiveMQConnectionFactory (actually the code for this is almost
> complete). This would be useful for not only SSL connections, but
> other tcp connections if the user wants to customize some of the
> socket options.
>
> Thanks,
> Kelly
>
> On 9/21/06, Sepand M <[EMAIL PROTECTED]> wrote:
>> Yeah, we realized this was needed, but I didn't have time (my work term
>> at the company was ending).
>> I've left instructions for people taking over this project on how to do
>> this (it just takes one setter and a well placed call from that setter).
>> I'm not sure when it will be done though.
>>
>> - Sepand
>>
>> Hiram Chirino wrote:
>> > On 9/21/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>> >> On 9/21/06, Kelly Campbell <[EMAIL PROTECTED]> wrote:
>> >> > Thanks for getting this submitted Sepand, and thanks for patching
>> >> it in Hiram.
>> >> >
>> >> > I'm looking at how best to configure the keystore settings more
>> >> > dynamically without using the default system properties or
>> anything in
>> >> > the URL. It looks like I'd need to be able to pass in a
>> >> > javax.net.ssl.SSLContext or SSLSocketFactory. I'd also like to
>> be able
>> >> > to pass these in so I can provide an implementation that does some
>> >> > extra security checks, e.g. checking that the server's DN is
>> what we
>> >> > expect, turning off weak ciphers.
>> >> >
>> >>
>> >> It would be nice if they were properties on the ssl transport server
>> >> so that you can configure them using the URI... like:
>> >>
>> >> ssl://localhost:61617?keystore=foo.ks&truststore=foo.ts
>> >>
>> >> > The part I'm struggling with now is where to create this API for
>> the
>> >> > client. Should it be a new constructor on
>> ActiveMQConnectionFactory,
>> >> > or should I add a new overridden
>> ActiveMQSecureConnectionFactory? Or
>> >> > should I just override it in my own code base, and not have this in
>> >> > the activemq code at all?
>> >>
>> >> Just add properties to the SslTransportServer and make sure they have
>> >> setters.
>> >>
>> >
>> > And properties to the SslTransport if you want to set those properties
>> > on the client connect URL
>> >
>> >> >
>> >> > Thanks,
>> >> > Kelly
>> >> >
>> >> > On 9/11/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>> >> > > starting to look into it now. thx for the patch!
>> >> > >
>> >> > > On 9/5/06, Sepand M <[EMAIL PROTECTED]> wrote:
>> >> > > > Hey guys,
>> >> > > >
>> >> > > > The patch is done.
>> >> > > > It's here: https://issues.apache.org/activemq/browse/AMQ-912
>> >> > > > Hope you like it.
>> >> > > > It would be really great if you could give an estimate of when
>> >> you will
>> >> > > > decide if it goes in or not (although I doubt you can =) ).
>> >> > > >
>> >> > > > Regards,
>> >> > > > Sepand
>> >> > > >
>> >> > > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Regards,
>> >> > > Hiram
>> >> > >
>> >> > > Blog: http://hiramchirino.com
>> >> > >
>> >> >
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Hiram
>> >>
>> >> Blog: http://hiramchirino.com
>> >>
>> >
>> >
>>
>>
>


Reply via email to