I have uploaded my work to googlecode. Its pretty rough right now, but its probably a good jump off point for anyone who is trying to add encryption to UDP.
Anyone with MINA experience, if you have recommendations on how I can do things better, please let me hear them. Also, anyone with a crypto background, I would love to hear if I have done things wrong (or right)! You can find it at: http://code.google.com/p/udpcryptfilter/ It is based on MINA 2.0.2, but it should easily be retrofitted to MINA 1.1.7 (probably just renaming IoBuffer) On Fri, May 27, 2011 at 8:11 PM, Shaun Senecal <[email protected]> wrote: > Ya, I thought about doing that, but I wanted this to be a "general purpose" > filter, which means I needed a solution that didnt require modifications to > any downstream filters. > > > On Fri, May 27, 2011 at 8:06 PM, Abhijit Bhatode < > [email protected]> wrote: > >> I was facing a simiilar issue: My application required processing >> handshake messages that should not be passed to ProtocolEncoder/Decoder. I >> maintained the state in IoSession and accordingly inferred whether to encode >> or decode the message. >> ________________________________________ >> From: Shaun Senecal [[email protected]] >> Sent: Friday, May 27, 2011 4:24 PM >> To: [email protected] >> Subject: Re: skipping certain filters in a chain to allow handling UDP >> encryption handshake messages >> >> I take it back. Hopefully I didnt waste anyone's time with this. >> >> The solution seems to have been that I needed to swap my 2 DTLS filters >> and >> then when I am writing "handshake" messages, I dont write them to the >> IoSession directly, but instead I write them to the DTLS Codec filter >> directly. >> >> The chain now looks like: >> DTLS Protocol Codec ---> DTLSFilter ---> TextLineCodec --> Logger >> >> and DTLSFilter hangs on to a reference to DTLS Protocol Codec so it can >> send >> the Handshake messages without worrying about the other filters messing >> with >> it. >> >> If I am able to get this solution working in a reasonable manner, I will >> post it somewhere (and reply to this thread with its location) so that >> others might be able to use this UDP encryption thingy. I just have it >> passing simple encrypted strings right now though (thus the >> TextLineCodec), >> so dont hold you breath that it will be anytime soon :) >> >> >> >> On Fri, May 27, 2011 at 5:52 PM, Shaun Senecal <[email protected]> >> wrote: >> >> > I'm using MINA 2.0.2 to implement a filter which adds encryption to UDP >> > messages (basically a mini-DTLS). The problem I'm having is that I was >> > hoping to be able to simply place a ProtocolCodecFilter on the filter >> chain >> > to handle these messages, but when I send out one of these messages it >> gets >> > processed by every other filter in the chain which is resulting in my >> > internal handshake messages being encoded by the TextLineCodec I have >> later >> > on in the chain. >> > >> > The chain looks like this: >> > DTLSFilter ---> DTLS Protocol Codec ---> TextLineCodec --> Logger >> > >> > When I initiate the handshake from the DTLSFilter, it writes the >> > HandshakeMessage to the IoSession, which promptly passed it for >> processing >> > through the chain in reverse order. This results in the TextLineCodec >> > "encoding" my HandshakeMessage before my DTLS Protocol Codec gets a >> chance >> > to. Is there a way I can simply disable the last N codecs during the >> > handshake process and re-enable them afterwards? >> > >> > I noticed some discussions about a state machine based filter process in >> > MINA 3.0 which sounds like it might be what I want, but thats not >> possible >> > in 2.0 AFAIK. I also noticed that SslFilter isnt using this approach, >> so >> > perhaps its not possible to have an out-of-band set of messages to >> perform >> > the handshaking and I should just try to repeat what SslFilter does! >> > >> >> DISCLAIMER >> ========== >> This e-mail may contain privileged and confidential information which is >> the property of Persistent Systems Ltd. It is intended only for the use of >> the individual or entity to which it is addressed. If you are not the >> intended recipient, you are not authorized to read, retain, copy, print, >> distribute or use this message. If you have received this communication in >> error, please notify the sender and delete all copies of this message. >> Persistent Systems Ltd. does not accept any liability for virus infected >> mails. >> >> >
