On Wed, 2003-06-11 at 00:20, David Schwartz wrote:
> > Thanks for the reply. I've read Netscape's SSL 3.0 draft twice...most of
> > the information is simply data type specification in Baukus Naur Form
> > with no reference to the construction of the packet itself.
>
> Since SSL is layered on top of a byte-stream protocol, there won't be any
> specifications for packets.
As I understand it, SSL is a layer 4 (transport layer) protocol used in
conjunction with TCP (located slightly above TCP on the OSI heirarchy,
depending on whom you ask).
>
> > For
> > instance, it outlines several higher-level data types within the
> > protocol (SSLPlaintext, SSLCompressed, SSLCiphertext) and their
> > component types (type, version, length, fragment, etc.), but with no
> > useful information as to where such data is located in the packet.
>
> Because the protocol is not defined in terms of packets, it's defined in
> terms of objects that are streamed across a byte-stream link.
I also realize that SSL "objects" introduce their own fragmenting, not
necessarily preserving data block divisions from higher level protocols.
>
> > I
> > need to be able to map a struct{} data type over the packet headers, so
> > some sort of detailed specification (e.g., "bits 0 - 7 are flag bits
> > with the following possible values, bits 9-23 are ...") is necessary.
>
> If you need to do that, then you're going to be out of luck. The protocol
> is not specified in terms of fixed-byte objects. It's specified in terms of
> objects that contain sub-objects. Each object and sub-object contains its
> length within it.
However, the data is there and can obviously be retrieved or SSL would
not work. I am assuming you mean that, for instance, SSLPlaintext
objects have their own length/version/type, and this entire object is
mapped into an SSLCompressed object's "fragment" field after
compression. The SSLCompressed object is then encapsulated within the
"fragment" field of an SSLCiphertext object. The Netscape spec. was not
clear (in my opinion) about whether the entire object was mapped into
the higher-level object's fragment field, or just the data itself (i.e.,
the type/version/length was not encapsulated each time with it). Your
remarks have now cleared this up, thank you.
>
> If you're not familiar with BER (X.690) and ASN.1, you're really just not
> going to be able to do this.
I browsed through the book "SSL and TLS" that others on the mailing list
recommended. It is a great reference and seems to contain all of the
information that I need. (There were several object diagrams inside the
front cover that, combined with the SSL3 Internet Draft's information,
immediately made sense.)
I WILL be able to do this.
>
> > Obviously, I could map them myself using a packet sniffer and
> > trial-and-error packet generation, but this is somewhat tedious.
> > Alternatively, I could look at the source for OpenSSL or SSLDump I
> > suppose, but this is not desirable either. It seems to me that since
> > somebody somewhere has developed software that interacts directly with
> > the layer 3 protocol datagrams themselves, this information should be
> > available.
>
> Datagrams? I think you have some fundamental misunderstandings about what
> type of protocol SSL is and where in the stack layering it fits. That's
> probably why you looked right at the information you wanted and didn't see
> it. ;)
>
> DS
I'm familiar with the OSI model. See remarks above. Unfortunately, I
used the incorrect term. I should have referred to them as SSL objects
encapsulated within TCP segments.
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
Thanks to all who replied with suggestions. I believe I have what I need
to proceed.
DCL
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
