> 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 the server is currently in debug mode and returning extended errors, can more easily perform attacks on it... ________________________________________ De: TLS <tls-bounces@xxxxxxxx> en nombre de Peter Gutmann <pgut001@xxxxxxxxxxxxxxxxx> Enviado: domingo, 1 de abril de 2018 7:29 Para: Eric Rescorla Cc: IETF discussion list; General Area Review Team; draft-ietf-tls-tls13.all@xxxxxxxx; Dale R. Worley; <tls@xxxxxxxx> Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24] Eric Rescorla <ekr@xxxxxxxx> 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 endpoint someone has put up. >3. An endpoint that someone is actively working on with you. >4. An endpoint you control (e.g., you're running it on your own machine). > >If this is a debug-only feature, then it won't be available in case #1, I have the feeling the people who have commented on this were talking from real-world experience, and in the example I gave it was exactly case #1. This was a live, large-scale production environment by a major ecommerce organisation (details fudged somewhat to avoid identifying anyone, but everyone here would know the name), and the only way to get things working was to spend several weeks randomly tweaking every conceivable option on the client until things started working, because the only thing the server would say was "Handshake failure". The client-side organisation still has no idea what made things work, they've narrowed it down by trial and error to about half a dozen things they had to change, but that's it. If they'd been able to get the server operators to turn on extended-alert for even just a single handshake it would have avoided several weeks' effort and a fix that even now is pure guesswork. >For the same reason, it's not really that helpful in case #3, because you can >just ask the person you're working with to read the logs, Except that these people are EDI companies, not TLS experts. They have neither the expertise nor the inclination to help debug TLS issues. What they will do is enable debug on the server so the client can sort things out, but they're not going to devote any effort to sorting out the problem at their end. 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. >so this leaves case #2, Actually it leaves 1, 2, and 3. 4 is kinda pathological, so really the problem is "all of the cases". Peter. _______________________________________________ TLS mailing list TLS@xxxxxxxx https://www.ietf.org/mailman/listinfo/tls
