Re: Wireshark-dev Digest, Vol 136, Issue 4

[Sadik Sikder <sadiksikder () gmail com>]

Thanks Mr. Peter for you kind help and cooperation...
i have figured-out how should i write my own decryption function . i have
some confusion or problem to understand... i am giving a example what i
would like to know.
in epan/packet-ssl.c file,  i have a seen a method called:
void
ssl_load_keyfile(const gchar *ssl_keylog_filename, FILE **keylog_file,
                 const ssl_master_key_map_t *mk_map)

or
void
ssl_debug_printf(const gchar* fmt, ...)
{
    va_list ap;

    if (!ssl_debug_file)
        return;

    va_start(ap, fmt);
    vfprintf(ssl_debug_file, fmt, ap);
    va_end(ap);
}

here ssl_load_keyfile or ssl_debug_print() are  methods. i havenot found
where these method are called into main function. similar this problem i
have faced several situations. In order to overcome the situation what
should i follow? how can i or which file/folder contains main functions
regarding epan/packet-ssl.c, epan/packet-ssl-utils.c?

i have used Eclipse IDE to track of these methods to figure-out main
function  but i was unable to find the main functions regarding
 packet-ssl.c, packet-ssl-utils.c and packet-ssl-utils.h.

Thanks in advance :)






*Kind Regards,*

Samsuddin Sikder
Masters Student
M.Sc. in Communication Systems Engineering
Cologne University of Applied Sciences (FH-Köln),Germany

On Tue, Sep 5, 2017 at 2:00 PM, <wireshark-dev-request () wireshark org> wrote:

