Wireshark mailing list archives
Re: Wireshark-dev Digest, Vol 136, Issue 4
From: Sadik Sikder <sadiksikder () gmail com>
Date: Fri, 8 Sep 2017 17:15:19 +0200
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 thereisn'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 thedissection>> 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 logHave 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
Current thread:
- Re: Wireshark-dev Digest, Vol 136, Issue 4 Sadik Sikder (Sep 08)
- Re: decryption SSL Peter Wu (Sep 08)