> 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.
Makes sense. > > 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. Interesting. I am still rapidly learning about using TLS, currently I just use SSL_read/write to send/recv data on a socket (set with SSL_set_fd), where might I look for info on defining data structures within TLS as you mention? > 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) It is a fun/serious/learning/practical exercise ;-) I will look into these things. Thanks for the great info! Nate ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
