On Thursday 31 Oct 2002 2:58 pm, Nathan Yocom wrote: > Interesting - okay ;-) Thanks for the info. > > Do you know whether is is simply because its not in the ssl code, or is > it a restriction based on SSL design? i.e. is it possible by hacking > the openssl lib, or are they mutually exclusive?
Well basically the reason is because SSL/TLS is simply a communication protocol that is designed to provide one linear stream of binary (byte-oriented) data in each direction - there's no inherent idea in the protocol to explain how to interpret any data that arrives "out-of-band", and the encapsulated transport that the protocol itself provides *ALSO* has no understanding of (or support for) out-of-band data. In fact, the SSL/TLS protocol is purely binary and has nothing per se to do with TCP/IP or even networking in general. You can replace any asynchronous pair of serial binary data streams with an SSL/TLS encapsulated version of itself. It just happens that nobody cares about any medium for SSL/TLS other than networking sockets (and even then, typically people are almost always interested specifically in TCP/IP). Eg. you could (if you wanted) self-encapsulate your own *postal* correspondance using SSL/TLS if you represent your "letters" as some kind of serial binary data (eg. null-terminated ascii bytes). (i) you'd have to post a couple more envelopes than the number of individual letters you had wanted to encrypt (and that applies in both directions), and (ii) you'd be posting a 2 or 3 good-sized pages of printed hexidecimal SSL/TLS stream data for each 1 or 2 clearly-written pages of english-language text you wanted to send, but in theory it would work. [Yeah I know, I guess it's hardly surprising nobody uses SSL/TLS for snail-mail ... :-) ] To provide a more constructive answer for OOB data though: you *could* fake it in the serial (non-OOB) SSL/TLS protocol data by creating a filter at each end of the SSL/TLS channel that implements a framing layer. Ie. frame the payload data so you can distinguish between "normal" and "OOB" data outside the SSL/TLS encapsulation. But why bother? The existing standards that people want to send over SSL/TLS are generally "serial" connection protocols (either sync or async) that have no concept of "out-of-band" data anyway. So typically they are simply fed directly in to (and out of) the SSL/TLS protocol without any framing to encode and detect (and thus *support*) out-of-band data - it would be a waste of time/performance/simplicity to do otherwise. This is currently the case, for example, with existing installations where SSL/TLS encapsulates HTTP, FTP, TELNET, SMTP, POP3, and a few others. In fact this is what web-browsers and web-servers do for HTTPS (it's HTTP inside SSL/TLS). For your own purposes however - you can define any behaviour you like for sending and interpreting out-of-band data as long as you keep it parallel to the SSL/TLS (the SSL/TLS stream data can't arrive out of order). This would be independant of OpenSSL (and any other SSL/TLS implementation) - and you would have to control the implementation at both ends of the connection. If this is for your own networking needs, that may be something you can do and and have a use for. But this won't help you if you want to talk with applications whose implementation you can't control. Nor will it help you if you want your applications to be compliant with standards you can't influence. Anyway, that's the long version of Jeffrey's more concise explanation! :-) > On Thu, 2002-10-31 at 10:26, Jeffrey Altman wrote: > > You cannot use OOB data with SSL/TLS. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
