On 2024-05-18 Elliott Mitchell <ehem+deb...@m5p.com> wrote: > On Sat, May 18, 2024 at 07:40:13AM +0200, Andreas Metzler wrote: >> On 2024-05-18 Elliott Mitchell <ehem+deb...@m5p.com> wrote: >>> On Sat, May 18, 2024 at 06:55:06AM +0200, Andreas Metzler wrote: [...] >>>> Afaict it is a short-cut to save more expensive processing for obvious >>>> errors. gnutls_session_get_verify_cert_status() (with >>>> gnutls_session_set_verify_cert() set correctly) or >>>> gnutls_x509_crt_check_hostname()/gnutls_certificate_verify_peers3() >>>> does more elaborate stuff on the data, >>>> gnutls_certificate_verify_peers2() requires a separate >>>> gnutls_x509_crt_check_hostname().
>>> Which seems to argue the more urgent issue is >>> _gnutls_server_name_send_params() needs to do checking of the provided >>> server hostname before sending it as SNI. >> Why is this urgent or even relevant? Certificate checking (client-side) >> will not accept IP adresses as SNI field. > Not relevant. If the certificate comes from a local file, it is assumed > trusted. If the certificate comes from the server, then it is only > available *after* connection and the SNI has already been sent. [...] Hello, You seem to argue that it is major problem for a gnutls client to *send* e.g. "127.0.0.1" as SNI. My point is that this is not a problem but at most uncomely since client-side certificate verification will fail. Even for a trusted certificate name checking is done (if gnutls is correctly used). And this will not succeed if the CN or SAN is an IP address. (I have tried with test certificates and gnutls-cli/-serv. My testing might be flawed of course.) cu Andreas
