Hello,
On Wed, Jul 07, 2021 at 04:43:53PM +0200, Remi Tricot-Le Breton wrote:
> I was indeed more focused on logging SSL related information only, with
> the idea that an SSL log line could be displayed after a completed
> handshake, hence the lack of upper layer information in the log line.
> But it would indeed bring a new level of complexity in the log because
> correlating the SSL and HTTP log lines of a specific session might be a
> pain. After talking with Willy, an https log was deemed more useful. It
> would only be an extension of the existing HTTP log with SSL specific
> information added. This log format would concern every log line raised
> by the frontends using this log format (one line per HTTP response of
> the SSL session).
Yes, what would be great is a "option httpslog" which would provide a
default log line for HTTP over SSL.
> A quick recap of the topics raised by the multiple conversations had in
> this thread :
> - we won't used tabs as separators in order to remain consistent with
> the existing log format (especially since this new format will only be
> an extension of the HTTP one)
I agree, using tab doesn't not seems to be something we would want, it's
the same problem with people that would want json in their log, they
need a new format, not the default one.
> - the date format won't change right now, it is a whole new subject
> - the logged lines will all have the same "date+process_name+pid" prefix
> as the already existing logs
> - the HTTP log format won't be touched yet, changing it would be a whole
> new subject as well
Agreed.
>
>
> The log would then be as follows :
>
>
> >>> Jul 1 18:11:31 haproxy[143338]: 127.0.0.1:37740
> [01/Jul/2021:18:11:31.517] \
> ssl_frontend~ ssl_frontend/s2 0/0/0/7/+7 200 2750 - - ---- \
> 1/1/1/1/0 0/0 {1wt.eu} {} "GET /index.html HTTP/1.1 \
> 0/0/0/0 TLSv1.3/TLS_AES_256_GCM_SHA384
>
> Field Format Extract from the
> example above
> 1 process_name '[' pid ']:' haproxy[143338]:
> 2 client_ip ':' client_port 127.0.0.1:37740
> 3 '[' request_date ']' [01/Jul/2021:18:11:31.517]
> 4 frontend_name ssl_frontend~
> 5 backend_name '/' server_name ssl_frontend/s2
> 6 TR '/' Tw '/' Tc '/' Tr '/' Ta*
> 0/0/0/7/+7
> 7 status_code 200
> 8 bytes_read* 2750
> 9 captured_request_cookie -
> 10 captured_response_cookie -
> 11 termination_state ----
> 12 actconn '/' feconn '/' beconn '/' srv_conn '/' retries*
> 1/1/1/1/0
> 13 srv_queue '/'
> backend_queue 0/0
> 14 '{' captured_request_headers* '}' {haproxy.1wt.eu}
> 15 '{' captured_response_headers*
> '}' {}
> 16 '"' http_request '"' "GET /index.html
> HTTP/1.1"
> 17 *conn_status '/' SSL fe hsk error '/' SSL vfy '/' SSL CA vfy*
> 0/0/0/0
> 18 *ssl_version '/' ssl_ciphers* TLSv1.3/TLS_AES_256_GCM_SHA384
>
> and the corresponding log-format :
>
> %ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC \
> %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r \
> *%[conn_err_code]/%[ssl_fc_hsk_err]/%[ssl_c_err]/%[ssl_c_ca_err]* \
> *%sslv/%sslc*
>
I saw that you hesitated between "conn_status" and "conn_err_code", the
"conn_" prefix could be confusing at some point once you try to have
errors on the frontend and the backend side in the same log-format, I
think something starting by "fc_conn_" would be more understandable.
That seems good to me, we only need frontend info IMHO. People who need
the SSL backend connection are not the most common case so they could
make their own log-format with it.
--
William Lallemand
