News for hackers. Stuff that matters.
Re:The hidden cost of QUIC and TOU (2016) by tinus_hn on Friday November 02, 2018 @01:41AM (#18360932)
It would be nice if these protocols could be easily decrypted using a key available on the client. Other than that, tough luck for the ‘transparent’ proxies and friends.
Re:The hidden cost of QUIC and TOU (2016) by tialaramex on Friday November 02, 2018 @08:06AM (#18362378)
Of necessity both client and server have the session keys.

In principle it would be possible for the client to lack keys needed for the server to read data sent by the client, and vice versa, but in practice this is never done.

Under Forward Secrecy a Middlebox must learn fresh session keys for every connection or it can't decrypt it. Both clients (e.g. Firefox) and servers (e.g. using Java or OpenSSL) have facilities to dump the session keys out somewhere, and this is adequate for debugging although obviously you will need to acquire new skills if you're used to being able to get stuff done with a paperclip and a copy of tcpdump. At scale this get hard, arguably that's fine because a minute ago we said we wanted this for "debugging" but people who got their foot in the door with a "debugging" argument often actually want to decrypt everything, always, and so they're unhappy about this.

If you don't want Forward Secrecy you have two options. Firstly, when the specification says to think of a random number for the key exchange protocol, you can always pick the same number, or a number chosen in some predictable fashion, the Middlebox can know this number (or method for predicting it) and then it can snoop as normal. This works in TLS 1.3, obviously it weakens your security (if bad guys learn how to predict the numbers you are screwed) but that's your choice.

Secondly you could use a key exchange process that doesn't have any Forward Secrecy by design, such as the RSA key exchange from SSL that's grandfathered into TLS 1.0 through 1.2. In this case you just give the server's private RSA key to the middleboxes and they can decrypt everything.

As you may notice in all the above scenarios, this is very bad for your security. But if "debugging" is really the problem that's almost certainly acceptable to you.

Re:The hidden cost of QUIC and TOU (2016) by rocqua on Friday November 02, 2018 @11:27AM (#18363690)
Dumping out those session keys comes with major logistical and security problems. All of a sudden, debugging requires

1) Updates on every client you might want to debug

2) Securely transporting the session keys from those clients to the person debugging.

Those are some massive challenges. An alternative is to always MitM all your devices. This comes with obvious downsides. Moreover, I could see providers doing cert-pinning that isn't over-ridden by user installed certificates. That would make it literally impossible to MitM your own devices.

This kind of cert-pinning really scares me, because it takes away any possibility to inspect your own network communications.

Re:The hidden cost of QUIC and TOU (2016) by hornetblack on Friday November 02, 2018 @03:35AM (#18361232)
I know that for https in NSS browsers (Chrome and FF) you can dump the secrets to a file that Wireshark can read. Given that Chrome is currently the biggest user i would be supprised if that was easy to update.
Re:The hidden cost of QUIC and TOU (2016) by nouseforaname on Friday November 02, 2018 @12:12PM (#18364156)
I believe chrome currently uses BoringSSL not NSS, but still has some facilities for writing the same keylogfile.