Re: Expanded alert codes. [Was Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Sat, Mar 31, 2018 at 10:29 PM, Peter Gutmann <pgut001@xxxxxxxxxxxxxxxxx> wrote:
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,

Sure. I am also 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.

Maybe. I've spent a fair amount of time trying to diagnose failures where
I know precisely the line of code that generated the failure, and it can still
be quite difficult.

 
>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.

I'm not suggesting that they ask the counterparty to diagnose the problem,
just send the relevant logs. It seems like the ask of "turn on logging and give
me the results" and "turn on extended debugging" are fairly similar.

-Ekr



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux