Sorry that's my bad, I meant *Fiddler not wireshark. Fiddler makes it a piece of cake to decrypt the extra tls, leaving you with just the encrypted data you were sending.
Fiddler is a MitM proxy with knobs on. I don't deny it is rather handy. I use a lot of tools.
Wireshark simply listens. If you give it the private key for a TLS exchange it is able to decrypt the stream.
Fiddler makes changes to the stream - it turns a single stream into two streams with the Fiddler in the middle, Wireshark does not - per se - it just listens but because it will be a tap in a stream it will slightly affect that stream, unless you use a switch that can mirror ports - and that's what I do.
When it is your web server (int al) then you have access to the private key and then Wireshark's minimal touch is indicated. Otherwise Fiddler or similar (Squid and others for me) is indicated instead.
Wireshark doesn't come with a built in way to extract the dynamically exhanged TLS keys from applications and use that to decrypt the traffic, so no it does not do what you claim.
> If I install something like Wireshark, Fiddler or mitmproxy, will I be able to decrypt all HTTPS content flowing from my computer to the application server of interest?
Yes.
> If yes, then how to secure web traffic against such activity?
I can't tell if you know this or not, but TFA is not about MitM. Wireshark isn't acting as a proxy, it's using keys saved by the client application to decrypt the traffic after the fact.
Wireshark is worth a couple of hours of play. It was quite a revelation to use it on a non https connection and watch myself transmit my password letter for letter in clear text :) Yes one can imagine how that is, but still, doing it is different.
> I could watch each command and response going over the wire.
AFAIK, Wireshark supports decrypting TLS traffic if you give it the private keys.
> When a POP3 mailbox got hung up on a single huge message you could just telnet in
Use “gnutls-cli” or “openssl s_client” – transparent TLS for your terminal. Both those commands also have options supporting protocols’ use of STARTTLS.
It will suck to have to resort to essentially MITM tactics on my developer workstation in order to decrypt local traffic. Yes, there are tools like Fiddler that can do this, but eventually it may be impossible to MITM traffic the way Fiddler does. That will make it more difficult to debug applications. There are also platforms like Pivotal Cloud Foundry that rely on being able to inject headers into HTTP messages as the messages traverse the platform (e.g., to support throttling); this will become more difficult if that traffic has to be encrypted.
HTTP/2 with forced TLS is, in effect, a binary protocol. Right now, developers all over the world enjoy the plain-text and hackable nature of HTTP 1.x.
If you have the keys, it looks like it can[1][2] (a contingency is that connections must use `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`) -- it seems like it's basically the same thing as Wireshark (a network packet sniffer for debugging/forensic purposes).
Not sure why everyone on HN is freaking out about it. It's actually pretty annoying to have to install Wireshark (including their capture driver) every time I need to debug over-the-wire network data.
> wireshark/tcpdump/ngrep/etc might be challenging to practically use in the presence of SSL/TLS. you can mitigate this problem by setting up SSL termination at your network perimeter so you can monitor unencrypted traffic.
Nitpicky, but: this isn't MITM, this is the client side of the connection writing out the keys necessary to decrypt the wire traffic. This is important because the process doesn't change alter the network data in any way, whereas a MITM proxy would.
reply