
:max_bytes(150000):strip_icc()/002_wireshark-tutorial-4143298-5c11759b46e0fb00015fcd85.jpg)
Finally, load the application to the module. To log the data directly, go to Transfer->Log to File (text) from the top menu and select where you’d like to save the data. This will prevent you from having to do a lot of reformatting to the keys like you would if you were to simply copy and paste.

If you’re using MTTTY for your serial terminal, we recommend that you log the serial data directly to the file. The flags -no_ticket and -no_cache will prevent connections from using session resumption, which will make our lives a tad easier when trying to decrypt the packets from Wireshark.Īfter we’ve started the server, go ahead and start listening for the packets on Wireshark. The flag -accept just dictates what port the SSL server will accept connections on. For more info on that, see our article on self signed certificates. We generated ours using the certificate generation scripts provided with the NNDK tools. Note that you’ll need to have a certificate ( -cert) and key ( -key) handy. Openssl s_server -key Server.key -cert Server.crt -accept 4433 -no_ticket -no_cache For this we use this OpenSSL command from the command line: The second is to actually start the SSL server that will receive the connection. Simply change the macro SSL_SERVER_NAME to the proper IP address, and rebuild the application. The first is to add the IP address of your SSL server to the example. You can find this example in \examples\SSL\sslclient.įor this example, you’ll need to do two things in addition to the system changes above. It very simple, and shows how the NetBurner device can connect to an SSL server. Example Code Changesįor the purpose of this article, we’ll be using our 3.x tools and will do our testing with the SSL client example. If you’re using our NNDK 2.x tools, you’ll need to rebuild the system libraries separately before building the application. If you’re using our latest tools, either with NBEclipse or via the command line, everything is taken care of when you rebuild the project itself, as all of the system libraries are included as a part of this process. Now, choose any SSL/TLS example, or if you’re already working on your application, rebuild the system libraries and the project.

Next, down in the function MakeTlsMasterSecret(), replace This bit of code sets a define that will make the secret accessible, and the function SaveMasterSecret() will simply output everything passed to it out the serial port. Void SaveMasterSecret( const char* pmsBuf, int pmsPos ) Īt the top of the file, add the following snippet of code: #include First, open the file \libraries\crypto\src\tls.c. These are short, painless, and easy to put in and take out. As we mentioned before, in order to get the secret that is required to decrypt our packets, we’ll need to make a few changes to the crypto libraries. When it comes to secret keys used out in the real world, Gandalf said it best… Changes to NetBurner Application Code System Library Changes Please keep in mind that this should be used only for debugging purposes in non-production environments. Fortunately, for NetBurner devices a few small code changes will give you everything you need to start looking at that network traffic. Now that we know where to load the secret key, the question is where to get it. Without this secret key, neither side can decrypt any messages that are encrypted by the other side. In every secure SSL/TLS connection, information sent back and forth between the client and server is encrypted using a secret key (also called a premaster secret) that is generated by the client during the TLS handshake. We won’t dive too far into the TLS handshake in this article, but having a basic understanding of how it works will help explain what we need to do in Wireshark. Finally, we’ll show what it looks like in action. Then we’ll look at how to get that information from the NetBurner device. First, we discuss what information needs to be set in Wireshark and demonstrate how to do it. In this article, we’ll cover the steps you have to go through to get to this goldmine of debugging goodness. Given the proper information, Wireshark can decode this information for you and let you see exactly what’s being sent over the wire. Unfortunately, that doesn’t help you as you’re staring at the mix of unfamiliar garbage sitting in front of your face.įortunately, there is hope. Maybe you know what it’s supposed to say. Trying to debug issues over an encrypted connection with Wireshark is a lot like trying to edit an article in a language you don’t know. Most of this looks great, until you actually look at the data, and are greeted with, “Encrypted Application Data: ”.
