>Possibly, if you consider being able to say "Invalid length encoding in
preferred-ECC-curves extension" in Tswana is mission-critical to debugging a
TLS handshake failure.
I so love your messages, Peter. Honestly I do.
Perhaps not Tswana, but perhaps China may care to pick a count
On Sat, Mar 31, 2018 at 10:29 PM, Peter Gutmann
wrote:
> Eric Rescorla writes:
>
> >In my experience, there are four major scenarios for diagnosing this kind
> of
> >failure. Under the assumption that you control one end, the other end can
> be:
> >
> >1. A live endpoint.
> >2. A testing endpoin
Anyway, I don't mean I'm against the idea of the extended errors extensions...
Only that let's not take it lightly. It can be a good debugging tool but also a
risky one.
De: TLS en nombre de Ion Larranaga Azcue
Enviado: domingo, 1 de abril de 2018 11:5
Of course not. I mean an attacker who is specially interested in this server
and knows that someone has requested a debug window on it.
De: Peter Gutmann
Enviado: domingo, 1 de abril de 2018 10:14
Para: Ion Larranaga Azcue; Eric Rescorla
Cc: IETF discussi
Ion Larranaga Azcue writes:
>And for the malicious user that, knowing the server is currently in debug
>mode and returning extended errors, can more easily perform attacks on it...
If there's someone on the Internet who can scan every TLS server on the planet
once a minute to see a brief debug w
> Note that temporarily enabling debug on a live endpoint isn't a big issue,
> everything will continue to operate as before except for the one client that
> requests debug-level alerts, and that knows what it's up for because it
> explicitly asked for it.
And for the malicious user that, knowing