On Fri, Nov 01, 2002 at 08:11:53AM -0800, Nathan Yocom wrote: > I have read through everything I can and the only hint I can find that > SSL may/maynot work with RPC is that "SSL may be used with any > TCP/stream based communication". Technically I can restrict my RPC > communication to tcp only - is it possible to then use SSL as well? or > should I just look at using the crypto library to encrypt the actual rpc > data prior/after the rpc is made?
SSL/TLS needs a reliable ordered data transmission to run correctly. The SSL designers didn't want to worry about packet ordering and retransmission since that's not a security problem and it's been solved already. BTW, since you can define your data structures inside TLS to be whatever you want, you can simulate OOB inside TLS if it makes it cleaner to match up with your existing code. But the premise of OOB is that it can bypass data that is in the queue to go out, or on the input queue and not read yet, i.e. it can arrive quicker than 'regular' data sent at the same time. Since TLS runs on an ordered connection, your "OOB" data will arrive in the order it was sent. If RPC really makes sense for an encrypted remote filesystem (I don't think it does, but that's an argument for another list), then you might want to look into existing solutions for secure RPC, instead of forcing it into TLS. This would be quicker to implement. The alternative is to write your own protocol, and unless you're a security expert, designing your own protocol is likely to get you something that is breakable. (of course if it's a fun/learning exercise, you might want to do it for that reason, in which case I'd recommend reading at a minimum Rescorla's SSL and TLS book, then the protocol parts of Schneier's Applied Cryptography, before beginning) Eric ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
