attachment
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Mike,<div class=""><br class=""></div><div class="">Thanks for looking into that!</div><div class=""><br class=""></div><div class="">A slightly different problem I had previously observed with Wireshark releases that included your updated IPP dissector (starting with 2.4?) was that when IPP traffic captured communicating with an IPP Printer listening on a non-standard port (some port other than TCP 631) weren't being recognized as IPP for some reason. This happens a lot when sniffing ippserver. But I just tested this with Wireshark 2.6.5 and 2.6.6 and both seem to be working as I would expect. Just wanted to close the loop on that.</div><div class=""><br class=""></div><div class="">Cheers for the work!</div><div class=""><br class=""></div><div class=""><div class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: "Lucida Grande"; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Chair, IEEE ISTO Printer Working Group<br class=""> HP Inc.<br class="">*/<br class=""><br class=""></div></div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On Jan 16, 2019, at 6:57 AM, Michael Sweet <<a href="mailto:msweet@apple.com" class="">msweet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class="">
<div class="">All,<br class="">
<br class="">
I've done some testing with the current stable version of Wireshark on macOS to determine what is going on with IPPS support (one of my long-standing action items...)<br class="">
<br class="">
The short of it is this: I am able to successfully decrypt IPPS traffic when I have the private key of the printer and RSA is used for the initial handshake. However, if a more secure handshake is in use (e.g. ECDHE) that provides forward secrecy, this all breaks because, well, that's the nature of the security offered by TLS... :) Short of getting a printer to log its session key (not something I'd recommend in production firmware!), there isn't anything that can be done in Wireshark to "fix" this.<br class="">
<br class="">
I've filed a Github issue to track a possible future ipptool feature to log all network traffic to a file (decrypted) for analysis:<br class="">
<br class="">
<a href="https://protect-us.mimecast.com/s/qd3iCVOrBrcqLo0wsy-2_L?domain=github.com" class="">https://github.com/istopwg/ippsample/issues/168</a><br class="">
<br class="">
_________________________________________________________<br class="">
Michael Sweet, Senior Printing System Engineer<br class="">
<br class="">
_______________________________________________<br class="">
ipp mailing list<br class="">
<a href="mailto:ipp@pwg.org" class="">ipp@pwg.org</a><br class="">
<a href="https://protect-us.mimecast.com/s/4P7uCW6vDvhrgmz9tnNAOw?domain=pwg.org" class="">https://www.pwg.org/mailman/listinfo/ipp</a><br class="">
</div>
</div></blockquote></div><br class=""></div></body></html>