test: openssl s_client debug mode for ssl_integration_test. #5092
Conversation
This makes life easier when debugging SSL handshake issues. Risk Level: Low Testing: ssl_integration_test with debug and !debug. Signed-off-by: Harvey Tuch <htuch@google.com>
| protected: | ||
| // Set this true to debug SSL handshake issues with openssl s_client. The | ||
| // verbose trace will be in the logs, openssl must be installed separately. | ||
| bool debug_with_s_client_{false}; |
There was a problem hiding this comment.
Shall we use the @borignssl//:bssl cc_binary? Then this is self-contained.
There was a problem hiding this comment.
Yeah, it seems like it would be a better option, but it turns out that bssl is a bit impoverished when it comes to debug output. Take a look at this comparison: https://gist.github.com/htuch/a440a4edfaa059bc83647f3f3cd7083e (there are two files there, one for openssl with max debug, another for bssl). I think when chasing down very low level handshake issues in these tests, having the full openssl s_client output at disposal is the most helpful.
There was a problem hiding this comment.
What information missing in the bssl output is useful to you? Or more generally, what information from the openssl output is useful to you?
I have a PR stashed somewhere that adds trace logs during handshake (from TLS socket, not external binary), but it's even more minimal than output from bssl.
There was a problem hiding this comment.
Take a look at the gist I link to. openssl gives you a running commentary of different parts of the handshake, it dumps cert details and even the low level hex is sometimes interesting IMHO. Since this is a debug-only setting for one particular test, I'm hoping it's not too controversial :)
There was a problem hiding this comment.
I know what's the difference... What I'm asking is which of that extra information was actually helpful to you?
There was a problem hiding this comment.
Yeah, seeing the decoded certificate types, cipher suites, CNs, signing chains before connection completes was helpful; this was a situation in which handshake failed but I still wanted to see what was on the wire. Also, since I am relatively new to the low-level details of the TLS handshake, being able to see where the failure occurred and what the exact TLS frame looked like was interesting from a grokking perspective.
There was a problem hiding this comment.
Friendly ping, can we merge this one?
There was a problem hiding this comment.
Sorry for the delay, I'm OOO this week. Yeah I think it's fair to use openssl.
…xy#5092) This makes life easier when debugging SSL handshake issues. Part of envoyproxy#1319. Risk Level: Low Testing: ssl_integration_test with debug and !debug. Signed-off-by: Harvey Tuch <htuch@google.com> Signed-off-by: Fred Douglas <fredlas@google.com>
This makes life easier when debugging SSL handshake issues.
Part of #1319.
Risk Level: Low
Testing: ssl_integration_test with debug and !debug.
Signed-off-by: Harvey Tuch htuch@google.com