Hi Rémi, [ I warned you that this was going to open a pandora box :-) ]
On Fri, Jul 02, 2021 at 04:26:48PM +0200, Remi Tricot-Le Breton wrote: > Some work in ongoing to ease connection error and SSL handshake error > logging. > This will rely on some new sample fetches that could be added to a custom > log-format string. > In order to ease SSL logging and debugging, we will also add a new default > log > format for SSL connections. Now is then the good time to find the best > format > for everyone. > The proposed format looks like the HTTP one to which the SSL specific > information is added. But if anybody sees a missing information that could > be > beneficial for everybody, feel free to tell it, nothing is set in stone yet. A few points first, that are needed to address various concerns. The goal here is to defined an HTTPS log format because that's what the vast majority of users are dealing with day-to-day. For specific usages, everyone already redefines log formats. But for a very basic setup, right now it's true that httplog is a bit limited, and all it shows to help guess there was SSL involved is to append this '~' after the frontend's name. However, it's also clear that most users will not violently migrate from httplog to httpslog, and it's important to keep a smooth enough transition. This also means not to change stuff that would be relevant to httplog as well (e.g. delimitors, time format etc). We can (and should) have discussions about what to change in future log formats, but let's not use the https one as a bootstrap for passing everyone's missing field. Instead, let's focus on the SSL-specific stuff that users are always missing from HTTP logs, and try to establish a reasonable list that will always be there and suit most users without adding too much for others, and that will require limited adaptations to parsers. > The format would look like this : > >>> 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 \ > 0/0/0/0 2750 ---- 1/1/1/1/0 0/0 TLSv1.3 TLS_AES_256_GCM_SHA384 Like Aleks, I think that we could have a single version+cipher field, as not all combinations are permitted anyway. > 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 *conn_status '/' SSL hsk error '/' SSL vfy '/' SSL CA vfy* 0/0/0/0 Be careful above not to reproduce the errors from the past, namely using a designation that could apply to both sides. "SSL hsk error" etc could be valid for either frontend connection, backend connection or both. We must absolutely be clear and explicit here about what this is. The same will be true for the versions and ciphers. I suspect that all of these will mostly be of interest for the front side but I could be wrong (particularly for errors). But it's probable that discussing the backend side already enters a new sub-topic in fact. Willy