> Send Wireshark-dev mailing list submissions to
>         wireshark-dev () wireshark org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.wireshark.org/mailman/listinfo/wireshark-dev
> or, via email, send a message with subject or body 'help' to
>         wireshark-dev-request () wireshark org
>
> You can reach the person managing the list at
>         wireshark-dev-owner () wireshark org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Wireshark-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: [RFC] Vendor-specific dissector extension for EtherNet/IP
>       (Michael Mann)
>    2. Re: decryption SSL (Peter Wu)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 4 Sep 2017 14:26:48 -0400
> From: Michael Mann <mmann78 () netscape net>
> To: groot.samuel () gmail com, wireshark-dev () wireshark org
> Subject: Re: [Wireshark-dev] [RFC] Vendor-specific dissector extension
>         for EtherNet/IP
> Message-ID: <15e4e251bae-c04-b17 () webjasstg-vab39 srv aolmail net>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> Hopefully inlining comments will work...
>
>
> -----Original Message-----
> From: Samuel GROOT <groot.samuel () gmail com>
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> Cc: Michael Mann <mmann78 () netscape net>
> Sent: Thu, Aug 31, 2017 8:58 am
> Subject: Re: [Wireshark-dev] [RFC] Vendor-specific dissector extension for
> EtherNet/IP
>
> Hi,
>
> I was already looking at CCO and the heuristic function when I received
> your last email.
> After some reading of the C dissector and some tests I arrived at the
> same conclusions, I will see now what I will implement, and how.
>
> > In the CIP specs, they focus on <identifier> being an object class and
> > instance, but
> > for some Rockwell PLCs, the <identifier> is just a string (and there is
> > no class in the message).
> > That's what I mean when I refer to "classless" requests.
>
> I never encountered this case but indeed this notion of segment is
> present in the CIP documentation, I didn't read it enough!
>
>
>
> I believe the only time you will encounter this is with Rockwell PLCs and
> its use is starting to go towards "legacy"
> status (not deprecated I'm guessing just because of backwards
> compatibility), so I wouldn't worry about it too much.
>
>
>
> >  >> 2. If you want to add vendor specific services to already supported
> >  >> objects, that would be more difficult to do in Lua because there
> isn't a
> >  >> dissector table hook for them.  I'm not sure there would be a way to
> >  >> handle the "general" case of registering service + class into a
> >  >> dissector table, but you could add dissector tables (patching
> >  >> packet-cip.c) for specific objects (Identity, ConnectionManager, etc)
> >  >> and submit just that part as a patch for inclusion in base Wireshark
> > code.
> > This is where I started to steer you incorrectly.  The heuristic
> > functionality should
> > be able to handle this case without issue.
>
> I think in this case it would be the dissector, since the heuristic only
> triggers for common services (and we want to support vendor-specific
> services for common objects).
>
>
> I believe what you want is:
> 1. A dissector for each vendor specific object
> 2. A (single) heuristic dissector for all vendor specific objects that use
> common services.
> I thought I could simplify the existing CIP dissector and only use one
> heuristic dissector (and just use a switch
> statement for the object IDs), but the "built in" objects have a way to
> list their attributes so they can be dissected
> by the common service dissection routines (GAA, GAS, GAL, etc).  I think
> part of the reason I never added an
> "external" interface for the attribute lists was I wasn't sure how to make
> it generic enough to fit into existing
> Wireshark APIs.
> Your 1 heuristic dissection function should look like
> dissect_class_cco_heur(), but have a switch statement for
> calling each of the object classes after you've parsed the EPATH for a
> request.  A "response" should be handled
> exactly like the CCO object (but I'm not sure how all of that would
> translate to Lua, trying to directly access a
> C structure from p_get_proto_data)
>
>
>
> > I think the intent of the cip.data_segment.iface dissector table was to
> > handle the "string"
> > identifiers I mentioned with the Rockwell PLCs.  It's probably something
> > that should actually
> > be removed from the dissector.
>
> It makes sense. Why remove it though, since it can be used to support
> "classless" services?
>
>
>
> Architecturally it seems simpler to have a heuristic function that
> registers with "cip.sc" table and dissects the EPATH
> for the "classless" services to determine if they are truly "classless".
> Again, the only ones that use this is Rockwell
> PLCs and because the information isn't in the CIP specs, I consider it
> proprietary, much like vendor-specific objects.
>
>
> >  >> 4. I believe Lua will "override" any value registered to a dissector
> >  >> table, so you could write the "vendor specific" portion, for say the
> >  >> Identity object, but then you'd have to duplicate all of the
> dissection
> >  >> currently being done for it in your Lua script.
> >  > I did test with setting a lua dissector for Identity in the
> > cip.class.iface, and on packets
> >  > with common services it wasn't triggered (I didn't have packets with
> > vendor-specific
> >  > services call for Identity).  So apparently it does not override the
> > default dissector
> >  > with the lua one (at least with a common service).
> > Again, this issue can be handled with the heuristic dissection mentioned
> > above.
>
> True in this case.
>
>
> So to clarify I could now cover the following cases:
> - Vendor-specific class, vendor-specific services with a dissector (one
> per class)
> - Vendor-specific class, common services with a heuristic (to handle the
> epath and attributes)
> - Common class, vendor-specific services with a dissector (again, one
> per class)
>
> An implementation in lua seems extremely tedious, since I will have to
> re-write most of the dissection code already present in C (status,
> epath, and attribute-related services).
>
>
>
> I hope you can simplify some of the dissection with the single heuristic
> function and a switch statement.
> But yes, you would have to rewrite (copy/paste) the value_strings used in
> the dissector.
> There is also the option of writing a C plugin (which I've done before and
> I know others have), but that is
> typically tied to a Wireshark release version (because APIs aren't
> guaranteed to stay the same between
> major releases)
> In general, I would discourage adding vendor specific object code to the
> Wireshark source base because
> of the high probability of collision (with another vendor's objects).
> Unless you're one of the large PLC
> manufacturers, you probably only have a handful of objects, and like most
> vendors you probably started
> at the bottom with 0x7F.
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://www.wireshark.org/lists/wireshark-dev/
> attachments/20170904/3e4587e6/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 4 Sep 2017 23:05:14 +0100
> From: Peter Wu <peter () lekensteyn nl>
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> Subject: Re: [Wireshark-dev] decryption SSL
> Message-ID: <20170904220514.GA5060@al>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Sikder,
>
> On Mon, Sep 04, 2017 at 12:48:30PM +0200, Sadik Sikder wrote:
> > could you tell me that which part of code decrypts using pre-master
> > key log
>
> Have a look at epan/dissectors/packet-ssl.c and
> epan/dissectors/packet-ssl-utils.c. For the involved data structures,
> see epan/dissectors/packet-ssl-utils.h
>
> The program flow in the common case (SSLv3/TLS) is as follows:
>
>  1. dissect_ssl is the entrypoint (commonly called from TCP dissector).
>  2. dissect_ssl3_record is called for each record.
>  3. ...which will read the record content type and call functions to
>     parse messages including handshake, alerts and application data.
>     If data was previously decrypted, that will be reused. Otherwise, an
>     record decryption is attempted.
>  4. The resulting (decrypted) buffer is given to
>     "dissect_ssl3_handshake", "dissect_ssl_payload", etc.
>
> In step 1, a "SslSession" structure is retrieved or created, this stores
> information about the current association (connection) like the version
> number in use. There is also a "SslDecryptSession" structure which is
> created on the first pass(*1) and contains the state necessary to
> perform decryption.
>
>  *1) Wireshark can be invoked multiple times for a packet. The first
>      time it linearly goes through all packets and performs decryption
>      if enough data is available. It may be called again after that to
>      fill in columns, or the packet details list (when you select a
>      different packet in the GUI).
>
> Decryption requires the cipher to be configured. Trace the use of
> SslDecryptSession in the packet-ssl.c and packet-ssl-utils.c files to
> find its uses. The "state" field will likely be very helpful. As you may
> know, key calculation (https://tools.ietf.org/html/rfc5246#section-6.3)
> requires a master secret, a server random and a client random.
>
> In the following sections I will try to describe the process involving
> the parameters, the master secret and actual record decryption.
>
> (About Client Random, SSL/TLS Version, Cipher Suite, etc.)
> The client and server random values are collected in
> "ssl_dissect_hnd_hello_common" (simply follow their call chain to see
> how it is invoked). It looks like this:
>
>     ssl_dissect_hnd_hello_common(..., SslDecryptSession *ssl, ...)
>     {
>         ...
>             rnd = &ssl->client_random;
>         ...
>         tvb_memcpy(tvb, rnd->data, offset, 32);
>         ...
>             ssl->state |= SSL_CLIENT_RANDOM;
>
> This pattern of saving information during dissection and setting a flag
> is used to ensure that all data is available before the decoder
> (decryptor) is created.
>
> (About Master Secret)
> For RSA cipher suites, the captured Encrypted Premaster Secret can be
> decrypted using the RSA private key (see "ssl_decrypt_pre_master_secret"
> as used by "ssl_generate_pre_master_secret").
>
> For cipher suites based on a DH key exchange, the captured
> ClientKeyExchange and ServerKeyExchange messages are of no use since the
> private (typically ephemeral) values are not known. That is why you have
> the "keylog file" method which simply maps the Client Random value to
> the master secret.
>
> Parsing the keylog file is not that interesting (done by
> "ssl_load_keyfile"), but note that it is attempted while parsing the
> ChangeCipherSpec message. The motivation is that by now all parameters
> (cipher suite, TLS version, Client Random, etc.) should now known and
> written to the file. Following this, "ssl_finalize_decryption" is called
> in order to try to build a decoder (remember that messages may be
> missing in a pcap or that the key may simply be unavailable).
>
> If all parameters are available, "ssl_generate_keyring_material" can
> start the real work. It calculates the (pre)master secrets, and then
> creates the bidirectional decoders using "ssl_create_decoder".
>
> (Record decryption)
> Now that the cipher is setup (the most difficult part I think), it is
> time to look at what "decrypt_ssl3_record" does. That function basically
> calls "ssl_decrypt_record" to do all the work. To understand function it
> is critical that you know about the three encryption types (CBC block
> mode, stream encryption and AEAD) as described in
> https://tools.ietf.org/html/rfc5246#section-6.2.3
>
> You should read that RFC section in order to navigate this
> "ssl_decrypt_record" function. The code has additional references to
> RFCs.
>
> I have skipped over details like record compression, fragmentation,
> session resumption, extended master secret, export ciphers, TLS 1.3 and
> many other things that affect decryption, but hope that this
> introduction will be helpful.
>
> Note that the described structure reflects the current implementation as
> of Wireshark 2.4. It might not be the best implementation, but should
> give you ideas how to write your own one.
> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev () wireshark org
> https://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
> ------------------------------
>
> End of Wireshark-dev Digest, Vol 136, Issue 4
> *********************************************
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe