Re: [Wireshark-dev] Support for TLS1.2 decryption using derived keys
Hi George, On Thu, Jun 18, 2020 at 08:29:41PM +0300, webpentest wrote: > Hello again, Peter and wireshark-dev! > > While testing and extending my schannel-sslkeylog tool that I previously > mentioned in the list ([1]), I found that in some cases I'm currently > not able to reliably tie extracted master secret to a client random, > because of the TLS Session Hash being in use (a.k.a "Extended Master > Secret", see RFC 7627). > In these cases I can only currenty reliably get a pair of session_hash, > master_secret, but this format is currently not supported by wireshark's > keylogfile parser. > > I was wondering whether a patch implementing this kind of sslkeylog > format (e.g. SESSION_HASH ) would be considered for > inclusion into wireshark? The amount of changes needed seem to be rather > small -- much smaller than my previous patch we discussed. That sounds reasonable. The session_hash (hash over all handshake messages) can indeed easily be implemented in the current form. In fact, it appears that this is currently unconditionally calculated when the secret is not yet available. It could potentially be useful when the Client Random collides (in the Go crypto/tls test suite it is all zeroes). > Of course some workarounds exist and extracting a client secret or a > session id must be possible, but it probably would make my tool much > less portable, because the API that I currently hook (namely, > SslGenerateMasterKey[2] and SslImportMasterKey [3] from ncrypt.dll) is > at least partially documented and more or less stable, whereas > extracting client secret or a session id for sessions that use Extended > Master Secret would require tapping into less-documented and less-stable > schannel.dll APIs. > > Regards, George. > > > [1] http://b.poc.fun/sslkeylog-for-schannel/ > [2] > https://docs.microsoft.com/en-us/windows/win32/seccng/sslgeneratemasterkey > [3] https://docs.microsoft.com/en-us/windows/win32/seccng/sslimportmasterkey Based on these two docs, I was not able to see where the session_hash is available. Would you mind elaborating on the (reverse engineered?) details? There are already a couple of formats, so ideally those can be reused. If not, then hopefully the proposed new addition covers this and future cases. -- Kind regards, Peter Wu https://lekensteyn.nl ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Wireshark and Kerberos keytabs?
Hi folks, I am trying to look inside kerberos blobs, so I followed the instructions at: https://wiki.samba.org/index.php/Keytab_Extraction and ran this command to extract the keytab for the user involved: ktpass.exe /out my.keytab /pass /princ @ /ptype KRB5_NT_PRINCIPAL /crypto all However, the enc part is not being busted out for me. Does anyone know how to do this? -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Code discussion - Extcap help files on Windows
Hi Chuck
There are no written rules for that, but basically the discussions take
place on gerrit when they are related to the code review itself. They are
moved or are started on -dev when they need more thoughts, more people or
simply when they become too long. Unless you have a working solution for
the issue, that you want to propose, I guess you are in the right place.
On Thu, Jun 18, 2020, 18:16 chuck c wrote:
> I'm looking to answer two questions:
> - where do these type discussions typically take place? Email? Code
> review comments?
> - suggestions on how to fix the Extcap help on Windows.
>
> thanks
> chuck
>
> +++
> https://www.wireshark.org/docs/wsdg_html_chunked/ChCaptureExtcap.html
> -
> "There should only be extcap programs (executable, python scripts, …) in
> the extcap folder to reduce the startup time and not have Wireshark trying
> to execute other file types."
>
> There are two file locations for Extcap programs.
>
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=ui/qt/about_dialog.cpp
>
>
> /* Extcap */
> appendRow(QStringList() << tr("Personal Extcap path") <<
> QString(get_persconffile_path("extcap", FALSE)).trimmed() << tr("Extcap
> Plugins search path"));
> appendRow(QStringList() << tr("Global Extcap path") <<
> QString(get_extcap_dir()).trimmed() << tr("Extcap Plugins search path"));
>
> Do the help files for Personal Extcap programs go in the "Program"
> directory (C:\Program Files\Wireshark) along with the official release
> Extcap html files?
>
> In the real world all the pieces just get stuffed in the extcap folder:
>
> https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_sniffer_ble%2FUG%2Fsniffer_ble%2Finstalling_sniffer_plugin.html
>
>
> Currently when clicking the Help button in the Extcap GUI, it looks in the
> Extcap folder for the help file.
>
>
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=extcap/sshdump.c
>
> --
> help_url = data_file_url("sshdump.html"); <--
> extcap_base_set_util_info(extcap_conf, argv[0], SSHDUMP_VERSION_MAJOR,
> SSHDUMP_VERSION_MINOR, SSHDUMP_VERSION_RELEASE, help_url);
> g_free(help_url);
>
>
>
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=wsutil/filesystem.c
>
> -
> data_file_url(const gchar *filename)
> {
> gchar *file_path;
> gchar *uri;
>
> /* Absolute path? */
> if(g_path_is_absolute(filename)) {
> file_path = g_strdup(filename);
> } else {
> file_path = g_strdup_printf("%s/%s", get_datafile_dir(),
> filename); <--
> }
>
>
>
> /*
> * On Windows, we use the directory in which the executable for this
> * process resides.
> */
>
> const char *
> get_datafile_dir(void)
> {
> if (datafile_dir != NULL)
> return datafile_dir;
>
> #ifdef _WIN32
> /*
> * Do we have the pathname of the program? If so, assume we're
> * running an installed version of the program. If we fail,
> * we don't change "datafile_dir", and thus end up using the
> * default.
> *
> * XXX - does NSIS put the installation directory into
> * "\HKEY_LOCAL_MACHINE\SOFTWARE\Wireshark\InstallDir"?
> * If so, perhaps we should read that from the registry,
> * instead.
> */
> if (progfile_dir != NULL) {
> /*
> * Yes, we do; use that.
> */
> datafile_dir = g_strdup(progfile_dir); <--
> } else {
> /*
> * No, we don't.
> * Fall back on the default installation directory.
> */
> datafile_dir = g_strdup("C:\\Program Files\\Wireshark\\");
> }
> #else
>
> ___
> Sent via:Wireshark-dev mailing list
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Support for TLS1.2 decryption using derived keys
Hello again, Peter and wireshark-dev! While testing and extending my schannel-sslkeylog tool that I previously mentioned in the list ([1]), I found that in some cases I'm currently not able to reliably tie extracted master secret to a client random, because of the TLS Session Hash being in use (a.k.a "Extended Master Secret", see RFC 7627). In these cases I can only currenty reliably get a pair of session_hash, master_secret, but this format is currently not supported by wireshark's keylogfile parser. I was wondering whether a patch implementing this kind of sslkeylog format (e.g. SESSION_HASH ) would be considered for inclusion into wireshark? The amount of changes needed seem to be rather small -- much smaller than my previous patch we discussed. Of course some workarounds exist and extracting a client secret or a session id must be possible, but it probably would make my tool much less portable, because the API that I currently hook (namely, SslGenerateMasterKey[2] and SslImportMasterKey [3] from ncrypt.dll) is at least partially documented and more or less stable, whereas extracting client secret or a session id for sessions that use Extended Master Secret would require tapping into less-documented and less-stable schannel.dll APIs. Regards, George. [1] http://b.poc.fun/sslkeylog-for-schannel/ [2] https://docs.microsoft.com/en-us/windows/win32/seccng/sslgeneratemasterkey [3] https://docs.microsoft.com/en-us/windows/win32/seccng/sslimportmasterkey On 02.05.2020 02:22, Peter Wu wrote: > On Sat, May 02, 2020 at 01:48:12AM +0300, webpentest wrote: >>> Since it relies on undocumented structures, maybe you could make an >>> automated test that you run with GitHub Actions to check whether it >>> keeps working? That can act as usage documentation as well. >> Some automated testing is a good idea, not sure how applicable would GH >> Actions be, because this probably needs to be eventually tested across >> multiple different versions of windows... > Based on https://github.com/actions/virtual-environments, it looks like > Windows Server 2016 and Windows Server 2019 are supported. There are > other CI platforms such as AppVeyor, they offer Windows Server 2012 R2, > 2016 and 2019: https://www.appveyor.com/docs/windows-images-software/ > > I'll leave it up to you to figure out a CI platform. Worst-case, you > don't have regression tests for older platforms. Best case, you catch > issues with newer platforms. And in any case, you could keep a local > fleet of machines and run the same automated scripts :-) > >>> With TLS 1.2, it resumes with the same master secret. So as long as you >>> have extracted the master secret from previous sessions, you should be >>> able to use the same master secret if you combine it with the Client >>> Random from the second session. >> By the way, if wireshark sees both the original handshake and the new >> resumed one, but the keylog file only contains master key for the first >> client random, I assume it will still decode the resumed session correctly? > Correct, Wireshark will associate the Session ID (or session tickets, if > there are any) with the master secret. It basically implements what a > normal client would do for session resumption. > >> My current understanding is that as I'm hooking the key creation >> procedure in lsass, it is not triggered during a resumption, because the >> key does not need to be recomputed for resumption. > That sounds reasonable, all that lsass would have to export is a session > ID or session ticket. Maybe you can extract these and use the "RSA > Session-ID:" format I mentioned before? (And "RSA" is really a misnomer, > it is independent of the key exchange.) > >> Also, for my testing it would be really nice to be able to quickly find >> out from wireshark's ssl debug log if there was any session not >> decrypted. Or, even better - is there a way to filter not-decrypted tls >> in the UI? > The Finished message is normally encrypted, you could match that as > quick test: > > tshark -r your.pcap -otls.keylog_file:keys.txt -Ytls.handshake.verify_data > > These are usually directly sent together with the ChangeCipherSpec > message. Assuming that is the case, then the following filter will show > non-empty output if there are sessions that fail decryption: > > tls.change_cipher_spec and not tls.handshake.verify_data > > Example info column for that case (tshark -Tfields -e_ws.col.Info ...): > > Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message > Change Cipher Spec, Encrypted Handshake Message > > Example info column for the case where decryption succeeds: > > Client Key Exchange, Change Cipher Spec, Finished > Change Cipher Spec, Finished > > Hope it helps! ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe:
[Wireshark-dev] Code discussion - Extcap help files on Windows
I'm looking to answer two questions:
- where do these type discussions typically take place? Email? Code review
comments?
- suggestions on how to fix the Extcap help on Windows.
thanks
chuck
+++
https://www.wireshark.org/docs/wsdg_html_chunked/ChCaptureExtcap.html
-
"There should only be extcap programs (executable, python scripts, …) in
the extcap folder to reduce the startup time and not have Wireshark trying
to execute other file types."
There are two file locations for Extcap programs.
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=ui/qt/about_dialog.cpp
/* Extcap */
appendRow(QStringList() << tr("Personal Extcap path") <<
QString(get_persconffile_path("extcap", FALSE)).trimmed() << tr("Extcap
Plugins search path"));
appendRow(QStringList() << tr("Global Extcap path") <<
QString(get_extcap_dir()).trimmed() << tr("Extcap Plugins search path"));
Do the help files for Personal Extcap programs go in the "Program"
directory (C:\Program Files\Wireshark) along with the official release
Extcap html files?
In the real world all the pieces just get stuffed in the extcap folder:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_sniffer_ble%2FUG%2Fsniffer_ble%2Finstalling_sniffer_plugin.html
Currently when clicking the Help button in the Extcap GUI, it looks in the
Extcap folder for the help file.
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=extcap/sshdump.c
--
help_url = data_file_url("sshdump.html"); <--
extcap_base_set_util_info(extcap_conf, argv[0], SSHDUMP_VERSION_MAJOR,
SSHDUMP_VERSION_MINOR, SSHDUMP_VERSION_RELEASE, help_url);
g_free(help_url);
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=wsutil/filesystem.c
-
data_file_url(const gchar *filename)
{
gchar *file_path;
gchar *uri;
/* Absolute path? */
if(g_path_is_absolute(filename)) {
file_path = g_strdup(filename);
} else {
file_path = g_strdup_printf("%s/%s", get_datafile_dir(), filename);
<--
}
/*
* On Windows, we use the directory in which the executable for this
* process resides.
*/
const char *
get_datafile_dir(void)
{
if (datafile_dir != NULL)
return datafile_dir;
#ifdef _WIN32
/*
* Do we have the pathname of the program? If so, assume we're
* running an installed version of the program. If we fail,
* we don't change "datafile_dir", and thus end up using the
* default.
*
* XXX - does NSIS put the installation directory into
* "\HKEY_LOCAL_MACHINE\SOFTWARE\Wireshark\InstallDir"?
* If so, perhaps we should read that from the registry,
* instead.
*/
if (progfile_dir != NULL) {
/*
* Yes, we do; use that.
*/
datafile_dir = g_strdup(progfile_dir); <--
} else {
/*
* No, we don't.
* Fall back on the default installation directory.
*/
datafile_dir = g_strdup("C:\\Program Files\\Wireshark\\");
}
#else
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Contribution in Wireshark during GSoD
On Thu, Jun 18, 2020 at 5:02 PM Sanyam Jain <17...@iiitu.ac.in> wrote: > This is Sanyam from India. I'm currently an undergraduate student pursuing my > course in computer science. Being a programmer I was looking for some > interesting projects to contribute to. While going through organisations in > "Google Season of Docs" I came to your organisation. GSoD is targeted towards Technical Writers. Programmer and Technical Writer are not quite the same. That being said, there's nothing preventing a person from doing both. > Since I am new to the community I would like to ask if any of your projects > are not taken up by someone then I am willing to work on that project or the > project which is prioritized by the organisation. Most likely Wireshark will receive one GSoD slot. GSoD is currently in the technical writer application period. The applications must be submitted via official GSoD form. We do not have access to the applications before the application submission deadline. > I have shared my idea please let in know what else you expect to be done > during GSOD. Looking forward to having a great learning experience while > contributing to the project before, during and after GSOD. Keep up the good > work, the project is really amazing. I am not sure what you mean by sharing your idea. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Contribution in Wireshark during GSoD
Hello, This is Sanyam from India. I'm currently an undergraduate student pursuing my course in computer science. Being a programmer I was looking for some interesting projects to contribute to. While going through organisations in "Google Season of Docs" I came to your organisation. Since I am new to the community I would like to ask if any of your projects are not taken up by someone then I am willing to work on that project or the project which is prioritized by the organisation. I have shared my idea please let in know what else you expect to be done during GSOD. Looking forward to having a great learning experience while contributing to the project before, during and after GSOD. Keep up the good work, the project is really amazing. Hoping to hear from you. Thank you. With Regards, Sanyam Github : https://github.com/sanyam188/ ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Tie code change to release version
What you can do on the command-line is the following: git log origin/master-2.4 | grep 'extcap: set help' this will give you an indication, if the patch was in 2.4 (for instance here). Coincidentally this is actually the version this patch was first released in. kind regards Roland Am Do., 18. Juni 2020 um 06:27 Uhr schrieb chuck c : > I would like to test installs with and without this change: > https://code.wireshark.org/review/#/c/19179/ > > Is there a way to figure out which binary this was first released in? > > > thanks > chuck > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
