Hi,

section 3.1 of RFC 3546 [0] states:
> "HostName" contains the fully qualified DNS hostname of the server,
> as understood by the client. The hostname is represented as a byte
> string using UTF-8 encoding [UTF8], without a trailing dot.

However when using curl sends the hostname also when a trailing dot is
included, e.g.

$ curl --trace out.log 'https://www.google.de.'

Then out.log includes:
> == Info: SSLv3, TLS handshake, Client hello (1):
> => Send SSL data, 512 bytes (0x200)
> [...]
> 00b0: 00 00 13 00 11 00 00 0e 77 77 77 2e 67 6f 6f 67 ........www.goog
> 00c0: 6c 65 2e 64 65 2e 00 0b 00 04 03 00 01 02 00 0a le.de...........

Notice the 0x2e ('.') before the zero termination.
When using OpenSSL curl sets the SNI hostname as follows:
> !SSL_set_tlsext_host_name(connssl->handle, conn->host.name))

I could not find documentation for this OpenSSL function but a look into
the sources revealed no indication of handling for a trailing dot.

Leaving this trailing dot makes Apache pretty unhappy. He angrily
replies that the HTTP Hostname does not match the SNI HostName, which is
technically correct [1].
I wonder who is at fault here. Should Apache handle this trailing dot
situation more in a more liberal fashion or should either curl or
OpenSSL handle this? Many other applications like Mozilla Firefox seem
to have similar issues with SNI trailing dot situations.

Best regards,
Leon Winter

[0] https://tools.ietf.org/html/rfc3546#section-3.1
[1] "Hostname www.xyz.de. provided via SNI and hostname www.xyz.de
provided via HTTP are different"
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-04-22