Bug: native-tls can send an invalid TLS SNI extension, by using IP in the host name

[Alvenix]

RFC3546 disallow using for IP address for server name indication. However it seems that native-tls violate this.

Literal IPv4 and IPv6 addresses are not permitted in "HostName".

I verified this by running the following openssl command:
$ openssl s_server -cert private/rsa_sha256_cert.pem -key private/rsa_sha256_key.pem -port 8000 -tlsextdebug

and using this example code:

use native_tls::TlsConnector;
use std::io::{Read, Write};
use std::net::TcpStream;

fn main() {
    let connector = TlsConnector::new().unwrap();

    let stream = TcpStream::connect("127.0.0.1:8000").unwrap();
    let mut stream = connector.connect("127.0.0.1", stream).unwrap();
}

Here is the relevant server output which indicate that native-tls send the IP as part of the server name indication:

Using default temp DH parameters
ACCEPT
TLS client extension "server name" (id=0), len=14
0000 - 00 0c 00 00 09 31 32 37-2e 30 2e 30 2e 31         .....127.0.0.1

I have encountered this bug while using reqwest and have reported here. I am not sure if this a bug in native-tls or incorrect usage from reqwest.

I have tested this on Ubuntu 20.04 only.

[Alvenix]

It was fixed here. Closing.