MITM on HTTPS traffic in Kazakhstan

Re:MITM on HTTPS traffic in Kazakhstan by jasonh3 on Thursday July 18, 2019 @06:00PM (#20474331)

Somewhat related: if there were a shared password between the client and server, Password Authenticated Key Exchange techniques [0] could offer protection even when the server CA was compromised. PAKEs use zero-knowledge proof techniques to assert that each side already had password material (and derive a key from it) without revealing what the actual password was if the other side didn't have it to begin with.

In this case, only connections where a password was already agreed on would be protected vs. general unauthenticated browsing.

There was a draft proposal to add PAKE support to TLS 1.3, but it appears to have unfortunately expired [1].

0: https://en.wikipedia.org/wiki/Password-authenticated_key_agr... 1: https://tools.ietf.org/html/draft-barnes-tls-pake-04

[ Parent | on HN ]

Re:MITM on HTTPS traffic in Kazakhstan by tialaramex on Friday July 19, 2019 @09:00AM (#20478255)

It died for lack of interest, you can basically watch that happen at IETF 102 here:

https://youtu.be/mx40DSeoxnw?t=1230

TLS 1.3 was in some part an exercise in removing crap people thought might be a good idea in earlier versions, but then either never used or turned out to be a terrible idea but was notionally "optional" so you could say to keep using TLS but just disable that feature. So there is skepticism pre-existing in that room against the idea of just adding more stuff than might be cool unless it's clearly _needed_.

A feature that keeps six people in Kazakhstan (who happen to have manually pre-configured a PAKE) safe but everybody else is still screwed isn't the sort of impact TLS 1.3 was looking for.

[ Parent | on HN ]

Re:MITM on HTTPS traffic in Kazakhstan by oneplane on Thursday July 18, 2019 @07:56PM (#20475117)

I suppose that'd take something pike obfuscated paper mail password exchange before digital. Or rtty. Or 56k international calls for key setup?

[ Parent | on HN ]